Subject: Re: Wacky thead of the month award goes to ... Re: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips

From: Cullen Jennings <[email-masked]>
Date: Wed, 31 May 2006 21:57:43 -0700

Excellent question (definitely falls in my not wacky category)

On May 30, 2006, at 6:17 AM, Michael Thomas wrote:

> Cullen Jennings wrote:
>
>> sips is not the answer to every problem.
>
> My question is whether it's answer to _any_ problem. My last  
> attempt at
> getting and answer was fruitless. What attacks do SIPS thwart in  
> real life
> that honest operators and transport=tls doesn't? Real life good  
> guy, bad guy
> situations would be helpful.
>
>       Mike

I agree with your comment that as long as people can't say what they  
are trying to accomplish, saying sips does or does not meet that is  
pretty meaningless.

The problem with transport=tls is that it only applies to one hop and  
has no semantics that it get applied to the retarget. If it did, then  
it would mean about the same as sips.

I think it is fairly clear there are cases where you want to make  
sure each hop is confidential protected and it is reasonable to trust  
the proxies. Let me provide a simple example. In several cases we end  
up using the to and from tags as cryptographic tokens that can be  
used for authorization. For example, the typical way an INVITE with  
replaces is authorized to replace an existing call is that the new  
INVITE knows the to and from tag of the old call. sips can provide a  
way to stop some attacker on the network form leaning these. (or just  
learning what 1-900 numbers I was calling ). It's pretty easy for the  
UAC to control the protection on the first hop. However, it needs a  
way to signal that the future hops are also protected. SIPS is used  
to signal that. Now you could argue that there could have been  
several other ways to signal this and I would agree. But I think  
there are plenty of practical threats where you can show that being  
able to signal this, and assuming proxies did the right thing, you  
can stop the attacks with this. An alternative design would be just  
say all connection MUST be protected. (Forgive my use of protected  
here, I understand how imprecise I am being but I think you follow  
what I mean). Then you would not need to signal that future hops  
needed protection but people were not willing to accept that for all  
case.

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Wed, 31 May 2006 22:00:57 -0700

On May 30, 2006, at 2:35 PM, Dean Willis wrote:

> On May 30, 2006, at 12:02 AM, Cullen Jennings wrote:
>>
>> I think that at the high level, the semantics of sips are simple.  
>> We want it to mean that every hop from the UAC to the UAS was  
>> integrity and confidentiality protected at a reasonable level  
>> assuming transitive trust. This can be very useful. At the more  
>> fine details level, we have some parts that are unclear in how to  
>> implement it, we probably have some bugs in the spec, and perhaps  
>> we even one place where we made a bad choice that we may correct.  
>> I'm very keen on this draft - I want it to try and sort out the  
>> details that are missing or wrong.
>>
>
>
> "Correcting" the "bad choice" in the proposed way would be counter  
> to the semantics you give above.
>
> It's been proposed that we should change RFC 3261 to require that,  
> if sips: is used, then TLS MUST be used on all hops. This runs  
> afoul of architectures where some other mechanism, notably IPSEC,  
> is used on some hops.
>
> If we make this proposal a requirement, we end up in in a situation  
> where we frequently cannot use sips: on the UAC to serving-proxy  
> hops because some other security mechanism is used on the back side  
> of the serving proxy. And since sips: is the only "please secure  
> me" indicator we have, this means that we have no way to request  
> any security treatment at all in this situation -- in short, that  
> we're requiring people to NOT secure some links.
>
> This doesn't sound particularly rational.

Yes, the key thing we might want to change would be what happens on  
the link from the callees "home proxy" to to the UAS. We could decide  
that on this link sips means

a) some unspecified secure things
b) tls
c) tls or ipsec

Right now we have a - I suspect that we might want b or c. I think  
this is one of the key issues we need to sort out.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 31 May 2006 22:01:28 -0700

this reply is not really all that relevant, I don't know why I am  
sending it but I will :-)

On May 30, 2006, at 2:35 PM, Dean Willis wrote:

> But in any case, sips: remains only a marginal indicator of  
> security. It's kind of like a note by the door of the office that  
> says "Last one out, please lock the door". If somebody forgets, or  
> choses not to, the door isn't locked, and nobody else knows.

