In general this is now in excellent shape. Just some detailed comments. 1. "It also makes normative changes to SIP". If so, then it should state on the front page that it updates RFC 3261.
2. In 3.1.1 "In this model, only the TLS server provides a certificate during the TLS handshake. Often, a proxy (which may or may not be the one terminating the TLS connection) authenticates the client by using the SIP HTTP digest. In this model, the UA is the TLS client side, and the Proxy is the TLS server side." The words "the Proxy" in the third sentence would appear to refer to "a proxy" in the second sentence, but that doesn't make sense. Also I think this is trying to say that the server-provided certificate can only apply between a UA and a proxy and when the UA is the client, so it can't apply between proxies and it can't apply when a proxy is a client. If so, to solve these two issues, perhaps it should say. "In this model, only the TLS server provides a certificate during the TLS handshake. This is applicable only between a UA and a proxy, where the UA is the TLS client and the proxy is the TLS server, and hence the UA uses TLS to authenticate the proxy but the proxy does not use TLS to authenticate the UA. If the proxy needs to authenticate the UA, this can be achieved by SIP HTTP digest authentication." 3. In 3.1.2 "In this model, both the TLS client and the TLS server provide a certificate in the TLS handshake phase. When no TLS connection is in place, the UAC would therefore take on the role of the TLS Client and the UAS would therefore take on the role of the TLS server." This seems to limit mutual TLS (more correctly TLS mutual authentication) to use involving a UA, but it also has an important use between proxies (this is not mentioned until further down). Also the second sentence seems to suggest a direct TLS connection between UAC and UAS, which is possible but not the typical case. Where at least one proxy is involved in the signalling path, if there is not already a TLS connection in place between the UAC and the first proxy, the UAC would take on the role of TLS client and the first proxy would take on the role of TLS server. Likewise, if there is not already a TLS connection in place between the last proxy and the UAS, the last proxy would take on the role of the TLS client and the UA would take on the role of the TLS server. I think this needs to be explained more fully. Perhaps we need to say something like: "In this model, both the TLS client and the TLS server provide a certificate in the TLS handshake phase. When used between a UA and a proxy (or between two UAs), this implies that a UA must be in possession of a certificate. When sending a SIP request when there is not already a suitable TLS connection in place, a UAC takes on the role of TLS client in establishing a new TLS connection. When establishing a TLS connection for receipt of a SIP request, a UAS takes on the role of TLS server." 4. "While guessing a SIPS AOR from a known SIP AOR and using it to initiate a request is a valid thing to do, doing the opposite (i.e., guessing a SIP AOR from a SIPS AOR and using it) is not a valid thing to do as it would be a security downgrade." I would not go as far as saying it is not valid. It is merely undesirable, but if the caller's UA does not support the SIPS scheme, that might be a valid way of contacting the desired user. 5. "Although "downgrading" from SIPS to SIP is disallowed," As mentioned above, I think it is valid but undesirable for a user to downgrade by guessing. However, I think what we are talking about here is downgrading by a proxy, so perhaps that should be made clear by saying: "Although "downgrading" from SIPS to SIP is disallowed at a proxy,". 6. In 4.1 "If a UAS does not wish to be reached with a SIPS URI but only with a SIP URI, it SHOULD respond with a 418 (SIPS Not Allowed)." If the UA does not wish to be reached with a SIPS URI, then surely it would not register a SIPS contact. If the UA has not registered a SIPS contact, it should not normally receive a SIPS request. So presumably this is required only for requests reaching the UA without going through the domain proxy. Correct? If so, perhaps some explanation is needed. 7. "UAS that do not support the SIPS URI scheme altogether "SHOULD reject the request with a 416 (Unsupported URI scheme) response" as described in [RFC3261]/8.2.2.1." Similar - should explain how this can occur. 8. In 4.1.1 "If a UA registers with a SIPS Contact header field, the registrar returning a service route [RFC3608] MUST return a service route consisting of SIP URIs if the intent of the registrar is to allow both SIP and SIPS to be used in requests sent by that client. If a UA registers with a SIPS Contact header field, the registrar returning a service route MUST return a service route consisting of SIPS URIs if the intent of the registrar is to allow only SIPS URIs to be used in requests sent by that UA." Because 4.1.1 is part of 4.1, which deals only with UAs, then it should not contain normative requirements on registrars. Presumably the intention of this is to state that RFC 3608 places such a requirement on registrars. The language needs changing to reflect this. 9. "However, the registrar MUST treat the SIP and SIPS schemes of the AOR the same way (i.e., it MUST not care if it is SIP or SIPS)." This is a requirement on the registrar and does not belong in 4.1. 10. "A registrar MUST only accept a binding to a SIPS Contact header field if all the appropriate URIs are of the SIPS scheme, otherwise there could be an inadvertent binding of a secure resource (SIPS) to an unsecured one (SIP). This includes the Request-URI, the Contacts and all the Path headers, but does not include the From and To headers. If the URIs are not of the proper SIPS scheme, the registrar MUST reject the REGISTER with a 419 (SIPS Required)." These are requirements on the registrar and do not belong in 4.1. 11. In 4.2 "It is RECOMMENDED to use an outbound proxy as per the procedures defined in [I-D.ietf-sip-outbound] for supporting UACs that can not provide a certificate for establishing a TLS connection (i.e., when server-side authentication is used)." This is a recommendation on a UA, not a proxy, so it does not belong as a normative statement in 4.2. 12. In 4.3 "A redirect server would not be usable if server-side authentication is used" This is incorrect. If a UA has a certificate it can provide TLS server-side authentication, yet a redirect server could still be used in this case. I think this is trying to say that a redirect server cannot be used to redirect to an entity (e.g., a UA) that does not have a certificate. 13. "When a redirect server receives a request with a SIP Request-URI, the redirect server MAY redirect with a 3XX response to either a SIP or a SIPS Contact header field. If the target UAS had registered previously using a SIPS Contact header field, the redirect server SHOULD return a SIPS Contact header field if it is in an environment where TLS is usable (as described in the previous paragraph)." This assumes that a redirect server is redirecting directly to a UA, i.e., to a contact. However, a redirect server can also redirect to another AoR that resolves to a domain proxy (or another redirect server). In other words, the redirect server may not have any knowledge of a "target UAS". 14. In 5.2 "Furthermore, the offending SIPS URI(s) may be in any location in the request (e.g., the Request-URI, a Contact header field, a Refer-To URI, etc.)." Shouldn't this say "the offending SIP URI(s)"? 15. In the example in 6.3, proxy A and proxy B violate the recommendation in 4.2 to route SIP requests over TLS. This doesn't seem to be a very good example! It would be better to show routing over TLS from proxy A onwards. 16. "7. Conclusion" Most of the content of this section consists of further considerations, rather than conclusions drawn from previous sections. So perhaps the title should be "Further considerations". 17. NITS - In 6.1 "This call flow". There is no call flow - the flow shows only registration. - There are instances of a SIP method name (e.g. REGISTER) being used alone without being followed by "request". - There are instances of "header" being used instead of "header field". John _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
