Subject: [Sip] Comments on draft-audet-sip-sips-guidelines

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 16 May 2006 20:44:04 -0400

Francois,

Thanks a lot for taking a stab at this. Its long overdue.

I have lots of comments and thoughts on this, but wanted to start with 
some high level issues that I think we need to agree on.

Firstly, I think that the sips mechanism is both underspecified and 
broken. Its broken because there are really no guarantees with it at 
all. As you point out, a UAS that receives a request with r-uri that is 
sips can't REALLY tell if it was TLS all the way (since it might have 
been upgraded). Furthermore, TLS is not strictly required, and thus its 
not clear what the guarantee actually is. I think we first need to fix 
this problem.

I'd propose that, to be useful, sips has to do as it implies - it means 
that each and every link from UAC to UAS was secure. This means two things:

1. SIPS requires the usage of TLS at every hop - none of this weasel 
words on IPSec

2. there is no upgrading or downgrading, period

With these two rules, it becomes much clear what kind of benefits are 
provided by sips. Every hop is secure with TLS, period. No ifs, ands or 
buts about it. If a UAS gets a request and the r-uri is sips, it means 
every hop was TLS. If it gets a request and the r-uri is sip, there is 
no guarantee about whether the hops were secure (they may or may not 
have been).

It also helps clarify the distinction between sips and transport=tls. 
Namely, transport=tls just means that a particular hop uses TLS. It 
implies nothing about the security of links upstream or downstream to 
it. sips, however, implies that every single hop towards the resource 
was secure.

Moving on to some of the details, I think we can simplify the 
registration procedure further. I would propose that it is never 
necessary to include separate contacts for sip and sips. If a 
registration is sent such that each hop was over TLS (done by having the 
r-uri in the registration be a sips URI), then that contact (and the 
associated secure path URI) can be used for requests sent to sip or sips 
AOR. If a request is sent to a SIPS AOR, the proxy sets the r-uri to a 
sips version of the contact. If a request is sent to a SIP AOR, the 
r-uri is a sip version of the contact.

Thoughts?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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

co.com; i=[email-masked];
	z=From:Jonathan=20Rosenberg=20<[email-masked]>
	|Subject:Comments=20on=20draft-audet-sip-sips-guidelines;
	X=v=3Dcisco.com=3B=20h=3DR0umInZz2wHkMXhC3KWPWOAbKy4=3D;
	b=POz4o+w0H/SYKMtcn+oURNZkK0Ig73VplwicY9J1vYA8yg8fFFZRLhqLbMJnYuMFpOtWgl3M
	B5sN7dzG0vVsD2Fp+diwQFGWdWLI03nz48TCV8IyeDw4Rvo/KafS84nt;
Subject: [Sip] Comments on draft-audet-sip-sips-guidelines

Francois,

Thanks a lot for taking a stab at this. Its long overdue.

I have lots of comments and thoughts on this, but wanted to start with 
some high level issues that I think we need to agree on.

Firstly, I think that the sips mechanism is both underspecified and 
broken. Its broken because there are really no guarantees with it at 
all. As you point out, a UAS that receives a request with r-uri that is 
sips can't REALLY tell if it was TLS all the way (since it might have 
been upgraded). Furthermore, TLS is not strictly required, and thus its 
not clear what the guarantee actually is. I think we first need to fix 
this problem.

I'd propose that, to be useful, sips has to do as it implies - it means 
that each and every link from UAC to UAS was secure. This means two things:

1. SIPS requires the usage of TLS at every hop - none of this weasel 
words on IPSec

2. there is no upgrading or downgrading, period

With these two rules, it becomes much clear what kind of benefits are 
provided by sips. Every hop is secure with TLS, period. No ifs, ands or 
buts about it. If a UAS gets a request and the r-uri is sips, it means 
every hop was TLS. If it gets a request and the r-uri is sip, there is 
no guarantee about whether the hops were secure (they may or may not 
have been).