Most security is only as strong as the weakest link and often no one  
knows when the weakest link has failed. I don't know why you use the  
word "indicator", if we think that sips is somehow a indicator to end  
users that they get something like an end users might think of as  
"secure", then clearly sips does not provide that.

> It's not the lack of security that gets me -- it's the lack of  
> KNOWING that there is no security. Our current usage of sips: is no  
> more secure and generally applicable to the Internet than the trust- 
> domain protections around the privacy of P-Asserted-Identity are,  
> and we made that a P-header.

I think there are some significant differences here. RFC 3325  
requires that you have contracts between two parties that are using  
this (the SPEC(T)) or you can be in violation of privacy laws in  
several countries. There is no case where you need a contract between  
two domains doing sips. It true that you can only trust things in so  
much you trust the person you contact. That is the nature of  
communications - just because you can perfectly encrypt your email to  
me does not mean I don't print it out and pin it the bathroom wall.

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 31 May 2006 22:17:01 -0700

Agreeing with Mike here....

Hypothetically, if we were going to write a BCP that said described  
when a phone should display a "lock icon" to the end user, well that  
would be a useful document to have and clearly it would not be the  
same as you display this when you have a sips URI.

My personal opinion is that we don't quite have all the building  
blocks in place yet to be able to do this yet. We have tls, sips,  
srtp, and Identity, but I think we need a little more on the SRTP key  
negotiation.

On May 31, 2006, at 4:38 PM, Michael Thomas wrote:

> You're undoubtably right -- I've been wondering about this -- so  
> let me say that
> my problem is with anything that supposedly dictates security  
> beyond what the
> next hop is but cannot be verified by the would be dictator.
>
> Barring end to end security of some form, anything that purports to  
> elevate the
> authenticity and/or confidentiality of the signaling is bound to be  
> misinterpretred,
> and that's what sips real sin is. If this is really a BCP -- which  
> I'm becoming
> convinced is the only way to reasonably sell -- not oversell --  
> this desire, then
> we should work in that direction. Signaling for security that one  
> has no means
> of verifying is just plain dumb.
>
>       Mike

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 31 May 2006 22:41:54 -0700

On May 31, 2006, at 7:35 AM, Robert Sparks wrote:

> There _is_ a way to tell the next hop to use TLS (or whatever  
> protocol)
> using 3263, so "next hop" probably isn't the real motivation for  
> the continued
> existence of transport=tls in the wild.

Agree with what you are saying but want to point out there are two  
sides of the connection.

Hop A is forming a connection to Hop B. Hop A might prefer no TLS,  
prefer TLS, or require TLS. Similarly with B. B could express what it  
wanted with DNS. However, A can not express it's reference using DNS.  
A could have a some field that the application passed down to the  
stack that told the stack what A wanted set up  but I think some  
people found transport=tls a convenient way to pass this "tls  
required" flag along with the URI and let the stack figure it out at  
the bottom of the application.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 1 Jun 2006 08:40:25 +0300

Rohan Mahy writes:

 > On the contrary Juha, the SIP server role can indicate it wants to the
 > client to use TLS by including the appropriate NATPR and/or SRV
 > records.

for clients, proxy usually supports all common transport modes has
NAPTR/SRV records for them all.  now if another proxy (e.g. trusted
peer) talks to this proxy, it may want to FORCE transport to be tcp+tls,
and thus adds transport=tls uri parameter to the request-uri before it
gives the request to the transaction layer for processing.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 1 Jun 2006 08:52:26 +0300

> the bottom of the application.

thanks cullen, it is this A preference thing that i have trying to
explain in my messages too.  today transport=tls is the only way known
me on how to indicate it.  if no other means exists and since there is a
clear need, we need de-deprecate transport=tls officially or make it
less ambiguous as transport=tcp+tls.

-- juha

---

From: Michael Thomas <[email-masked]>
Date: Thu, 01 Jun 2006 07:59:41 -0700

Cullen Jennings wrote:

>> My question is whether it's answer to _any_ problem. My last  attempt at
>> that honest operators and transport=tls doesn't? Real life good  guy, 
>> bad guy
> the proxies. 

