Draft: draft-ietf-sipping-config-framework-13.txt Reviewer: Elwell, John [john.elwell@siemens.com] Review Date: 10/31/2007 Review Deadline: 11/9/2007 Status: Post-WGLC Summary: This draft is on the right track but has open issues, described in the review. General comments: This is a big improvement on the previous draft - thanks. However, I do still have lots of comments. In particular, I think there are security and other holes concerning the case where there is a proxy between the UA and the PDS. My review record is below: Detailed Comments: ================== 1. "PDSs and devices will implement all the three profile types. Unless configured otherwise, a device will try to obtain all the three profile types" Shouldn't there be a means by which the first profile downloaded can indicate if there is no need to fetch additional profiles? This would avoid pre-configuration. 2. "There are no proxies in the network" This assumption for the Simple Deployment Scenario seems to suggest a P2P network, which should be outside the scope of this document (a matter for the P2PSIP group). Does it mean that UAs can contact the PDS without going through a proxy? If so, say so. However, I am not sure how typical this case would be. Once configured with an outbound proxy (which is the norm), future SIP requests, including any SUBSCRIBE or re-SUBSCRIBE requests to this package, will go through the outbound proxy according to normal RFC 3261 rules. We shouldn't specify anything in contradication. 3. " (A) Upon initialization, the device obtains IP configuration parameters using DHCP. (B) The device performs Profile Enrollment for the device profile ; the device profile data is contained in the enrollment notification." Why the device profile? Since the local-network profile is normally gathered before the device profile, wouldn't the local network profile be more suitable for this Simple Deployment Scenario? 4. "o The device MUST use the device identifier and the device provider's domain name to form the Request URI." It should say exactly how the URI is formed from these two components. 5. "Option 1: Devices that support DHCP MUST attempt to obtain the hostname of the outbound proxy during the DHCP process, using the DHCP option for SIP servers defined in [RFC3361] or [RFC3319] (for IPv4 and IPv6 respectively)." Presumably this domain name must then be used in forming the Request-URI. Needs more explanation. 6. "Option 2: Devices that support DHCP MUST attempt to obtain the local IP network domain" Presumably this domain is used in the domain part of the AoR. Needs more explanation. 7. "The device MUST set the Request URI to the user AoR". I can't figure out how this will work if the SUBSCRIBE request gets routed via a standard proxy. It seems it would get routed to any registered contacts for that AoR. Of course, if the user profile PDS is a registered contact, it will get sent there too. Without looking at the Event header field, it is impossible for a proxy to determine that such a SUBSCRIBE request requires special treatment. 8. "In the absence of a Server Identity authenticated TLS session with the next-hop SIP entity: o the device MUST NOT respond to any authentication challenges" The requirement to use TLS is only SHOULD, so if you don't use TLS, you can never respond to an authentication challenge. This doesn't make sense. 9. "the device MUST ignore any notifications containing sensitive profile data" How does the device know which data is sensitive? Is this something that has to be defined with each profile? If so, we need some statement. 10. "Once enrolled, the device obtains the initial notification. This is authenticated using two methods. If this initial notification was transmitted on the mutually authenticated TLS session established for enrollment requests, then it is considered authenticated" This only works if the TLS session is end-to-end, i.e., no proxy between the UA and the PDS. If there is a proxy, it is only the proxy that is authenticated, not the PDS. 11. "If the SIP Identity header is absent or the device cannot validate it" If the profile needs to be downloaded in order to install the CA certificate, the device will be unable to validate the server and we have a deadlock situation. 12. "If the SIP Identity header is absent or the device cannot validate it , the device MUST reject any sensitive profile data " Same comment about how sensitive profile data is identified. 13. "If the SIP Identity header is present, and the device cannot validate it, then it MUST reject the profile data and retry enrollment" This seems to contradict the previous sentence - two conficting actions for the case where cannot validate. 14. "or those in deployments where communication with the PDS in the absence of a mutually authenticated TLS is disallowed." Which hop are we talking about - device-to-proxy, inter-proxy, proxy-to-PDS? I guess there could be closed environments where it is known that all hops use TLS, or SIPS could be used to ensure this is the case. Seems to require more explanation. 15. "the PDS MUST set the host portion of the AoR in the 'From' header to the Provider's domain" What does it put in the user-info part? 16. "If known by the PDS and the notification will result in data specific to the user AoR, the PDS MUST challenge the request using Digest authentication specified in [RFC3261]" There needs to be some discussion about realm. Does the PDS necessarily use the same realm that the device uses with its domain proxy/registrar? 17. "If the device established TLS with the next-hop entity then any such notifications SHOULD be sent over the same TLS session by the PDS." We should not preclude multiple TLS sessions (in accordance with SIP-outbound) and should not preclude a TLS session having been re-established following loss of an earlier session. Furthermore, sending over the same TLS session from PDS to proxy does not guarantee it will be sent over the same TLS session from proxy to UA. Therefore what do we achieve by recommending it be sent over the same TLS session? 18. "If no such TLS session exists, the device MUST NOT accept any sensitive profile data without verifying the presence of, and validating, a SIP Identity header." The use of TLS is not necessarily a substitute for this, unless the TLS session is end-to-end, not via a proxy. 19. "Profile data that allows the end-user to communicate with the device or SIP service provider." It would be helpful to say "Profile data that allows the end-user to communicate by non-SIP means with the device provider or SIP service provider." 20. "* Profile data that redirects the device to an entity, such as the PCC, that can provide identity data." Where is this redirection mechanism specified? Or is it simply content indirection, as defined in this spec, in which case isn't this bullet redundant (because it is covered by the last bullet)? 21. " + If profile enrollment fails due to an explicit failure or a timeout as specified in RFC3261 = Continue with this function()" It is unclear what "continue with this function() means. Does it mean continue the inner loop (i.e., the next next-hop SIP entity? 22. "If a PDS wants to invalidate a profile it may do so by transmitting a NOTIFY with an 'empty profile' (not to be confused with an empty NOTIFY)." What is the syntax of an empty profile? Is it a requirement that each profile type must define a syntax that means the profile is empty? 23. "and add the "ob" parameter as specified in [I-D.ietf-sip-outbound] within the SIP SUBSCRIBE for profile enrollment." In sip-outbound, I can only find reference to use of "ob" in REGISTER requests. It appears to have no meaning in a SUBSCRIBE request. 24. "The "effective-by" parameter MAY be provided in the NOTIFY request for any of the profile types." What is required behaviour if this is omitted? 25. "The SUBSCRIBE SHOULD be either authenticated, or transmitted over an integrity protected SIP communications channel." An integrity protected SIP communications channel is not a substitute for authentication of the UA. 26. "If the specific user or device is unknown, the Notifier MAY either accept or reject the subscription." Do we wish to specify a response in the case of rejection, e.g., 403? 27. "the Notifier MAY either respond with profile data (e.g., default profile data) or provide no profile information (i.e. no body or content indirection)." Is "no profile information" the same as an "empty NOTIFY", as mentioned earlier? Use consistent terminology. 28. " If the URI in the SUBSCRIBE request is a known identity and the requested profile information is available (i.e. as specified in the profile-type parameter of the Event header)," Which URI in the SUBSCRIBE request are we talking about - the Request-URI, the From header field URI? 29. " If the SUBSCRIBE was received over an integrity protected SIP communications channel, the Notifier SHOULD send the NOTIFY over the same channel." This seems to violate RFC 3261 procedures, where a request to the dialog initiator should be routed to the first entry in the route set. So if the last proxy through which the SUBSCRIBE request passed does not record route, the NOTIFY request will not necessarily need to be routed to that proxy, and thus use of the same TLS connection will not be possible. Instead, normal RFC 3263 procedures should be used to route to the first element in the route set or, if no proxy has record-routed, directly to the remote UA. 30. "The subscription dialog MUST NOT be terminated by a NOTIFY with no body." Is "NOTIFY with no body" the same as an "empty NOTIFY", as mentioned earlier? Use consistent terminology. 31. "Both the examples are derived from a snapshot of Section 4.1" The word "snapshot" does not seem appropriate here (nor "snapshots" a little further one). 32. "The examples are purely informative and in case of conflicts with the framework or protocols used for illustration, the latter should be deemed normative." I cannot parse this. What does "the latter" refer to? There are three items: "the examples", the "framework" and "protocols used for illustration". If it refers to the last of these ("the protocols used for illustration"), the meaning is still unclear. 33. " +----------------------+ +--------+ | SIP Service Provider | | Device | | | |(SIP UA)| | SIP PDS HTTP | +--------+ | PROXY Server | | | +----------------------+" The PDS here is a device profile PDS (because the example shows a subscription to the device profile). Why is device profile PDS part of SSP? It could happen to be, but it doesn't seem a very good example. Better just to show the PDS, HTTP server and SIP proxy in separate boxes. 34. " | | | | | | | | | SUBSCRIBE | | | (SReq)|--------device profile--------->| | | | |------>| |" Why us device profile, rather than local-network profile, shown as the first subscription? 35. " Contact: sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB @example.com" The Contact URI and Request URI are the same. Doesn't make sense. 36. " NOTIFY sip:urn%3auuid%3a00000000-0000-1000-0000-00FF8D82EDCB @192.0.2.44 SIP/2.0" Presumably this is the URI that should have appeared in the contact header field of the SUBSCRIBE request. 37. "It then transmits the request, after establishing a TLS session if required. If obtained via a SIP proxy, the Request-URI is used to route it to a PDS (via an authoritative SIP proxy, if required)." What is "obtained via a SIP proxy"? 38. "When a PDS receives the enrollment request, it can either challenge the presented identity (if any) or admit the enrollment." What is the "presented identity"? 39. "The use of SIP Identity is useful in cases when TLS is not used but the device still obtains a profile (e.g., the local-network profile)." Identity is useful even when TLS is used, particularly if there is more than one TLS hop. 40. "In such cases the device provider, or the user, can use the SIP Identity header to verify the source of the local-network profile." The section concerned is to do with local-network profile, not device profile. 41. "Thus the framework requires that devices supporting any sensitive device profiles establish next-hop authenticated TLS connections prior to device enrollment." Next hop authenticated TLS is insufficient - some other means is needed to authenticate the PDS. 42. "If the user AoR is a SIPS URI then the device is required to establish a next-hop authenticated TLS session. This framework requires this for profiles with sensitive data". Requires SIPS, or requires next hop authenticate TLS? I can't find any MUST statements relating to this and sensitive data. You can still subscribe without TLS, but the device MUST ignore notifications with sensitive data.