It also helps clarify the distinction between sips and transport=tls. 
Namely, transport=tls just means that a particular hop uses TLS. It 
implies nothing about the security of links upstream or downstream to 
it. sips, however, implies that every single hop towards the resource 
was secure.

Moving on to some of the details, I think we can simplify the 
registration procedure further. I would propose that it is never 
necessary to include separate contacts for sip and sips. If a 
registration is sent such that each hop was over TLS (done by having the 
r-uri in the registration be a sips URI), then that contact (and the 
associated secure path URI) can be used for requests sent to sip or sips 
AOR. If a request is sent to a SIPS AOR, the proxy sets the r-uri to a 
sips version of the contact. If a request is sent to a SIP AOR, the 
r-uri is a sip version of the contact.

Thoughts?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: "Samir Srivastava" <[email-masked]>
Date: Wed, 17 May 2006 13:40:29 -0500

On the other hand, what would be more useful would in fact be an end-
to-end assertion about what level of security the UAS can count on.

SS>> I am working on a proposal where UAC states what cipher suites it
needs in the path with the qValues in a header. UAC puts required
cipher-suites with Proxy-Require and Require option tags. If the UAC
desired level of security is not provided in the path, request is
rejected by the proxy which is reached with the desired level of
security. UAC can decide what to do if desired level of security is not
provided end to end. It proposes to include the ciphersuites in the via
header too for the UAS Knowledge. 

Thx
Samir

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 24 May 2006 09:47:38 -0400

Jeroen,

Your solution changes the problem of an endpoint having a suitable TLS
certificate to being sure that every proxy on the path has a suitable
certificate.  If an endpoint doesn't have a certificate, then it is not
very robust in supporting real security.  The solution you suggest seems
to devolve into the solution I suggested as proxies are removed.  Adding
more players into the chain only weakens security.  Reducing middlemen
strengthens it.

I do like the idea of Proxy-Requiring well specified behavior.  I just
wonder if the signed object should include both forward and backward
pointers to proxies in the chain.

Mike

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Wednesday, May 24, 2006 5:13 AM
> To: Michael Hammer (mhammer); Cullen Jennings (fluffy); IETF SIP List
> Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines
> 
> >For example, the new mode could require that only redirect 
> servers be 
> >used so that the UAC and UAS (no B2BUAs allowed) be able to 
> establish a 
> >direct signaling connection over TLS.  Of course there would 
> be other 
> >details of such an architecture to work out, but at least this would 
> >put a stake in the ground for what is needed to give 
> end-users a true 
> >"lock icon" option.
> >
> >Mike
> 
> This assumes that endpoints have suitable TLS certificates. 
> In practice this would be a problem.
> 
> What we could do, is turn the current transitive trust model 
> into an end-2-end verifiable trust chain:
> 
> > > So, how do you KNOW that TLS was actually used at each hop?
> [...]
> > > TLS works with HTTP because it works end-to-end, tunneling
> > through the
> > > HTTP proxies. If a proxy cheats and acts like a B2BUA for 
> TLS, the 
> > > client can check the cert-name and detect the 
> misbehavior. But with 
> > > sips:, we have no way for the UAC to "check up" on the proxies.
> > >
> > > For sips: to give the kind of security assurance you seem
> > to want, it
> > > has to work end-to-end "through" the proxies, like https: does.
> 
> A mechanism could work as follows: UAC inserts a 
> 'Proxy-Require: trust' into its request. This requires that 
> every proxy on the path adds information to its Record-Route 
> header, namely a link to where its certificate can be 
> obtained, and proof that it owns that certificate (e.g. by 
> signing something including its RR-URI and the Call-ID with 
> the private key of the
> certificate)
> 
> Both peers can then go and inspect every certificate in the 
> proxy chain, to verify if they trust all proxies ("check up" 
> on them). They still would not KNOW that TLS was used, but 
> based on this established trust they may assume that the 
> proxy will do the right thing
> 
> Regards,
> 
> jeroen
>