Subject: [Sip] WGLC comments on sip-sips

From: "Elwell, John" <[email-masked]>
Date: Mon, 09 Jul 2007 13:54:34 +0100

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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 16 Jul 2007 18:12:31 -0500

> -----Original Message-----
> From: Elwell, John [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 05:55
> To: Audet, Francois (SC100:3055); [email-masked]
> Subject: WGLC comments on sip-sips
> 
> 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
> 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.
> "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
> 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).

> 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.

> 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
> 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).

> 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
> 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

Same as 8.

> 10. "A registrar MUST only accept a binding to a SIPS Contact 
> header field

Same as 8.

> 11. In 4.2 "It is RECOMMENDED to use an outbound proxy as per 
> the procedures
> 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.

> 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
> 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".
> 

Yes, I'll fix.

> 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".
> 

I'll fix the nits.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 17 Jul 2007 10:01:09 +0100

Francois,

More below. I have stripped out the comments that have been
satisfactorily dealt with.

John 

> make the text even more heavy).
[JRE] OK, I can live with that.

> > Similar - should explain how this can occur.
[JRE] Ditto.

> p. 56. This is why it's in this section.
[JRE] OK, I don't like it, but I suppose you are correct. However, you
didn't respond to the second part of my comment, concerning the need for
a change of language. Thinking about this further, I now see that we are
in fact updating RFC 3608 - correct? If so, then don't we need to state
this up front, and also mention it in the Introduction section where we
mention RFC 3261?

> procedures of sip-outbound in a proxy is a proxy requirement, 
[JRE] The words "It is RECOMMENDED to use an outbound proxy" sound to me
like a recommendation on a UA, i.e., a recommendation that the UA be
configured to use an outbound proxy. Perhaps what we are trying to say
is "It is RECOMMENDED that a proxy be able to behave as an outbound
proxy as per the procedures...", in which case it would indeed belong in
this section.

> > server may not have any knowledge of a "target UAS".
[JRE] You didn't answer this or make any changes. Do you consider that
no change is necessary?

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 17 Jul 2007 14:03:23 -0500

Thanks John.

See below (I'm removing where we are in agreement). 

> Sent: Tuesday, July 17, 2007 02:01
> Subject: RE: WGLC comments on sip-sips
> 
> Francois,
> 

> field, the 
> > > Presumably the intention of this is to state that RFC 3608 places 
> > > such a requirement on registrars. The language needs changing to 
> > > reflect this.
> > 
> However, you didn't respond to the second part of my comment, 
> concerning the need for a change of language. Thinking about 
> this further, I now see that we are in fact updating RFC 3608 
> - correct? If so, then don't we need to state this up front, 
> and also mention it in the Introduction section where we 
> mention RFC 3261?

OK, I think you are right. It does in fact update 3608. I will fix it.

> > > 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.
> [JRE] The words "It is RECOMMENDED to use an outbound proxy" 
> sound to me like a recommendation on a UA, i.e., a 
> recommendation that the UA be configured to use an outbound 
> proxy. Perhaps what we are trying to say is "It is 
> RECOMMENDED that a proxy be able to behave as an outbound 
> proxy as per the procedures...", in which case it would 
> indeed belong in this section.

Ok, I'll fix as per your suggestion.

> > >    redirect server MAY redirect with a 3XX response to 
> either a SIP 
> > > or a
> > > server). In other words, the redirect server may not have any 
> > > knowledge of a "target UAS".
> [JRE] You didn't answer this or make any changes. Do you 
> consider that no change is necessary?

Sorry, I missed that. I guess in that case you can redirect to whatever
you want. 
I'll make some changes.