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

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

>>    registration is requested MUST be defined by a standards-track RFC.
>>
>>
>> Note that the above two paragraphs seem to be self contradictory.  
>> "Specification Required" means 3GPP and recognized bodies can  define 
>> parameters by publishing specifications. But"Standards Track  RFC" 
>> means only IETF can do so, and it has to be done with an IETF- 
>> consensus standards-track document.
>>
>> Note that the IANA registry currently says:
>>
>>
>>     SIP/SIPS URI Parameters RFC3969 Specification Required
>>
>>     SIP/SIPS URI Parameters - per [RFC3969]
>>     (New registrations are via Specification Required)
>>
>> This means that the current IANA policy for this registry is  
>> "Specification Required".
>>
>>
>> Which did we mean?
> 
> 
> We might want to check with Allison on history of this but my vague  
> recollection was last time we discussed this, we decided we meant  
> "Standards Track". I forget the details and may be totally wrong.
> 
> 
> 
> _______________________________________________
> 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
> 

-- 
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: Juha Heinanen <[email-masked]>
Date: Wed, 17 May 2006 10:08:51 +0300

Jonathan Rosenberg writes:

 > 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

i fully support these and also the once below:

 > It also helps clarify the distinction between sips and transport=tls. 
 > Namely, transport=tls just means that a particular hop uses TLS. 

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

lets get an rfc out quickly that fixes rfc3261 based on jonathan's
proposal.

-- juha

---

From: David R Oran <[email-masked]>
Date: Wed, 17 May 2006 09:20:12 -0400

On May 16, 2006, at 8: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
>
Uh,  why? This contradicts what you said above, which was that "each  
and every link...was secure". If that in fact is the desired  
semantic, how can you argue that, for example, a direct UAC-UAS IPSEC  
tunnel using AES-256 and keys delivered by NSA agents is not secure,  
while a multi-hop TLS connection where each hop uses null-encryption  
cypher or 40-bit keys is secure?

I'd have less problem with this if SIPS was redefined to mean "each  
hop used TLS" and said NOTHING about whether the end-to-end  
communication was secure or not.

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.

> 2. there is no upgrading or downgrading, period
I'm OK with this.

>
> With these two rules, it becomes much clear what kind of benefits  
> are provided by sips. Every hop is secure with TLS, period.
I'm OK with this if you simply say "used TLS" as opposed to "secure  
with TLS". I would still argue that you'd need strong caveats that  
this does not actually say much if anything about how secure the end- 
to-end communication was unless the transport connection is direct UA- 
UA with no proxy hops.

Cheers, Dave.

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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 May 2006 06:42:26 -0700

> to-end assertion about what level of security the UAS can count on.

How can the UAS do that? If an intermediate proxy/UAC/B2BUA _lies_ about 
whether
the previous hop was TLS, how exactly can you detect that? Sips is nothing
more than a request that good actors act good, and no amount of shoe 
pounding
on podiums is going to elevate it to first class status.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 May 2006 06:52:39 -0700

David R Oran wrote:

>
> On May 17, 2006, at 9:42 AM, Michael Thomas wrote:
>
>> David R Oran wrote:
>>
>>>
>>> Uh,  why? This contradicts what you said above, which was that  
>>> "each  and every link...was secure". If that in fact is the  
>>> desired  semantic, how can you argue that, for example, a direct  
>>> UAC-UAS IPSEC  tunnel using AES-256 and keys delivered by NSA  
>>> agents is not secure,  while a multi-hop TLS connection where each  
>>> hop uses null-encryption  cypher or 40-bit keys is secure?
>>>
>>> I'd have less problem with this if SIPS was redefined to mean  
>>> "each  hop used TLS" and said NOTHING about whether the end-to- end  
>>> 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.
>>
>>
>>
>> How can the UAS do that? If an intermediate proxy/UAC/B2BUA _lies_  
>> about whether
> I didn't say it was easy/possible to do. I said it would be more  
> useful :-)

Well, the operative word here is "count". A UAS can't count on anything
with SIPS because it has no way to verify against potential adversaries. No
amount of words -- weasel or otherwise -- are going to change that.

       Mike

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 May 2006 10:43:34 -0400

Jonathan Rosenberg wrote:
> 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.

Yeah. That is a problem.

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

Yes. But we need to be very clear about how the applicable case is 
recognized. It is certain means of using SIPS that will provide this 
guarantee. Other usages of sips may not. I don't think it is yet clear 
exactly what those usages are, and that is part of the task.

