Subject: Re: [Sip] SIPS question

From: Christer Holmberg <[email-masked]>
Date: Fri, 01 Nov 2002 08:12:37 +0200

Hi Arunachalam,

If there are no record routing proxies in the path, your second "rule" may
work just fine.

However, I am not sure your first "rule" would work when there are record
routing proxies. Like Hisham said, if UA2 has registered itself with P1 using
SIPS-URI, P1 will contact UA2 using SIPS-URI. Now, UA2 MUST insert SIPS-URI in
the Contact header, which again means that UA1 may end up in a situation where
the Request-URI for the next request is SIPS-URI, and according to the spec it
MUST now use TLS for that request - even if it doesn't support TLS, and even
if it's not going to use the Request-URI to route the message in the first
place.

Now, changing the text in the spec MAY help: the change would be that the UAC
does not make any transport based decissions based on the Request-URI, but on
the URI it actually uses to route the request (which of course MAY be the
Request-URI, but also the top Route).

I also think part of the basic problem is the fact that the URI may change
from SIP to SIPS in the signalling path. I don't think that is true for
HTTP/HTTPS, is it?

Thanks for your comments!

Regards,

Christer Holmberg
Ericsson Finland

Arunachalam Venkatraman wrote:

> Christer
> Interesting issue.
>
> How about this for a solution ---
> The UAS sends a SIPS URI in its Contact only if one of the following is
> true-
> 1. The top Route in its Route Set is a SIPS URI
> 2. If no Route set has been established, the Contact in the request is a
> SIPS-URI.
>
> In all other cases, it sends a SIP-URI in its Contact.
>
> Will this work?
>
> Venkat
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Christer Holmberg
> Sent: Thursday, October 31, 2002 6:43 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sip] SIPS question
>
> Hi,
>
> > > > > Hi,
> > > > >
> > > > > > I guess UA2 should have registered with P1 using a sips-uri
> > > > > in the contact-header. P1 doesn't care about the
> > > > > contact-header sent in the 200 OK. UA2 contact-header is
> > > > > telling UA1 (not P1) to contact it using TLS.
> > > > >
> > > > > No, but the Contact header value will be used in requests
> > > > > during the session, as part of the route set or Request-URI
> > > > > (depending on if loose routing is used etc)
> > > >
> > > > What I meant to say is that if UA2 had registered with P1
> > > using a sips-uri in the contact-header, then when P1 is
> > > routing the INVITE, it will put sips-uri in the record-route
> > > header since the request uri (retrieved from the registrar)
> > > is a sips-uri.
> > >
> > > > Since P1 contacted UA2 using sips, the 200 ok must contain
> > > a contact-header with sips-uri.
> > >
> > > Ok. So, in this case UA1 will receive a Record-Route with
> > > SIPS-URI. So, the next time UA1 sends a request the SIPS-URI
> > > indicates it shall use TLS - which UA1 may not even support.
> >
> > No, P1 will modify the record-route header in the response and will make
> it a sip-uri.
>
> > >And, since UA1 used SIP-URI in its own Contact header, P1
> > >shall use UDP (or TCP) to forward requests received from UA2,
> > >so now we would have the separate-transport-in-each-direction
> > >problem between UA1 and P1, wouldn't we?
> >
> > UA1 will have a different route-set that UA2.
>
> True.
>
> However, EVEN if UA2 has registered itself with P1 using SIPS-URI, and P1
> uses TLS to
> contact it, UA1 will still receive a Contact header with SIPS-URI, and
> according to the
> RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it would have to
> use TLS for the
> other requests, even if it doesn't support TLS, and even if the requests
> aren't even sent
> to UA2 (UA1 send them to P1, which record-routed).
>
> Regards,
>
> Christer Holmberg
> Ericsson Finland
>
> _______________________________________________
> 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
>
> _______________________________________________
> 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

_______________________________________________
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: [email-masked]
Date: Fri, 1 Nov 2002 11:43:40 +0200

> From: ext Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, November 01, 2002 8:13 AM
> To: Arunachalam Venkatraman
> Cc: [email-masked]

Yes, the problem is in the sentence in section 8.1.2

"Independent
   of which URI is used as input to the procedures of [4], if the
   Request-URI specifies a SIPS resource, the UAC MUST follow the
   procedures of [4] as if the input URI were a SIPS URI."

Why is that sentence there?

The original problem remains, and that is what if UAS decides it wants to use TLS when it receives an INVITE, my answer remains the same: reject the INVITE, but with which response code? How does UAC know that the UAS rejected the INVITE because it wants it over TLS?

