Subject: RE: [Sip] SCTP and TLS

From: [email-masked]
Date: Tue, 25 Nov 2003 13:14:14 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of ext
> Cullen Jennings
> Sent: 25.November.2003 04:17
> To: Adam Roach; Vijay Gurbani; [email-masked]
> Subject: Re: [Sip] SCTP and TLS
> 
> 
> 
> sips means every hop needs TLS, transport=tls is about one 
> hop needing TLS.
> 
> transport=tls was deprecated in a SIPS uri (because it is 
> redundant there)
> but I don't believe it was deprecated in a SIP uri. I was 
> taking about the
> case of a sip uri.  Imagine A sends with a sip uri over UDP 
> to B with a
> preloaded route to C and A wishes to indicated that a TLS 
> protected protocol
> should be used from B to C. However C can send the message to 
> D any way it
> wants so we don't want to upgrade to a sips.

A can insert a route-header with a sips URI. What is wrong with that?

/Hisham

> 
> This is not an unreasonable scenario - A and D could be clients in an
> enterprise network that is protected in some way and B and C could be
> enterprise proxies that do TLS protection across the internet.
> 
> There is also the Via problem...
> 
> I see a few possibilities for this ... (yes and I agree with 
> Adam on the
> confounding of transport type and security type into one tag 
> was not the
> most elegant move but yet that is where we are)
> 
> We need to be able to indicate in the VIA what the protocol 
> is and also if
> TLS was used or not.
> 
> Solution A
> - define SCTPS to be SCTP with TLS and UDPS to be UDP with 
> TLS and let the
> via look like
> 
> Via: SIP/2.0/SCTPS pc33.example.com;branch=z9hG4bK776asdhds
> 
> Solution B
> - change the SIP in the via to be either SIP or SIPS and 
> treat this to be
> sort of like the SIP or SIPS in a NAPTR record
> 
> Via: SIPS/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds
> 
> Solution C
> - add a security tag that defines if security TLS is used or not
> Via: SIP/2.0/SCTP 
> pc33.example.com;branch=z9hG4bK776asdhds;security=TLS
> 
> There are backwards compatibility issues with all of these.
> 
> Next we need to be able to represent that we want security 
> for a single hop
> in a URI ( could be a request URI or route or others)
> 
> Solution 1
> make the transport tag be one of UDP, TCP, SCTP, DCCP and add 
> a security tag
> that could be TLS
> sip:[email-masked];transport=SCTP;security=TLS
> 
> Solution 2
> define some more transports of udp+tls sctp+tls, dccp, 
> dccp+tls. Note that
> tls alone means tls over tcp.
> sip:[email-masked];transport=SCTP+TLS
> Also a URL with transport=+TLS would mean that any transport 
> could be used
> but it must include TLS.
> 
> Given we have two security protocols (nothing and tls) and a 
> handful of
> transports (UDP, TCP, SCTP, DCCP) - Solution A and 2 could 
> work without an
> explosion of labels. Solution 1 is tricky to make sure no one 
> ever sends
> transport=tcp;security=tls to someone expecting 
> transport=tls. Solution B
> will no doubt break someone who gets a "Via: SIPS/2.0/TCP" on a TLS
> connection. Solution C would be the right things if we went 
> with Solution 2
> instead of Solution 1.
> 
> Sorry this is such a disorganized email. Thoughts?
> 
> Thanks, Cullen
> 
> 
> 
> On 11/24/03 8:50 AM, "Adam Roach" <[email-masked]> wrote:
> 
> > Vijay K. Gurbani [mailto:[email-masked]] wrote:
> > 
> >> I seem to recall that "transport=tls" was deprecated in favor
> >> of the sips URI which implies it.
> > 
> > Yes, this is precisely the correct answer to Cullen's question.
> > Section 26.2.2 of RFC 3261 addresses this:
> > 
> > Note that in the SIPS URI scheme, transport is independent of TLS,
> > and thus "sips:[email-masked];transport=tcp" and
> > "sips:[email-masked];transport=sctp" are both valid (although
> > note that UDP is not a valid transport for SIPS).  The use of
> > "transport=tls" has consequently been deprecated, partly because
> > it was specific to a single hop of the request.  This is a change
> > since RFC 2543.
> > 
> > Personally, I couldn't be more pleased, since calling tls a 
> transport
> > always puts my teeth on edge.
> > 
> > However, this leaves the issue of Via headers.
> > 
> > I can say:
> > 
> > Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds
> > 
> > Or:
> > 
> > Via: SIP/2.0/TLS pc33.example.com;branch=z9hG4bK776asdhds
> > 
> > But there is no standardized syntax that allows me to say
> > both at the same time.
> > 
> > /a
> > 
> > _______________________________________________
> > 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: Adam Roach <[email-masked]>
Date: Tue, 25 Nov 2003 23:10:08 -0600

Cullen Jennings [mailto:[email-masked]] wrote:

> There is not really any SCTP or TLS over SCTP or UDP or DCCP 
> deployed so I think we could be backwards compatible with
> existing TLS stuff. I'm not seeing a way to be backwards
> compatible with everything but the current stuff looks broken
> so I think the odds of something other than what is currently
> specified deploying are fairly high. This is not a "I don't
> like the current thing issues" this is the current thing can't 
> construct a usable via for a stateless proxy using SCTP with TLS.

Actually, I think we have a choice between backwards-compatibility
and elegance.

For example, we could choose designations like the following
for a sort of elegance:

UDP:       SIP/2.0/UDP
UDP+TLS:   SIP/2.0/TLS/UDP
TCP:       SIP/2.0/TCP
TCP+TLS:   SIP/2.0/TLS/TCP
SCTP:      SIP/2.0/SCTP
SCTP+TLS:  SIP/2.0/TLS/SCTP
DCCP:      SIP/2.0/DCCP
DCCP+TLS:  SIP/2.0/TLS/DCCP

Alternately, we could retain backwards compatibility (but have
people forever wonder about the TCP aberration) by using
designations like:

UDP:       SIP/2.0/UDP
UDP+TLS:   SIP/2.0/TLS/UDP
TCP:       SIP/2.0/TCP
TCP+TLS:   SIP/2.0/TLS
SCTP:      SIP/2.0/SCTP
SCTP+TLS:  SIP/2.0/TLS/SCTP
DCCP:      SIP/2.0/DCCP
DCCP+TLS:  SIP/2.0/TLS/DCCP

Because of practical considerations, I would propose that the
second approach is probably the best path forward.

/a

---

From: [email-masked]
Date: Wed, 26 Nov 2003 09:01:57 +0200

Why isn't it enough to state that if a request was received using TLS, the response must sent using TLS? It requires proxies and UASs to keep a state though.

Regards,
Hisham

> Adam Roach
> Sent: 26.November.2003 07:10
> To: 'Cullen Jennings'; Vijay Gurbani
> Cc: Adam Roach; [email-masked]
> Subject: RE: [Sip] SCTP and TLS
> 
>