> 1. SIPS requires the usage of TLS at every hop - none of this weasel 

I'm still on the fence on this one. IPSec has its uses, and people using 
it will want some guarantees of secure communication too. I don't have 
an answer here, but I fear if we don't accommodate it explicitly then 
people will just cheat.

> 2. there is no upgrading or downgrading, period

I think this depends on what you mean by upgrading and downgrading. 
Below you propose that the home proxy can take a single registered 
contact and convert it from sip to sips or visa versa depending on how 
the call reached the AOR. That seems like upgrading or downgrading to me.

Also, I don't want to have to independently register to the sip and sips 
form of my AOR, and yet I want calls to both forms to be valid. That 
also implies some form of upgrading or downgrading somewhere.

I think it is more a matter of in what circumstances an AOR may be 
upgraded or downgraded. It must be restricted to cases where it remains 
clear whether there is a secure path end to end.

So, it should be ok for the originator of a request to upgrade (and 
maybe to downgrade), but it isn't ok for others along the path to *that* 
target to do so. Once it reaches that target (the AOR), then some other 
rules cut it. Since upgrading or downgrading along the path is a 
translation, it is already forbidden by 3261, so this perhaps only 
amounts to a clarification.

B2BUAs may (as always) present a special concern. As a UA, it may be 
valid for one to upgrade or downgrade. But that may be very deceptive to 
the ultimate target. So this may require some special specifications.

> With these two rules, it becomes much clear what kind of benefits are 
> provided by sips. Every hop is secure with TLS, period.

There remains the problem that this is hop by hop, and any of those hops 
can lie. So the guarantee is always conditional.

	Paul

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

---

From: David R Oran <[email-masked]>
Date: Wed, 17 May 2006 09:44:57 -0400

On May 17, 2006, at 9:42 AM, Michael Thomas 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:
>>>
>> "each  hop used TLS" and said NOTHING about whether the end-to- 
>> end  communication was secure or not.
>>
> more than a request that good actors act good, and no amount of  
> shoe pounding

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 May 2006 10:43:34 -0400

Yeah. That is a problem.

	Paul

---

From: David R Oran <[email-masked]>
Date: Wed, 17 May 2006 09:44:57 -0400

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 17 May 2006 10:22:04 -0500

I think the operative word here is "people"...

> it will want some guarantees of secure communication too. I don't have an 
> answer here, but I fear if we don't accommodate it explicitly then people 
> will just cheat.

The problem is, using the APIs I'm familiar with, there's no indication that 
IPsec was used, when you get to the application level, so there's no 
reasonable way for applications to provide indications that communication 
was secure, without digging through kernel data structures.

I'm finding this somewhat frustrating - as Dave pointed out, even saying 
"TLS" doesn't say anything about "secure" (see null encryption transform), 
much less "secure at every hop", but most people who care about security 
also care about confidentiality, including confidentiality at every hop.

Thanks,

Spencer

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 May 2006 08:38:15 -0700

Spencer Dawkins wrote:

>> I'm still on the fence on this one. IPSec has its uses, and people 
>> using it will want some guarantees of secure communication too. I 
>> don't have an answer here, but I fear if we don't accommodate it 
>> explicitly then people will just cheat.
>
>
> The problem is, using the APIs I'm familiar with, there's no 
> indication that IPsec was used, when you get to the application level, 
> so there's no reasonable way for applications to provide indications 
> that communication was secure, without digging through kernel data 
> structures.
>
> I'm finding this somewhat frustrating - as Dave pointed out, even 
> saying "TLS" doesn't say anything about "secure" (see null encryption 
> transform), much less "secure at every hop", but most people who care 
> about security also care about confidentiality, including 
> confidentiality at every hop.

Since SIPS is completely based on the good will of the participants, if 
you're
going to have it at all it makes as much sense to include ipsec and probably
SIP over Brinks Armored Car while we're at it. It doesn't require that the
proxy be able to know that there's an actual SA active -- this could be just
provisioned -- because ultimately the UAS has no way to know if somebody is
fibbing anyway.

Like I said earlier: SIPS is a *request* that good actors behave good; 
advertising
it as anything else is overselling what SIPS actually gives you. In 
fact, I'd go so
far as to say: a UAS MUST NOT take different action based upon whether an
incoming request was labeled SIP or SIPS.

       Mike

---

From: Dean Willis <[email-masked]>
Date: Wed, 17 May 2006 17:28:31 -0500

> 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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 22 May 2006 18:11:39 -0700

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:

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