Subject: RE: [Sip] transport=tls

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 14 Mar 2002 11:26:15 -0600

Yes, SIPS is a TLS-specific mechanism. Similarly, HTTPS does not suggest
that a particular set of security principles have been upheld to secure the
traffic, rather, it is a TLS-specific mechanism. SIPS is a good thing
because it normalizes the security expectations of the sender and receiver
of a request; for example, it also entails the use of a particular
ciphersuite to secure the traffic.

Note that the 'path' in this instance refers to a collection of proxies
server, entities that MUST support TLS. Once a SIPS request has reached the
proxy server responsible for the destination domain, this TLS restriction
for forwarding to the next hop is lifted (Dean alluded to this in his note).
Presumably, end-users would have registered an appropriate contact address
with the domain's location service that reflects their security capabilities
and preferences; since UAs are not required to support TLS, this allows
security through some other means.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Thursday, March 14, 2002 7:24 AM
> To: Peterson, Jon
> Cc: 'Dean Willis'; Sean Olson; [email-masked]
> Subject: RE: [Sip] transport=tls
> 
> 
> Peterson, Jon writes:
>  > According to bis09, transport=tls has been deprecated. For 
> the purposes of
>  > backwards compatibility, the former transport=tls 
> mechanism would be treated
>  > roughly the same way as the SIPS URI scheme; the two 
> important differences
>  > are that transport=tls assumes TCP, and that a number of 
> specific rules have
>  > been mandated for handling the SIPS URI that presumably 
> wouldn't hold for
>  > transport=tls.
>  > 
>  > Either of the meanings that Dean alludes to below can be 
> expressed by the
>  > SIPS URI scheme in varying contexts. The use of SIPS in a 
> Request-URI
>  > mandates the latter meaning (use TLS for the whole 
> signaling path), while
>  > use in contexts such as a Record-Route, a Contact address 
> of a registration,
>  > or in a preferred NAPTR record can suggest to the use of 
> TLS over particular
>  > segments of a signaling path.
> 
>    So let me get this straight: an INVITE with
>    To: sips:...  should fail if somewhere along
>    the path the next hop is protected, but just
>    not with TLS? Somebody needs to remind why this
>    is a Good Thing. 
> 
> 	    Mike
> 

_______________________________________________
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: Michael Thomas <[email-masked]>
Date: Thu, 14 Mar 2002 11:13:34 -0800 (PST)

> ciphersuite to secure the traffic.

   Um, no it doesn't. All it says is that you must
   use TLS between each hop. There is nothing that
   says that if you use AES-256 and SHA2 on your
   first hop that you're going to get it on each
   subsequent hop. Indeed, since TLS allows
   anonymous clients, you're not even assured
   mutual authentication on each hop.

 > server, entities that MUST support TLS. 

   MUST support != MUST use.

		Mike