Well, SIPS is _clearly_ not up for that task. But what about lazy, 
indifferent or
incompetent proxies? That is, IMO, the real threat. All of this division 
into
"trusted" and "evil" proxies doesn't cover the full range of 
possibilities in the
real world. Do I trust a service provider proxy for example? Defining 
"trust"
as "won't turn this message over to the NSA", then clearly I don't even 
if I
trust them to route the message correctly.

> Let me provide a simple example. In several cases we end  up using the 
> to and from tags as cryptographic tokens that can be  used for 
> authorization. For example, the typical way an INVITE with  replaces 
> is authorized to replace an existing call is that the new  INVITE 
> knows the to and from tag of the old call. sips can provide a  way to 
> stop some attacker on the network form leaning these. (or just  
> learning what 1-900 numbers I was calling ). 

This is where we have a pretty fundamental disconnect: sips is not providing
that, it's the good will of that proxy. What's even worse about this is 
that SIPS
is having the perverse effect of discouraging proxies from doing the 
right thing
unless they are explicitly asked. It should be the Best Current Practice 
that
proxies forward requests with equivalent or better security. It should 
be the
_norm_ that proxies forward with TLS/etc if possible, not the exception.

> It's pretty easy for the  UAC to control the protection on the first 
> hop. However, it needs a  way to signal that the future hops are also 
> protected. SIPS is used  to signal that. 

Why does this need to be signaled? Especially when there's no way that I
can verify that they did the right thing? You're setting the wrong 
expectations
for the user, and that I think is quite dangerous.

> Now you could argue that there could have been  several other ways to 
> signal this and I would agree. But I think  there are plenty of 
> practical threats where you can show that being  able to signal this, 
> and assuming proxies did the right thing,

    ^^^^^^^
Then lets just write a BCP that says that proxies should do the right 
thing. We
should be promoting secure signaling in general, not in specific 
unenforceable
cases.

          Mike

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 1 Jun 2006 14:12:53 -0500

> this is one of the key issues we need to sort out.

Exactly.

I'm open on both b) or c).

>From my own bias I prefer b), but I'm also OK with c), especially if it
satisfies some
market segment (say, 3GPP or whatever).

I don't like a) at all because it is too open.

I would be open to something along the lines of 

d) Security mechanisms specified by IETF to be appropriate. At the time
of this writing,
   it means TLS or IPsec.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Jun 2006 16:41:45 -0400

I would be ok with something like (d). Or perhaps just a specification 
of the characteristics that must be met without specifying the protocol 
used to achieve them. The latter would be just a tightening up of (a).

Whichever of those, why is it applicable only downstream of the callee's 
home proxy? Why shouldn't this be valid between caller and its proxy? Or 
on any hop along the way?

It seems like TLS is important as a protocol of last resort, when all 
you know about contacting the next hop is learned via 3263.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 1 Jun 2006 21:00:05 -0500

I'm not sure I understand your point about "protocol of last resort".

And yes, in my mind, it would be applicable end-to-end accross all hops
(including upstream to the outbound proxy). I agree.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Thursday, June 01, 2006 13:42
> To: Audet, Francois [SC100:3055:EXCH]
> Cc: Cullen Jennings; Dean Willis; Sip
> Subject: Re: Wacky thead of the month award goes to ... Re: 
> [Sip]draft-audet-sip-sips-guidelines: Meaning of sips
> 
> 
> >>From my own bias I prefer b), but I'm also OK with c), 
> especially if 
> >>it
> > satisfies some
> > d) Security mechanisms specified by IETF to be appropriate. At the 
> > time of this writing,
> >    it means TLS or IPsec.
> > 
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip
> > 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Jun 2006 08:50:46 -0400

> I'm not sure I understand your point about "protocol of last resort".

What I mean is that TLS (over TCP) is a protocol that can be used with 
somebody you have no prior relationship with. The other likely 
candidates aren't like that - e.g. you would need some other agreement 
to know how to set up an IPSec relationship.

> (including upstream to the outbound proxy). I agree.

Hey, we arent' supposed to *agree*! :-)

	Paul