> -----Original Message----- > From: Elwell, John [mailto:[EMAIL PROTECTED] > Sent: Monday, July 09, 2007 05:55 > To: Audet, Francois (SC100:3055); [email protected] > Subject: WGLC comments on sip-sips > > 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.
Agreed. Will change. > 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." Yes, much clearer. I'll fix. > 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." Yes, much clearer. I'll fix (but I'll keep the last sentence of the paragraph). > 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. Ok, will change. > 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,". Ok, will change. > 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. The main use case is for endpoints that don't register (e.g., gateways). Furthermore, this is written from the UA point of view and thus it could happen in error scenarios. I'm not sure explaining this will help, but I can add it if the groups feels it is necessary (I personally think it will just make the text even more heavy). > 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. Same as above. > 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. Actually, Registrars are "a special type of UAS" according to RFC 3261 p. 56. This is why it's in this section. > 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. Same as 8. > 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. Same as 8. > 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. I'm not sure I agree on this. Seems like the decision to use or not the procedures of sip-outbound in a proxy is a proxy requirement, not a UA requirement. > 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. Correct. I'll fix. > 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)"? Yes, I'll fix. > 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. I'll put some wording around this (i.e., go look at 6.4). > 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". Ok. I'll change it. > 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". I'll fix the nits. > 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