/Hisham

---

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 2 Nov 2002 17:12:55 -0500

inline.

Jon Peterson
NeuStar, Inc.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Saturday, November 02, 2002 12:37 PM
> To: Peterson, Jon
> Cc: 'Anders Kristensen'; [email-masked]
> I think we have lost sight of the semantics of SIPS.
> 
> To me, SIPS is a way to tell a UA that ***the entire path*** was 
> hop-by-hop secured. If a UA cannot know this with certainty, and we 
> support these mixed scenarios, that devalues what sips is trying to do.

Actually, I recall our discussions of SIPS involving more than just
hop-by-hop-all-the-way scenarios - more than just the use of SIPS as an AoR.
Since we deprecated transport=tls, there is another reasonable application
of SIPS for characterizing particular hops that should go over TLS (we
discussed its use in Route headers, Contact headers, etc). The point is
using SIPS in the 'remote target' implies the e2e semantic, but its use
elsewhere has a different significance. There are plenty of reasons why we
might want individual hops to go over TLS, and SIPS is a reasonable way to
express this.

The problem is just that the text is a little schizo about how to
differentiate the use of SIPS as an AoR from the use of SIPS as an element
in a Route set, and that this confusion seems to have arisen from loose v.
strict routing.

> Secure on just some hops is the same is insecure, and therefore, not 
> useful.
> 

Obviously that's dependent on particular deployments. Some hops that a
request traverses might have different security requirements than others.
Only the SIPS AoR usage has the connotation that all the hops must be
secure.

> I also think it is a travesty to turn off loose routing to handle sips. 
> I am not convinced this is needed or wise.

I don't think I characterize it as a 'travesty', but I agree it is less
desirable, and it is unneeded. I suggested strict routing for SIPS only
based on my assessment of necessary textual changes, but after studying the
text for a while I agree we can probably salvage SIPS for lr.

> 
> I would prefer to add words which prohibit using sips at any hop unless 
> the previous was sips.
> 

This prohibits useful security functions that seem orthogonal to the
concerns Christer et al have raised.

