Subject: RE: SIPS related clarifications (was: [Sip] SIPS question)

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 2 Dec 2002 08:09:30 -0500

We did discuss this issue a bit in Atlanta. Unfortunately, I think all we
agreed on is that we all need to think about it some more.

Some more specific suggestions are offered below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 28, 2002 7:09 AM
> To: [email-masked]
> Subject: SIPS related clarifications (was: [Sip] SIPS question)
> 
> 
> 
> 
> 
> Hi all,
> 
> There were couple of interesting questions raised in
> this thread by Christer earlier this month that perhaps
> got left out in the middle of the conversation. Wanted
> to get my understanding regarding inter-mingling of
> "sip:" and "sips:" URLs within the spec clear. Sorry
> if any questions had got resolved earlier and I missed
> the mail as I'm entering the discussion late. Any
> pointers are welcome.
> 
> * Is it allowed for a SIP proxy that got a request on
>   TLS to forward the request downstream on a non-TLS
>   protocol? 

Depends on what you mean by 'got a request'. This also doesn't say whether
or not SIPS appears in the Request-URI or not; it is possible for a proxy
server to receive a request over TLS that does not have the SIPS URI scheme
in the Request-URI.

> Jon Peterson had suggested that "sips" was
>   designed to allow selective hops in the path to be
>   secure,

I suggested that SIPS could appear, for example, in a Route header, in which
case it would only be intended to secure a particular hop.

>  while Rosenberg had mentioned that the presence
>   of "sips:" should imply that the end-to-end path is
>   secure.

If SIPS appears in the Request-URI of the original request sent by the UAC,
it implies this end-to-end path security.

I don't think these two ways of using the SIPS URI are mutually exclusive -
we don't have to say that SIPS is only usable in one or the other of these
contexts.

>  I guess the way I understand the spec stands
>   at present is that if the Req-URI is re-written to a
>   "sips:" URL at any stage of the routing, then any hop
>   downstream _from_this_hop_onwards_ has to forward the
>   request on TLS.

I agree, that is how we should understand it - with the caveat that SIPS
only applies to the entire path until it reaches the domain indicated by the
hostname portion of the Request-URI. Once a proxy server in the destination
gets hold of the request, it can retarget it arbitrarily (to non-SIPS
resources, if it wishes).

Also note that proxies should not 're-write' the Request-URI of a SIP
request at just any stage of the routing. In fact, there are rules in
RFC3261 about when the Request-URI can be retargeted, and they are somewhat
restrictive.

>  The entire path (from UA to UA) need
>   not be secure. Is this correct?

Yes.

>  Or can the request
>   path be set-up with some hops on TLS and others on
>   non-TLS in any combination of them?
> 

Not when the Request-URI contains a SIPS URI.

> * What is the response code to be used by a UAS to
>   inform the UAC that it is not willing to accept
>   insecure calls and that the UAC should retry the
>   request on TLS?
> 

Although 416 might look like an attractive candidate, the language in
8.1.3.5 makes it a little ugly. I would suggest 403.

> * Also, another question Christer had raised in the
>   discussion was end-points should not be allowed to
>   send REGISTER with AoR as "sip:" and Contacts as "sips:"
>   since end-to-end security (if that's what "sips:"
>   implies always) would not be assured if a request
>   for that end-point came with Req-URI of "sip:". Is
>   this the case?
> 

Mr. Holmberg's cases got a lot nastier than that - for example, if I use a
SIP URI scheme in the Contact header I send when I register, but a SIPS URI
scheme in the Contact header that I send in (say) 200 OK responses to
requests. This creates some tricky cases, ones we are still mulling, I
think. Just for the sake of simplicity, it might be nice to forbid this, but
the spec doesn't forbid it today.

> * Finally, the conclusion of the earlier thread seemed
>   to be that the last sentence of Section 8.1.2
>   (paragraph 1) is incorrect and the UAC's choice for
>   the transport protocol should not rest on the req-uri's
>   scheme being "sips:" alone. But this was not logged
>   into bugzilla for resolution? Did I miss something?
> 

I think we do need to fix the 8.1.2 text, yes. We should log this into
bugzilla. I think the only reason this may not have happened yet is that the
answer to all of this may rest on some more fundamental principles that we
want to consider further before we propose any new language. 

> Thanks for your time.
> 
> Regards,
> Siddharth.
> 
> --------------------------------------------------------
> Siddharth Toshniwal
> Hughes Software Systems
> Prestige Opal                    http://www.hssworld.com
> 146, Infantry Road          Ph (O): +91-80-2286390 (7094)
> Bangalore-560001, India           Mobile: +91-9845154068
> --------------------------------------------------------
> 
> 
> _______________________________________________
> 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