Draft: draft-ietf-sipping-config-framework-11.txt Reviewer: Cullen Jennings [fluffy@cisco.com] Review Date: 3/9/2007 Review Deadline: Status: Interim Review Summary: This draft is on the right track but has open issues and nits, described in the review. Comments: --------- My overall feeling was that it was easer to understand and making progress in the right direction but still had a long way to go. This is all sent with my individual hat on and I apologize that many of the comments are not all that clear but I am trying to get thorough a bunch of drafts right now - I'm happy to rewrite or clarify any comments that make so little sense that you can't figure them out. Cullen I think the separation of the security stuff into the security section is causing serious problems. I think the best path would be to describe the normative things the various software must do like in the place it makes sense outside the security section. Then have the security section only focus on explaining the threats, the overall model, why it is secure, and any limitations. I think the device ID should be carried in the contact and nowhere else. I think the rules for how the users id gets inserted are the same for all profiles types 3.3 2nd para, last para, should be clear applies to devices enrolled to that profile not all enrolled devices 3,2 - for the security to work we need to put some additional explanation about what is in the profiles. Local network - typically will not have any information that could not be revealed to everyone Device Profile - typically has significant users specific private information including pointers to the user profiles and the credentials to access them User PRofiles - typical has significant private information 5.1 - need to deal with ordering if both v4 and v6 are available 5.1.1.1 - point 1 - we have no guarantee that sipuaconfig.domainj is not already in use for something else. I feel pretty strongly we can't use this. I suggestion the _ approach. in point 3 - duplicates point 1 point 4 - put in contact header ALso the AOR may not be known to the device at this point. 5.1.1.2 I don't think the request URI needs the device id - this is in the contact 5.1.1.2.1 The MAC stuff is forming a new URI type and would need registration - this will be a bunch of work and this is 100% a subset of UUID. Originally people claimed this would be done long before UUID so we could not block on UUID - this is no longer true since UUID is an RFC. I think we should make this document simpler and drop the MAC stuff. Section 5.1.1.2.2 The draft has Devices MUST follow the procedures specified below in the order presented, unless exceptions are made by device manufacturers or Device Providers who may provide an option for the user to choose the order (to suit specific deployment models, for example). We need to remove unless wiggle room like this to make it so the draft specifies something that would be interoperable. The draft has the specific places where a device can use some manufacture or manually specified sort of way of getting some information - that's part of the spec and does not need a you MUST do X unless you decide to do something else. In point 1 Has The details of how this is accomplished are beyond the scope of this document. I disagree - i think this clearly explain what happens when the dim or flash provides the domain of the PDS or some other info point 2, the MUST could be removed from this para 2a - "devices that support DHCP" - we need to decide if this spec requires devices to support DHCP - I suspect it does because we have no other way to get local network profile 2b - why do we really need both of approaches described in 2b - could we simplify and just have one of them in point 3 3 have the device SHOULD provide a means for the user to present information that may help with the retrieval process. this is way too vague - suggest chaining to the device SHOULD provide a means for the user to manual enter the domain later The user MAY be allowed to present information pertaining to a configuration server that provides the device profile, not using a PDS as defined in this framework. This framework specifies one such possible process in Section 5.5.1. way too vague to be implementable - just remove Section 5.1.1.4 Things like "... should be carefully considered." leave me not knowing what this means to an implementor. draft has When cached, the device should use the cached Subscription URI upon a reset. Exceptions include cases where the device identifier has changed (for example, new network card with a new MAC address), Service Provider information has changed (for example, user initiates change) or the device cannot obtain its profile using the Subscription URI. I think there are some subtleness of what a reset is here that we need to cover. Clearly if it reboots, power cycles, etc it needs to cache. However if the users does "reset to factory ship" sort of state, then it should not cache. I don't know the best way to write this up but it will take some text. Basically the device should cache this as long as it the user does not tell the device to blow it's brains out. I think it is fine if a device profile updates the URL for future device profiles - this should also be mentioned. I think the or the device cannot obtain its profile using the Subscription URI. is the wrong thing to do. Basically, when you loose this ache, the phone will in many cases will enroll in the local network. This means that if I took my phone to a hotspot, and it temporarily could not connect to the right thing, it might go and enroll in the local system - this is not what we want. 5.1.1.4 has not mention of user URI - it should 5.1.2 the points that a device MUST do something specified elsewhere in the document is really confusing as a MUST - just put the normative language in the other section and remove the MUST here You have A device SHOULD follow suitable BackOff and Retry mechanisms if a successful Profile Enrollment does not happen within the expected period. This needs to be specified how this all works 5.1.3. The document needs to deal with what happens if a profile is downloaded but that profile data has an error in it. There needs to be a way for the PDS to understand the client will not perform the update. The do has o the device SHOULD cache (i.e. store persistently) the contents of retrieved profiles, until overridden by subsequent Profile Change Notifications (this avoids situations where a PDS is unavailable, leaving the device without required configuration) I don't think we want this for the local network - the problem is that if you can't access the local PDS - your info is likely to be very wrong and assuming no local PDS is likely better. Stuff like the device MUST retry using alternate methods for creation of the enrollment subscription and transmit an enrollment request. seems really confusing - how do I implement that MUST in an interoperable way? Just delete all this sort of stuff from the draft. section 5.2 Profile Content Retrieval protocols and frameworks are out of scope for this specification. I don't think this is true. The document specifies it is mandatory to implement http and https as well as NOTIFY - it provides a way to negotiate what transports (such as https or ftp) can be used and it specifies a way to negotiate what body types are understood by the client. All this should be described at a high level here along with a way for the client to find out the PDS can not produce any profile content type that the client can understand. 5.4 - delete "compliant with this framework" Section 5.5.1 Paragraph 1 - this example makes absolutely no sense as a motivation. If DNS does not work for SIP, it's not going to work for HTTP either. The solution if you want it to wok when DNS does not is to use an IP address in the SIP URI for the profile. Things like devices expected to encounter scenarios where propogation of the device profile can be hindered may employ the specified - or any alternative - process. make no sense for figure out out to make this work in an interoperable way. The problem with this HTTP approach revolves around the only reason you would do it was if the SUB/NOT did not work. But if the SUB/NOT did not work, it is not going to work after the HTTP fetch. At this point their is no way to find out about future updates and apply them. The point of this framework and reason it was in RAI not apps was because it requires real time notifications of change updates. This section breaks that and offers no benefits that I understand. There are also issues with what the credentials are because the URI now has to be long lived and contain contain the secret in part of the URI. It is also unclear how the PDS finds out that the NOTIFY are not working. I am very much in favor of removing all of 5..5.1 unless someone can clearly articulate why the existing approaches in the rest of the draft are not adequate. 5.5.2 There are some issues to explain this draft for devices that do not know about a user - I would leave it out of scope for now but I don't feel too strongly about this. 5.5.3 has As an example, the device profile may contain the list of codecs to be used by the device and the user Profile (for a user on the device) may contain the codecs preferred by the user. Thus, the same data (usable codecs) is present in two profiles. I think this is a bad example - the device profile has a list of "allowed codecs" which is merged with the inherent "supported codecs" that the device has software to support, and then this list can be combined or ordered with the users "preferred codecs" lists. The allowed, supported, and preferred all seem to be fairly different information to me. 6.2 I think the device-id and network-user should be removed from the Event header. The network-user can be found in the From and device-id in the contact. Having them two places will only lead to problems within they are not the same and means we do not need to deal with the privacy of them separately in two different places. I have not heard any compelling reasons they need to be here. 6.2.5 need to specify that the units for the effective-by is seconds. WOuld be nice to specify an upper bound on the number too (like 32 bits or something) 6.5 - this is vague about who has to support TLS, - I think what you want is both client and PDS the draft has Further, if the Accept header of the SUBSCRIBE included the MIME type message/external-body (indicating support for content indirection) the content indirection SHOULD be used in the NOTIFY body for providing the profiles. I think this SHOULD needs to be a MAY - the PDS should be able to choose. ALso need to say somewhere that if the UA does not support cid, then PDS MUST send the profile in the NOTIFY here it says If none are specified, the Profile Data frameworks are responsible for, and MUST specify, the MIME type to be assumed. This does not make sense - I think UA has to say what it supports and only those can be used section 6.6 If the NOTIFY is expected to contain profile contents or the Notifier is unsure, the SUBSCRIBE SHOULD be either authenticated or transmitted over an integrity protected SIP communication channels. this is looking pretty wacky to implement without knowing an awful lot about the data before you decide to even accept the subscribe. In generally all the stuff about how and when a subscribe id authenticated is very confusing. I think we need to work through in a very clear way. In general, I think the approach should be along lines of 1) PDS receives subscribe (regardless of profile type) and decided if the From is an AOR that it is authoritative for 2) if not it marks the request "unauthenticated" 3) if it is, it challenges and if the challenges succeeds it marks the the request as "authenticated" 4) when profiles data schema are defined, the are specified as either working for unauthenticated, authenticated requests, or both 5) if it us an unauthenticated request and profile data that requires authentication, no result is returned 6) if it in an unauthenticated request and a profile that returns both, the profile defines how to construct the returned data such that no privacy is revealed for the unauthenticated request. Everywhere the document has "integrity protected SIP communications channel" just change it to to TLS, it's the only one we have defined for SIP where the application can detect this is the case and can understand who it is integrity protected too. Section 6.7 Does the Subscriber have to support content indirection? I would actually prefer not to require this but can be convinced either way. If the SUBSCRIBE was received over an integrity protected SIP communications channel, the Notifier SHOULD send the NOTIFY over the This would be a change to 3261. Imagine a case where SUB came via a proxy that did not RR. By default the NOTIFY would not. I basically think that the best way to deal with this is just say that clients have to use outbound but I'm also ok with saying nothing on this subject. draft has If the Subscriber wishes to support alternative URI schemas it MUST be indicated in the "schemes" Contact header field parameter as defined in [RFC4483]. If the subscriber does not specify the URI scheme, the Notifier may use either "http:" or "https:". I think it would be better to go with the Notifier MUST not use any scheme that was not indicated in the schemes 6.8 This does not cover what happens with the error handling when the Subscriber gets some profile data that they are not capable of interpreting because it has a syntax error or something. I think he PDS needs to know that the stuff it wanted to be effective by item X is not going to happen. 6.9 ANy advice on how to stop or what to do if forking does happen. I ignored all the example sections Section 9 prior to 9.1 seemed like it might not be needed but we can ignore till more of the nuts and bolts is clear. I don't read this and get the felling that we have a simple clear description of how security works. As I said on the call, I think you need to clearly explain how both the device and PDS are authenticated for each profile type, where the credentials come for for authentication, how the integrity of the profile data is ensure, and then how the privacy of profile data is protected. To me it seems that for Can you just change "service credential" to credential - I have no idea what a service is after reading the sipping list :-) o devices and PNCs complying with this framework MUST implement TLS as specified in [RFC3268], including support for both mutual and one-way authentication (server-side) This is for SIP or HTTP? mutual TLS is not really possible in SIP for the type of devices we are talking about here. I would like to see this defined assuming that the way a UA authenticates to a server is using digest. If at some later date some sets up a certificate based approach for doing this then that can state that it is an alternative to digest and can be used where digest is used. o a PNC capable of propagating device and user profiles MUST contain a X.509 certificate. This certificate MUST contain the PNC's Fully Qualified Domain Name in the 'SubjectAltName', establishing the PNC as a host in the Service Provider's domain Uh - it needs to be more subtle this this - we need to say must implement not must use. We also need to allow for certificates that use CN instead of SAN. o a PNC capable of propagating local-network profiles or unauthenticated device profiles MUST support the use of the SIP Identity header as defined in [RFC4474] for inclusion in profile notifications What identity would it assert - this never seems to be discussed. * the PNC MUST authenticate the identity of the user (if set to anything other than the default) what is the default? this seem like the wrong way to go * the PNC MAY NOT authenticate requests for the local-network profile that do not result in any user-specific sensitive data (irrespective of the value of the From field) I know what you are getting at here but keep in mind it means the PNC needs to be able to know what requests will result in this and what will not. * the PNC MUST include the SIP Identity header as defined in [RFC4474] within profile notifications sent in response to local-network profile enrollment, unless an integrity- protected channel exists (for example, using S/MIME) I think that Identity is a good way to provide integrity for the body but keep in mind it is just the body and not the header with the cid. This would need to be clear about when you did not need to send it. I think we can safely assume that no one will use S/MIME in the short term and that our solution needs to work without it. * a device receiving profile notifications for local-network profiles MUST verify the SIP Identity header, unless transmitted over a previously established authenticated, integrity-protected channel. keep in mind the name we are verifying against we discovered with DHCP so I am having a hard time figuring out what this buys us from a security point of view for this profile - I understand for device and user. If none exists, the device MUST establish a TLS connection with the PNC and verify the PNC's certificate. Are we only going to allow config to be used in places where there is not edge proxy? this seems too limited to me I think that in the case of a phone that has no credentials and is getting a device profile for the first time, explaining the baby duck imprint and why this is OK because the phone does not reveal anything that was not already known to the system it imprinted on is worth explaining draft has If the PNC authentication fails or a secure communications channel cannot be established, the device MUST treat it as a device profile enrollment failure and take measures such as retry enrollment what does retry mean here? if it means dumping the cached URI, that would be really bad from a security point of view Worth talking about how a new device with no AOR or credential gets enrolled. Section 9.2 o devices and PCCs compliant with this framework MUST implement HTTP Digest authentication as specified in [RFC2617]; this is used whenever an authentication challenge is initiated using HTTP based protocols specified for interoperability need to describe where do the credentials fro this come from? and how does device know which one to use o a PCC complying with this framework MUST contain a X.509 certificate. I think we want must implement not must use Need to discuss how names of certs are validated Section 9.3 I did not understand o an entity that is allowed to make updates MUST contain a AOR that is known to the network and the requirements for making changes are the same as that for user profile content retrieval, with the authorized entity playing the role of a user Section 10 OLD Rohan Mahy from Plantronics NEW Rohan Mahy from Cisco, Airespace, Plantronics, and couting (and Jon is from Neustar)