> -Jonathan R.
> 
> Peterson, Jon wrote:
> > To be clear, that text in 26.2.2 is not normative, it is 
> merely descriptive.
> > The functional behavior of SIPS is specified elsewhere in 
> the document;
> > changing the wording of 26.2.2 does not change anything's behavior.
> > 
> > I maintain that the problem normative text in 8.1.2 (end of 
> 1st paragraph)
> > was most likely written without sufficient consideration of 
> loose routing. I
> > can assure you that we were quite mindful of your culprit 
> 2) below, and
> > considered it a desirable case (in which TLS rightfully 
> MUST be employed by
> > the UAC to contact the first hop). We weren't really 
> mindful of 1)... but
> > again, throughout this discussion it has been a little 
> unclear why a UA
> > would specify a URI in the Contact address in responses 
> that differs from
> > the Contact address it sends when it registers (we call 
> both of those things
> > by the same name for a reason); this has been something of 
> a corner case.
> > 
> > I agree that it would be unfortunate to throw away loose 
> routing for SIPS
> > entirely - when I suggested this was the simplest fix, I 
> meant simplest from
> > a specification perspective. I know the text in 8.1.2 is 
> bad, arguably
> > 26.2.2 needs to be changed, but I haven't been able to go 
> through the whole
> > spec (as well as RFC3263) and hunt for similar text... 
> mandating strict
> > routing provides a one-sentence band-aid. In the long run, 
> though, I agree
> > it would be better to fix all the places where there is 
> language contrary to
> > lr.
> > 
> > Finally, speaking to a point that has occasionally been 
> brought up in this
> > thread, RFC3261-compliant proxies MUST support SIPS. By 
> RFC3261, proxies
> > MUST support TLS, and TLS implementations MUST support SIPS. At a
> > specification level, it isn't clear to me that we need to 
> worry about
> > ascertaining proxy support for SIPS any more than we worry 
> about proxy
> > support for TCP. I don't think this part of the behavior is 
> broken, anyway.
> > 
> > Jon Peterson
> > NeuStar, Inc.
> > 
> > 
> >>From: Anders Kristensen [mailto:[email-masked]]
> >>Sent: Friday, November 01, 2002 12:51 PM
> >>To: Peterson, Jon
> >>Cc: 'Christer Holmberg'; Arunachalam Venkatraman; [email-masked]
> >>Wouldn't it be unfortunate if we were to downgrade an otherwise 
> >>all-loose routing signaling path to strict routing because of the 
> >>situation discussed here.
> >>
> >>I agree with Christer that the problem lies with the text 
> of section 
> >>26.2.2 which requires that the UAC use TLS even though it's 
> not routing 
> >>the request based on the R-URI but to the top Route. It seems that 
> >>26.2.2 didn't anticipate that 1) the scheme of the R-URI of 
> a subequent 
> >>request can be sips even though it was sip for the original 
> request, and 
> >>2) initial requests with a sips R-URI but a preloaded Route 
> whose top 
> >>URI is a sip URI. This last case could be common, for 
> example, in cases 
> >>where a service route has a sip URI top entry.
> >>
> >>Is there a problem in clarifying section 26.2.2 to say that 
> request is 
> >>sent using a transport of the top Route if there is one, or 
> else to the 
> >>R-URI? It seems more natural to use the properties of the 
> next-hop URI 
> >>that the request is in fact being sent to.
> >>
> >>It is clearly also the case, as Jon points out, that the 
> UAS should be 
> >>at least discouraged from using a sips Contact when the top 
> R-R isn't 
> >>sips (or it somehow *knows* that that proxy does in fact 
> support sips). 
> >>If the original request has a Record-Route header, I don't think it 
> >>should matter whether or not the UAC happens to support 
> sips or not - as 
> >>long as the upstream record-routing proxy does, that should 
> be enough, no?
> >>
> >>Anders
> >>
> >>
> >>Peterson, Jon wrote:
> >>
> >>>I think the problem with much of the language that has been 
> >>
> >>cited from
> >>
> >>>RFC3261 in this thread is that we expected SIPS to be 
> >>
> >>strict-routed. I don't
> >>
> >>>think any of these problems with intermediaries and 
> >>
> >>retargeting arise if
> >>
> >>>strict routing is used. Unfortunately, both loose routing 
> >>
> >>and SIPS arose
> >>
> >>>relatively late in the game for RFC3261, and we may not 
> >>
> >>have fully studied
> >>
> >>>their interaction.
> >>>
> >>>A few other notes about this thread:
> >>>
> >>>While I agree that HTTP R-U's cannot be retargeted to 
> HTTPS, I think
> >>>retargeting SIP to SIPS is attractive and workable, 
> >>
> >>provided strict routing
> >>
> >>>is used (or language is introduced to bring SIPS into 
> >>
> >>parity with loose
> >>
> >>>routing). It is desirable to be able to secure as much of 
> >>
> >>the communications
> >>
> >>>path as possible.
> >>>
> >>>The recipient of a request should be able to ascertain 
> >>
> >>whether or not the
> >>
> >>>request was retargeted to SIPS by checking to see if the To 
> >>
> >>header field
> >>
> >>>uses the SIPS scheme.
> >>>
> >>>Finally, when we were working on the design of SIPS, we 
> >>
> >>noted that there
> >>
> >>>were a class of problems that resulted from specifying 
> >>
> >>transport=tls (or any
> >>
> >>>optional transport, including =tcp and =sctp) in 
> >>
> >>Contact/Record-Route header
> >>
> >>>fields. Hence there is language in bis that says things like:
> >>>
> >>>         The [Record-Route] URI SHOULD NOT
> >>>         contain the transport parameter unless the proxy 
> >>
> >>has knowledge
> >>
> >>>         (such as in a private network) that the next 
> >>
> >>downstream element
> >>
> >>>         that will be in the path of subsequent requests 
> >>
> >>supports that
> >>
> >>>         transport.
> >>>
> >>>Similar language should probably be introduced for SIPS, 
> >>
> >>and the Contact
> >>
> >>>header.
> >>>
> >>>Anyway, for the time being, I suspect that the simplest bug 
> >>
> >>fix is to say
> >>
> >>>that whenever a route set or remote target for a dialog 
> >>
> >>contains a SIPS URI,
> >>
> >>>requests must be strict routed.
> >>>
> >>>Jon Peterson
> >>>NeuStar, Inc.
> >>>
> >>>
> >>>
> >>>>From: Christer Holmberg [mailto:[email-masked]]
> >>>>Sent: Thursday, October 31, 2002 10:13 PM
> >>>>from SIP to SIPS in the signalling path. I don't think that 
> >>>
> >>>>is true for
> >>>>HTTP/HTTPS, is it?
> >>>>
> >>>>>The UAS sends a SIPS URI in its Contact only if one of the 
> >>>>
> >>>>following is
> >>>>
> >>>>
> >>>>>true-
> >>>>>2. If no Route set has been established, the Contact in the 
> >>>>
> >>>>request is a
> >>>>
> >>>>
> >>>>>SIPS-URI.
> >>>>>
> >>>>>>>>>>I guess UA2 should have registered with P1 using 
> >>>>>>>>>
> >>>>a sips-uri
> >>>>
> >>>>
> >>>>>>No, P1 will modify the record-route header in the 
> >>>>>
> >>>>response and will make
> >>>>
> >>>>
> >>>>>it a sip-uri.
> >>>>>
> >>>>>
> >>>>>
> >>>>>However, EVEN if UA2 has registered itself with P1 using 
> >>>>
> >>>>SIPS-URI, and P1
> >>>>
> >>>>
> >>>>>uses TLS to
> >>>>>contact it, UA1 will still receive a Contact header with 
> >>>>
> >>>>SIPS-URI, and
> >>>>
> >>>>
> >>>>>according to the
> >>>>>RFC ("if the Request-URI is SIPS-URI, TLS MUST be used") it 
> >>>>
> >>>>would have to
> >>>>
> >>>>
> >>>>>use TLS for the
> >>>>>other requests, even if it doesn't support TLS, and even if 
> >>>>
> >>>>the requests
> >>>>
> >>>>
> >>>>>aren't even sent
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
>

