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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Tue, 23 May 2006 10:22:48 -0400

Cullen,

There seems to be a dichotomy here between what could be termed "best
effort" security and "lock icon" security.  Given the weak link nature
of the former provided by sips, perhaps it might be useful to define a
new mode of operation for the latter, rather than try to reform the
already implemented former mode.

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

> -----Original Message-----
> From: Cullen Jennings (fluffy) 
> Sent: Monday, May 22, 2006 9:12 PM
> To: IETF SIP List
> Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines
> 
> 
> I think that we all agree that with sips you never know that 
> know if one of the proxies cheated and that you do not have 
> e2e security.  
> Sure e2e would be better but that's not what sips gives you.
> 
> I imagine that we might all be convinced that IP over Brinks 
> was equivalently secure to TLS.
> 
> The questions is, can we figure out how to specify SIP well 
> enough that we allow IP over Brinks and don't end up having 
> implementers implement something far weaker than TLS on every 
> hop. My point is, I don't think this is a questions about 
> absolute level of theoretical security that we can achieve, I 
> think it is a question about how good we are at writing 
> specifications for abstract security protocols (such as IP 
> over Brinks). Given that our previous attempt at specifying 
> sips clearly had some, ah, small holes in it, I initial gut 
> feeling is to write something very narrow, simple, and easy 
> to specify. Then as needs arise for sips to be transported 
> over something other than TLS, carefully extend the previous 
> RFC to cover the new secure transports. This could be all 
> wrong, perhaps we can get the more abstract version tightly specified.
> 
> Cullen
> 
> 
> 
> On May 17, 2006, at 3:28 PM, Dean Willis wrote:
> 
> >
> > On May 16, 2006, at 7:44 PM, Jonathan Rosenberg wrote:
> >
> >>
> >> 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
> >>
> >
> > So, how do you KNOW that TLS was actually used at each hop?
> >
> > Until you have a way to KNOW that it was, all you have is a 
> vague hope 
> > that the serving proxy to UA link was secured properly, and 
> no amount 
> > of "MUST" in the specification is going to change it. You'll have 
> > added feel-good words to the specification that don't 
> actually improve 
> > the security characteristics.
> >
> > Not only that, but you will have prevented "real deployable 
> security" 
> > where some links -- like UA to serving proxy -- are 
> actually secured 
> > by something like IMS-IPSEC. Net result, everybody will 
> just use sip:, 
> > and the security situation will actually degrade relative 
> to where it 
> > is today (where sips: works at least part of the time).
> >
> > 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.
> >
> > --
> > Dean
> >
> >
> > _______________________________________________
> > 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: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 24 May 2006 11:12:38 +0200

>a stake in the ground for what is needed to give end-users a true "lock

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 

> > So, how do you KNOW that TLS was actually used at each hop?
[...]
> > 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

---

From: "Nataraju A B" <[email-masked]>
Date: Wed, 24 May 2006 15:27:40 +0530

Comments inline...

Thanks & Regards,
Nataraju A.B.

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Wednesday, May 24, 2006 2:43 PM
To: Michael Hammer (mhammer); Cullen Jennings (fluffy); IETF SIP List
Subject: Re: [Sip] Comments on draft-audet-sip-sips-guidelines

>a stake in the ground for what is needed to give end-users a true "lock

This assumes that endpoints have suitable TLS certificates. In practice
this 
would be a problem.

[ABN] how about to have a combination of e2e and hop-by-hop trust
model...?

[...]

[ABN] Any way, every proxy will insert a via header while passing the
message downstream, if we mandate every proxy has to insert a some
parameter while forwarding a sips request. In this way we can make sure
@ the UAS, the request had been forwarded by a trustworthy proxy in
between...

Does this makes sense... ? 

> > 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