---

From: [email-masked]
Date: Mon, 4 Nov 2002 16:08:09 +0200

Removing this restriction seems to fix the problem, I think.

"Independent

But also, would mandating that: if a REGISTER has a sips-uri contact, the To-header must contain a sips-uri work? and visa versa? 

eg: UA2 registers with sips-uri in both To-header and contact-header (sips in both or neither, but not mixed).

In this case, UA2 home proxy will reject the request with 404 if UA1 sends a request with sip-uri. UA2 can also reject the request directly if it doesn't want to accept requests not using TLS.

Regards,
Hisham

> Sent: Monday, November 04, 2002 1:55 PM
> To: Peterson, Jon
> > >Also, it's not only about mid-session requests, even if 
> that may be so in
> > >most cases. Assume the Request-URI for the initial INVITE 
> is SIPS-URI, but
> > the
> > >UAC uses an outbound proxy, ie using a pre-configured 
> Route with SIP-URI.
> >
> > The design of SIPS used as the 'remote target', as the AoR of the
> > destination, necessitates that this first hop go over TLS. 
> Look, as I said,
> > outbound proxies are proxy servers, proxy servers MUST 
> support TLS, and
> > entities that support TLS MUST support SIPS. Converting 
> this Route header to
> > a TLS route is plausible and allowed by the spec.
> 
> Yes, but the problem is again if the UAC doesn't support TLS. 
> Assume the UAC
> gets the Request-URI SIPS-URI from some "external source" 
> (ENUM, data base,
> whatever...), but since it uses an outbound proxy, using a 
> predefined Route with
> SIP-URI, it doesn't care about the Request-URI SIPS-URI.
> 
> I don't know if that scenario is "allowed" or not, but my 
> point was that the
> problem would be the same as for mid-session requests.
> 
> > We considered both transport parameters (transport=tls was 
> obsoleted in
> > favor of SIPS, as I'm sure you recall) and 
> Require/Supported option tags in
> > our deliberations about SIPS. The point is that we wanted a resource
> > identifier that indicates directly that it should be 
> contacted securely.
> 
> Another option would be that the URI in the TO header, which 
> IS end-to-end,
> would be used to indicate if to use TLS or not. That would 
> not allow that TLS is
> used between specific hops only, though.
> 
> Now, however, TLS would be used for the mid-session requests 
> EVEN if the record
> routing proxies insert SIP-URI in the Record-Route headers, 
> and/or the UAC
> inserts SIP-URI in the Contact header, since the TO header 
> URI would not change.
> 
> Now TLS would always be used for the whole session, and not 
> only for the INVITE,
> but I assume that is how most people intend to use it anyway. Or?
> 
> But, I still think the easiest fix would be to change the 
> text as proposed
> earlier. Then, we may have to write something about the 
> outbound proxy scenario
> - or use Jonathan's proposal to use TLS only if the previous 
> hop used TLS
> (assuming we want to use TLS end-to-end ONLY, that is).
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
>