Subject: [Sip] sips: upgrading allowed or not

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Mar 2007 09:40:02 -0400

During the Prague IETF, I shared some opinions on what I thought sips 
needs to look like and why, and wanted to take these to the list.

Firstly, what is the point of sips? What does it bring a network that it 
can't get with TLS on some hops, as needed? The answer is that certain 
security benefits are afforded if we can assure that every single hop 
from UAC to UAS was TLS protected, and that furthermore, this fact can 
be definitively known by the UAC, UAS, and all proxies along the way. If 
we make the assumption that the UA's trust their proxies (please don't 
question the assumption in this thread), then SIPS provides you some 
very nice security properties - confidentiality and integrity from all 
non-trusted entities. We use this property all over our specs to secure 
various extensions.

Given that, sips is broken if it doesn't provide that service (tls on 
each hop with knowledge of such by all entities). FOr this reason, I 
think we need to eliminate the last hop exception (uncontroversial I 
think), but furthermore, I believe this extends to retargeting as well. 
I think we clearly need to disallow retargeting or downgrading from a 
sips URI to a sip URI. I think that was also largely non-controversial. 
However, I also want to disallow upgrading or retargeting from sip to 
sips. On this, there was some disagreement.

The challenge Jon gave me at the mike was this. As long as a UAC inserts 
a sips URI into the To field and R-URI field when it emits a sips 
request, does not the presence of a sips URI in the TO field, and 
receipt over a TLS connection, assure that the request was delivered 
over TLS at each hop? Had the request been sent originally to a sip URI 
and then upgraded, the TO field would not have been sips, but rather sip.

I believe Jon is correct, however I still think it is not a good idea. 
My rationale is:

1. if upgrades are disallowed, redirecting from sip to sips works much 
better. Such a redirection would necesarily have to go all the way to 
the UAC. If we allow upgrades, a proxy in the middle could recurse and 
upgrade. In that case, if the reason for the redirection was that the 
UAS *wanted* TLS on each hop, recursing in the middle would destroy that 
possibility.

2. The architectural principle behind the first issue, more generally, 
is that the meaning of sips is *SECURE ON EACH HOP FROM UAC TO UAS*. To 
me, this is fundamentally at odds with any notion of upgrade or downgrade.

3. Things become simpler if we forbid upgrades. We can eliminate the 
text on double-record routing sinec a proxy would never be sip/sips 
converting. I think it also just generally makes overall processing 
easier. SIPS means one thing and one thing only and its terribly clear 
what it means.

As such, I stand by my argument that we should forbid upgrades.

-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: Dean Willis <[email-masked]>
Date: Tue, 27 Mar 2007 12:50:26 -0500

On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote:

>
> Firstly, what is the point of sips? What does it bring a network  
> that it can't get with TLS on some hops, as needed? The answer is  
> that certain security benefits are afforded if we can assure that  
> every single hop from UAC to UAS was TLS protected, and that  
> furthermore, this fact can be definitively known by the UAC, UAS,  
> and all proxies along the way. If we make the assumption that the  
> UA's trust their proxies (please don't question the assumption in  
> this thread), then SIPS provides you some very nice security  
> properties - confidentiality and integrity from all non-trusted  
> entities. We use this property all over our specs to secure various  
> extensions.
>

Note that I changed threads . . .

There is a big gap between "UAs trust their proxies" and "UAs trust  
every proxy that might possibly get inserted into the signaling path".

You assert "assure that every single hop from UAC to UAS was TLS  
protected, and that furthermore, this fact can be definitively known  
by the UAC, UAS, and all proxies along the way"

Since:

1) UAs have no control over what proxies beyond the first hop get  
inserted.
2) Neither UAs nor proxies have any mechanism for knowing whether  
proxies or UAs more than one proxy hop away actually complied with  
the requirements of SIPS.

That's not saying SIPS doesn't provide some useful security  
properties. It does. It just doesn't provide the assurance that I  
keep hearing repeated. And I think that if you STOP saying it  
provides that sort of assurance, it will stop confusing people so  
badly about what it does usefully provide.

--
Dean

---

From: "Frank W. Miller" <[email-masked]>
Date: Tue, 27 Mar 2007 12:08:07 -0700

I think there are two distinct environments that need to be identified.
The first would be something like a carrier environment, i.e. IMS-like.
In this environment the assumption that the proxies are trusted is
probably valid.  The carriers are unlikely to use a path that does not
include proxies they trust, either because they own them or because they
have a relationship with the owner.  This looks alot like the SS7 world
where the signaling points are all assumed to be trusted.

The second environment I'll call the open Internet.  While this may
include proxies that can be trusted, e.g. my first hop to a known
service provider, I think it would be easy to paint scenarios where the
UA didn't really know all the signaling hops.  In this environment the
hop-by-hop trust is probably not good enough for the security properties
being targeted.

I know you said we weren't supposed to question the trust of the proxies
but I think that's really the heart of the issue with SIPS.  I don't
think its the implementation of hop-by-hop, I think its the assumption
that hop-by-hop is good enough for all the scenarios that SIP is used
for.

My thought is that to alleviate confusion, clarification of the
environment in which SIPS is sufficient is really the key.  Perhaps
break the environment into those that are really trusted and those that
are not.  Allow use of SIPS for the trusted environments and come up
with a decent end-to-end mechanism for those that are not.

FM

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 27 Mar 2007 21:21:27 +0300

Frank W. Miller writes:

 > probably valid.

what do you mean by "trusted"?  government of sweden just proposed that
they are going to monitor all communications that pass through the
borders, e.g., my cal lfrom finland to norway.  as a user i cannot
"trust" that.  the fact that proxies in sweden see contents of sip
requests make the whole system untrusted.  it doesn't help at all if sip
requests are encrypted on a particular link.

the right solution is to deprecate sips and stop fooling the users.

-- juha

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 27 Mar 2007 13:30:44 -0500

Sorry for coming to fray late and couldn't attend the Prague. I have yet
to look into the proceedings.

My understanding was that we are going to have BCP/INFORMATIONAL
document which will just state that what SIPS provide. I had the
question on the value of this document too. But I stopped arguing seeing
the community wanted to have the document due to whatever reasons...

What is the decision on the Tel URI ? Are we going to have tels uri
scheme for that or other URN etc. 

Though, I have repeated again and again just deprecate SIPS. But now
keeping silent to let BCP proceed and then update cipher-suites etc...

Thx
Samir

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2007 10:50 AM
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Does TLS have the security benefits claimed? (was TLS Re:
[Sip]
> sips: upgrading allowed or not)
> 
>

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 27 Mar 2007 14:30:59 -0400

I don't know the full context of this discussion, but one thing which comes
to my mind is that what Frank is saying is very important. In a P2P scenario
(on the internet), this is even more relevant since the UA certainly wont
know how the call is getting routed.

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 27 Mar 2007 13:30:44 -0500

Thx
Samir

[Sip]

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Tue, 27 Mar 2007 14:30:59 -0400

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Mar 2007 13:56:07 -0500

On Mar 27, 2007, at 8:40 AM, Jonathan Rosenberg wrote:

> I believe this extends to retargeting as well. I think we clearly  
> need to disallow retargeting or downgrading from a sips URI to a  
> sip URI. I think that was also largely non-controversial.

I'd say that this is arguably already a factor in RFC 3261, EXCEPT  
for the responsible home proxy being able to downgrade. So  
"eliminating the last-hop exception" and "disallowing downgrading  
from SIPS to SIP" are, IMHO, redundant expressions.

In any case (chair hat on), we had a clear consensus at IETF 68 to  
disallow downgrading.

Retargeting is a somewhat thornier question, since that behavior is  
AFAIK somewhat scattered throughout RFC 3261, but I believe we also  
had a consensus to disallow retargeting from SIPS to SIP at IETF 68.

> However, I also want to disallow upgrading or retargeting from sip  
> to sips. On this, there was some disagreement.
>
> The challenge Jon gave me at the mike was this. As long as a UAC  
> inserts a sips URI into the To field and R-URI field when it emits  
> a sips request, does not the presence of a sips URI in the TO  
> field, and receipt over a TLS connection, assure that the request  
> was delivered over TLS at each hop? Had the request been sent  
> originally to a sip URI and then upgraded, the TO field would not  
> have been sips, but rather sip.
>
> I believe Jon is correct, however I still think it is not a good  
> idea. My rationale is:
>
> 1. if upgrades are disallowed, redirecting from sip to sips works  
> much better. Such a redirection would necesarily have to go all the  
> way to the UAC. If we allow upgrades, a proxy in the middle could  
> recurse and upgrade. In that case, if the reason for the  
> redirection was that the UAS *wanted* TLS on each hop, recursing in  
> the middle would destroy that possibility.
>
> 2. The architectural principle behind the first issue, more  
> generally, is that the meaning of sips is *SECURE ON EACH HOP FROM  
> UAC TO UAS*. To me, this is fundamentally at odds with any notion  
> of upgrade or downgrade.
>
> 3. Things become simpler if we forbid upgrades. We can eliminate  
> the text on double-record routing sinec a proxy would never be sip/ 
> sips converting. I think it also just generally makes overall  
> processing easier. SIPS means one thing and one thing only and its  
> terribly clear what it means.
>

Something I'm confused about here.

Assume we started a request chain with a "tel:" URI that was  
delivered over TLS to an "outbound" proxy that needs to retarget the  
request to a destination for which it has a known SIPS: URI.

What should the proxy do? Retarget to sips:, or retarget to sip: and  
rely on the "thou shalt use TLS if possible" language to deliver the  
request securely?

--
dean

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 27 Mar 2007 14:04:50 -0500

This is what I am asking. I want my N11 call to have confidentiality
too.
What if the translation to SIP URI is to be done by a SIP Proxy which is
couple of hops away from the UAC.

Thx
Samir

---

From: David R Oran <[email-masked]>
Date: Tue, 27 Mar 2007 15:08:38 -0400

> hop-by-hop trust is probably not good enough for the security  
Hmmm, I might be tempted to argue the reverse, because the IMS  
carriers are subject to CALEA-like regulations, and the open internet  
services are not.

Transitive trust just sucks, and constructing finely tuned arguments  
about exactly when it is resonable to place that trust is, at leas to  
me, in the domain of philosophy and well outside engineering.

This is why I continue to be in the camp that finds SIPS of very  
limited utility, and more likely to be misunderstood to the detriment  
of users than truly valuable.

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Mar 2007 14:12:09 -0500

People,

Can we stick to the topic and not repeat the pointless arguments of the
previous 4 months
about transitive trust.

We have a working group consensus, let's move on.

Let's focus on the one remaining issue, which is "Do we allow for
retarget upgrades from 
SIP to SIPS" (in the other thread).

This particular thread here should be put to rest.

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 27 Mar 2007 14:21:01 -0500

I have to state respectfully that SIP network is not going to be
utilized for transporting only SIP URI schemes in different scenarios.
This is another point apart from transitive trust. 

I just want to know the decision on the other URI schemes.

Thx
Samir

> From: Audet, Francois (SC100:3055)
> Sent: Tuesday, March 27, 2007 12:12 PM
> To: IETF SIP List
> Cc: Dean Willis
> Subject: RE: Does TLS have the security benefits claimed? (was TLS Re:
> [Sip] sips: upgrading allowed or not)
> 
> 
> People,
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Mar 2007 14:24:57 -0500

In that case, it's not a retarget but a redirect.

For example, I call you at sip:[email-masked]. You send me a 301
Contact: mailto:[email-masked].

My UA warns me that you are only availble through email, and I can
decide to send you email or not.

That's covered in there.

> From: Srivastava, Samir (SC100:8826) 
> Sent: Tuesday, March 27, 2007 12:21
> To: Audet, Francois (SC100:3055); IETF SIP List
> Cc: Dean Willis
> Subject: RE: Does TLS have the security benefits claimed? 
> (was TLS Re: [Sip] sips: upgrading allowed or not)
> 
> I have to state respectfully that SIP network is not going to 
> be utilized for transporting only SIP URI schemes in 
> different scenarios. This is another point apart from 
> transitive trust. 
> 
> > Can we stick to the topic and not repeat the pointless arguments of 
> > the previous 4 months about transitive trust.
> > 
> > retarget upgrades from SIP to SIPS" (in the other thread).
> > 
> > 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: Dean Willis <[email-masked]>
Date: Tue, 27 Mar 2007 14:30:26 -0500

On Mar 27, 2007, at 2:12 PM, Francois Audet wrote:

> the

That's the "upgrading allowed or not" thread which is continuing  
independently. This thread is the "rehash the assurance question"  
thread . . .

> This particular thread here should be put to rest.

Let it go, or it's likely to come back up  on the "upgrading allowed"  
thread . . . and it's much better to have the two discussions running  
under different subject lines than the same subject line.

--
Dean

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 27 Mar 2007 14:30:53 -0500

This doesn't cover the original (first) request having ReqURI populated
with tel URI, which has to traverse couple of SIP proxies  and then
translation to SIP or SIPS is done at a proxy which is further down.
What the intermediate proxies will do ?

Thx
Samir

> Sent: Tuesday, March 27, 2007 12:25 PM
> To: Srivastava, Samir (SC100:8826); 'IETF SIP List'
> Cc: 'Dean Willis'
decide
> to send you email or not.
> 
> That's covered in there.
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Mar 2007 14:32:02 -0500

It must not map from Tel to SIPS.  

Just from Tel to SIP. That's the point. 

> Sent: Tuesday, March 27, 2007 12:31
> To: Audet, Francois (SC100:3055); 'IETF SIP List'
> Cc: 'Dean Willis'
> This doesn't cover the original (first) request having ReqURI 
> populated with tel URI, which has to traverse couple of SIP 
> proxies  and then translation to SIP or SIPS is done at a 
> proxy which is further down. What the intermediate proxies will do ?
> 
> Thx
> Samir
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Mar 2007 14:36:13 -0500

> This is what I am asking. I want my N11 call to have confidentiality

Right.

Of course, if we have the working requirement that "all compliant  
implementations MUST use TLS if it is available", then the additional  
requirement for N11 calls of "This call MUST succeed, and it SHOULD  
be confidential and integrity protected" lead us to a different  
conclusion.

That conclusion would be: N11 calls translate to sip: URIs, because  
the PSAP or some intermediary might not support sips:, and it is more  
important for the N11 call to succeed than it is for it to be  
confidential and integrity protected.

> couple of hops away from the UAC.

I think that case is pretty clear -- by the reasoning presented, if  
there have been a assertably-not-SIPS-like hops, you can't upgrade  
from tel: to sips:.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Mar 2007 14:35:50 -0500

I agree with Jonathan's proposal.

Here is a slighly different perspective on it however. I'll keep
rethorical arguments
out of it, and stick to protocol.

- Disallowing re-targeting "upgrades" from SIP to SIPS by a proxy would
be
  a normative change to RFC 3261. Section 26.4.4 describes it (3rd
paragraph
  on p. 250). That is just an observation.

- The fact that it is currently allowed means that the UAS receiving the
request
  has to go through some fairly esoteric logic to "guess" if the request
was
  sent securily on each hop or not. This is described in paragraph 4 of
p. 250,
  and section 4.1 of draft-ietf-sip-sips-02 also describes it, with some
modifications.
  Those procedures are extremely cludgy and non-deterministic. They are
also misleading
  for the UAS, and inconsistent with the use of SIPS and SIP as
described in this draft
  (i.e., for the other scenarios of forwarding and retargeting). In all
other instances, 
  the idea is that when a request is forwarded/retargeted, the scheme is
preserve. 
  I'd really like to get rid of section 4.1.

	- Jonathan Peterson was proposing that the UAS inspect the To
header to see if 
        the request was initially targeted at SIPS. This is a subset of
the procedures 
        of 4.1/draft-ietf-sip-sips and of RFC 3261 (they add stuff like
looking at 
        Via and other fields).

- This "upgrading" also forces the use of the double Record-Route in
section 4.2
  of draft-ietf-sip-sips-02. Since we agreed to deprecate the last hop
exception
  for downgrading, the SIPS-to-SIP Record-Route scenario will be removed
from the
  -03 version. Removing the "upgrade" scenario would also remove the
double 
  Record-Route for the SIP-to-SIPS, and the net-net is that the whole
section
  4.2 could be removed.

- Because of rules described in RFC 3261, if a UAS receives an incoming
request with a 
  SIPS Request-URI, it MUST use a SIPS contact. This is a big problem
for the sender
  of the initial request that initiated the dialog if that UAC did not
support SIPS.
  If Record-Routing is not used, it will just plainly not work. The UAC
will not be
  able to send further requests (like BYE for example). If Record-Route
is used, it 
  might work (or it might not). The reason it might not work is that
there is possible
  that the UAC might "choke" on the SIPS URI in the Contact (because it
doesn't understand
  how to parse it).

	- We have corrected to types of problems everywhere else in this
draft. There was
	  quite a few of them in previous versions. This is the only one
remaining.

- Note that it would still be possible to "upgrade" by sending SIP over
TLS. In fact, I would
  argue that we need to put a requirement to do so when there is already
a TLS connection
  opened with the target (as would be the case if Outbound was used, and
the registration was
  done over TLS).

In summary, I favor deprecating the "retargeting upgrade" scenario for
the following reasons:

- It greatly simplifies the draft, eliminating sections 4.1 and 4.2
completely.

- It is much less confusing for the far end.

- It avoids some nasty protocol level problems that "break" things.

- You can still use TLS for transport for delivering to that last hop.

> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Tuesday, March 27, 2007 06:40
> To: IETF SIP List
> Subject: [Sip] sips: upgrading allowed or not
> 
> During the Prague IETF, I shared some opinions on what I 
> thought sips needs to look like and why, and wanted to take 
> these to the list.
> 
> Firstly, what is the point of sips? What does it bring a 
> network that it can't get with TLS on some hops, as needed? 
> The answer is that certain security benefits are afforded if 
> we can assure that every single hop from UAC to UAS was TLS 
> protected, and that furthermore, this fact can be 
> definitively known by the UAC, UAS, and all proxies along the 
> way. If we make the assumption that the UA's trust their 
> proxies (please don't question the assumption in this 
> thread), then SIPS provides you some very nice security 
> properties - confidentiality and integrity from all 
> non-trusted entities. We use this property all over our specs 
> to secure various extensions.
> 
> Given that, sips is broken if it doesn't provide that service 
> (tls on each hop with knowledge of such by all entities). FOr 
> this reason, I think we need to eliminate the last hop 
> exception (uncontroversial I think), but furthermore, I 
> believe this extends to retargeting as well. 
> I think we clearly need to disallow retargeting or 
> downgrading from a sips URI to a sip URI. I think that was 
> also largely non-controversial. 
> However, I also want to disallow upgrading or retargeting 
> from sip to sips. On this, there was some disagreement.
> 
> The challenge Jon gave me at the mike was this. As long as a 
> UAC inserts a sips URI into the To field and R-URI field when 
> it emits a sips request, does not the presence of a sips URI 
> in the TO field, and receipt over a TLS connection, assure 
> that the request was delivered over TLS at each hop? Had the 
> request been sent originally to a sip URI and then upgraded, 
> the TO field would not have been sips, but rather sip.
> 
> 1. if upgrades are disallowed, redirecting from sip to sips 
> works much better. Such a redirection would necesarily have 
> to go all the way to the UAC. If we allow upgrades, a proxy 
> in the middle could recurse and upgrade. In that case, if the 
> reason for the redirection was that the UAS *wanted* TLS on 
> each hop, recursing in the middle would destroy that possibility.
> 
> generally, is that the meaning of sips is *SECURE ON EACH HOP 
> FROM UAC TO UAS*. To me, this is fundamentally at odds with 
> any notion of upgrade or downgrade.
> 
> 3. Things become simpler if we forbid upgrades. We can 
> eliminate the text on double-record routing sinec a proxy 
> would never be sip/sips converting. I think it also just 
> generally makes overall processing easier. SIPS means one 
> thing and one thing only and its terribly clear what it means.
> 
> This list is for NEW developmenFrom [email-masked] Tue Mar 27 15:36:58 2007
From: Dean Willis <[email-masked]>
Subject: Re: [Sip] sips: upgrading allowed or not
Date: Tue, 27 Mar 2007 14:36:13 -0500
To: "Samir Srivastava" <[email-masked]>
Cc: IETF SIP List <[email-masked]>

Right.

--
Dean

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 27 Mar 2007 14:38:01 -0500

Changed the subject.

But the UAC wanted its Tel Uri Request to traverse securely on the
intermediate hops. How it can enforce that?    
  
Thx
Samir

> Sent: Tuesday, March 27, 2007 12:32 PM

---

From: Sean Olson <[email-masked]>
Date: Tue, 27 Mar 2007 12:40:41 -0700

Tels:  of course

-----Original Message-----
From: Samir Srivastava [mailto:[email-masked]]
Sent: Tuesday, March 27, 2007 12:38 PM
To: Francois Audet; IETF SIP List
Cc: Dean Willis
Subject: [Sip] Securing Other URI (Tel URI) scheme

Changed the subject.

Thx
Samir

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 27 Mar 2007 14:45:58 -0500

Hi Sean,

That's where I have the biggest problem. This solution is non-modular.

Proxy-Require (tls / cipher-suite) provides the modular solution. You
keep inventing the other URI schemes without doubling the "S" suffix
URIs for secure routing. Secure Routing requirement is settled once for
all using Proxy-Require / Require. 

Thx
Samir

> From: Sean Olson [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2007 12:41 PM
> To: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055); IETF
SIP
> List
> Cc: Dean Willis
> Subject: RE: Securing Other URI (Tel URI) scheme
> 
> Tels:  of course
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Mar 2007 14:46:17 -0500

> intermediate hops. How it can enforce that?

It can't. SIP, as currently defined, JUST DOESN'T HAVE THAT PROPERTY.

Without adding a new mechanism, at the very best, we can do a "the  
request will be sent as securely as it can be". And adding such a  
mechanism is, I believe, more complex than just an option-tag or  
request-URI modifier.

One way of getting the sort of property I think you're looking for  
would be to add something like a Connection-Handling header field  
that would say "must use TLS", along with a new option tag that could  
be used in Proxy-Require and Require to make sure that the proxies  
and UAS support the "Connection-Handling" extension.

--
Dean

---

From: Sean Olson <[email-masked]>
Date: Tue, 27 Mar 2007 12:48:33 -0700

Ahhh, yes.  Now I remember why SIPS was a bad idea. A proxy-require/require solution might work, just be prepared for zero adoption.

-----Original Message-----
From: Samir Srivastava [mailto:[email-masked]]
Sent: Tuesday, March 27, 2007 12:46 PM
To: Sean Olson; Francois Audet; IETF SIP List
Cc: Dean Willis
Subject: RE: Securing Other URI (Tel URI) scheme

Hi Sean,

Thx
Samir

SIP

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Mar 2007 14:49:17 -0500

> Tels:  of course

Ok, I stand corrected.

You could do this with a new URI scheme, provided that 1) the new URI  
scheme had explicitly stated retargeting properties equivalent to  
those proposed for sips: and that 2) we fix 3261 to provide those  
properties for sip:.

--
Dean

---

From: "Frank W. Miller" <[email-masked]>
Date: Tue, 27 Mar 2007 14:03:48 -0700

> carriers are subject to CALEA-like regulations, and the open internet  

The need to do CALEA is an additional reason why they will route through
their own stuff or one of their telco buddies boxes.  It reinforces the
fact that they need to trust the proxies.  How can I be certain I can
see (and therefor tap) the signaling if I'm not sure all the signaling
is going through my trusted proxies?

> of users than truly valuable.

Well this is actually my real opinion too but we're stuck with proxies.
Its a basic architectural tenet of SIP.  The fact that their are proxies
and that they need to see at least some of the messaging is the root
cause of the transitive trust problem.  The only real way to do
end-to-end is to somehow force the signaling to not traverse the proxies
but to be end UA to end UA.

Its interesting that if point-to-point signaling were used rather than
traversing proxies, SIPS would be just fine for end-to-end security.
Perhaps we should come up with a mechanism that allows/forces the
signaling to be end-to-end only when end-to-end security is required?

FM

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Mar 2007 15:09:17 -0500

You can not.

There is no secure Tel URI. 

> Sent: Tuesday, March 27, 2007 12:38
> Subject: Securing Other URI (Tel URI) scheme
> 
> Changed the subject.
> 
> But the UAC wanted its Tel Uri Request to traverse securely 
> on the intermediate hops. How it can enforce that?    
>   
> Thx
> Samir
>

---

From: "Frank W. Miller" <[email-masked]>
Date: Tue, 27 Mar 2007 14:11:03 -0700

> what do you mean by "trusted"?  government of sweden just proposed that

What I mean is that the telco owns the actual proxy or has some kind of
relationship with any other carriers that own their boxes.  They can
control how signaling is routed.  Its the SS7 model, i.e. I know where
my signaling came from and where its going always, no doubts.  SIPS will
work in that kind of environment.  I would be shocked if when the big
carriers implement SIP and/or IMS proxies they don't "own" all the
equipment, either themselves or through trusted business relationships.
(Somebody from Verizon or TMobile or somebody with like a real cell
phone network please shock me)

FM

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 27 Mar 2007 15:13:29 -0500

I have stated a lot of other problems earlier with SIPS too.

Apart from just doubling the URIs schemes and documentation pains
everytime, It will double the entries in DNS, Registrar too. 

Loose routing got adopted against the strict routing. Though we provided
the backward compatibility as Strict Routing was DEPLOYED. 

Here SIPS is not deployed, then why not deprecate it. (Pl correct me, if
I am wrong) Cost will be on the early implementers. 

The next version of cipher-suite draft will be more problem centric and
talking about the each bit of the problem with SIPS.

Thx
Samir

> Sent: Tuesday, March 27, 2007 12:49 PM
SIP
> Ahhh, yes.  Now I remember why SIPS was a bad idea. A proxy-
> require/require solution might work, just be prepared for zero
adoption.

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Mar 2007 15:27:02 -0500

> signaling to be end-to-end only when end-to-end security is required?

like the sipsec: draft?

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Mar 2007 15:28:12 -0500

> phone network please shock me)

trusted != trustworthy.

We need to remember that.

--
Dean

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 27 Mar 2007 15:51:22 -0500

SIP providers have to make money also. How does SIPSEC draft provide
this information to intermediate proxies without opening up the message
to them ?

Also how CALEA compliance will be achieved with this ? 

SIP != HTTP (Though we barrowed a lot from there).

Thx
Samir

> Sent: Tuesday, March 27, 2007 1:27 PM
> To: Frank W. Miller
> Cc: IETF SIP List; David R Oran
> Subject: Re: Does TLS have the security benefits claimed? (was TLS Re:

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 27 Mar 2007 16:42:58 -0500

> this information to intermediate proxies without opening up the message

I am not a cryptographer, but it seems that there are
techniques in the cryptography world that allow limited keyword
searches across encrypted data without leaking all the
information in the stream.  The work by Boneh et al. [1] is the
one I am aware of.  It works by providing a list of keywords
to a proxy such that the proxy can search for those keywords
in the encrypted stream without compromising the overall
confidentiality of the message.

[1] D. Boneh, G. Di Crescenzo, R. Ostrovsky, and G. Persiano,
  "Public Key Encryption with Keyword Search," Proceedings of
  Eurocrypt 04, pp. 506-522, 2004.

So, presumably, intermediary proxies that want to bill on
certain codecs or headers can still do so and make money without
compromising end-to-end security.

In the end, you need to pick what you want to do.  If you do not
want intermediaries to poke in the signaling, use sipsec.  On the
other hand, if this is not a constraint for you, use normal
hop-by-hop protected signaling.

> Also how CALEA compliance will be achieved with this ? 

If CALEA is an issue, then don't use sipsec.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Mar 2007 16:49:42 -0500

On Mar 27, 2007, at 3:51 PM, Samir Srivastava wrote:

> SIP providers have to make money also.

Intermediate proxies know that they are being traversed, can  
authenticate the user making the SIPS: connection request, and can  
certainly bill them for the privilege of traversing the proxy,  
including a wide variety of possible charging metrics such as per  
connection, per connection duration, per destination, per byte, per  
time of day, or any combination thereof.

SIP end points (like telephony gateways, application servers, call  
centers, whatever) can also authenticate the originator or terminator  
of a call, and can therefore bill them based on any aspect of the  
communications covered by the agreement between the service provider  
and the operator of the endpoint in question.

This can all be done without compromising the fundamental security of  
the SIP-level signaling path.

> How does SIPSEC draft provide

It doesn't. Once you've done that, you've defeated the security  
mechanism. If it hurts, DON'T DO IT!

> Also how CALEA compliance will be achieved with this ?

I'm sorry, but what part of RFC 2804 did you not understand?

Here are two bullet points to ponder:

    - The IETF believes that in the case of traffic that is today going
      across the Internet without being protected by the end systems (by
      encryption or other means), the use of existing network features,
      if deployed intelligently, provides extensive opportunities for
      wiretapping, and should be sufficient under presently seen
      requirements for many cases. The IETF does not see an engineering
      solution that allows such wiretapping when the end systems take
      adequate measures to protect their communications.

    - The IETF believes that adding a requirement for wiretapping will
      make affected protocol designs considerably more complex.
      Experience has shown that complexity almost inevitably jeopardizes
      the security of communications even when it is not being tapped by
      any legal means; there are also obvious risks raised by having to
      protect the access to the wiretap. This is in conflict with the
      goal of freedom from security loopholes.

> SIP != HTTP (Though we barrowed a lot from there).

Arguably, we borrowed some of the the wrong parts. We got the bulky  
encoding  and muddy semantics of the request-response model without  
getting the security features and transport-application isolation  
(yes, we have worse transport-application cross-layer binding than  
HTTP, although many predicted it would be impossible to do worse than  
HTTP. OTOH, we can do a lot of stuff that HTTP can't).

There is still much to be learned from the amazing successes (and  
curious weaknesses) of HTTP.

--
Dean

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 27 Mar 2007 17:01:27 -0500

> Sent: Tuesday, March 27, 2007 4:50 PM
> To: Srivastava, Samir (SC100:8826)
> 
> authenticate the user making the SIPS: connection request, 
> and can certainly bill them for the privilege of traversing 
> the proxy, including a wide variety of possible charging 
> metrics such as per connection, per connection duration, per 
> destination, per byte, per time of day, or any combination thereof.
> 
> SIP end points (like telephony gateways, application servers, 
> call centers, whatever) can also authenticate the originator 
> or terminator of a call, and can therefore bill them based on 
> any aspect of the communications covered by the agreement 
> between the service provider and the operator of the endpoint 
> in question.
> 
> This can all be done without compromising the fundamental 
> security of the SIP-level signaling path.

Agree.

And if the proxy is using a model where this is not possible, it can
reject the connection until the originator is willing to comply with the
terms of use for that proxy. If the model the proxy is using is not
useful, then the user will simply use a proxy that is willing to accept
the traffic that the user is generating.

Simply put, the proxy doesn't have to carry traffic that it's not
comfortable with, and the end points may not have to send their traffic
to that proxy (subject to the policies of their domain administrator).

Regards,
Brian

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Mar 2007 15:32:15 -0700

Dean Willis wrote:
>> need to disallow retargeting or downgrading from a sips URI to a sip 
>> URI. I think that was also largely non-controversial.
>
> I'd say that this is arguably already a factor in RFC 3261, EXCEPT for 
> the responsible home proxy being able to downgrade. So "eliminating 
> the last-hop exception" and "disallowing downgrading from SIPS to SIP" 
> are, IMHO, redundant expressions.
>
Can I suggest that this particular turd is as polished as it's going to get?
If we are going to go after retargeting too, then are going start writing
proscriptions against people to downgrading when they type in a SIPS
URI from somebody's business card? Let's just not go here; effort would
be far better spent on things that aren't such a dead end.

       Mike

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Mar 2007 00:45:01 +0200

Hi,

In Prague I asked Francois whether Proxy-Require/Require had been
considered, but I don't remember what the answer was. So maybe someone
could repeat :)

I am a little confused when I hear "there is no secure TEL URL". To me
the encryption is more related to the SIP signalling as such, rather
than to what URL scheme is used...

Regards,

Christer

> Sent: 27. maaliskuuta 2007 23:13
> Subject: [Sip] RE: Securing Other URI (Tel URI) scheme
> 
> Apart from just doubling the URIs schemes and documentation 
> pains everytime, It will double the entries in DNS, Registrar too. 
> 
> Loose routing got adopted against the strict routing. Though 
> we provided the backward compatibility as Strict Routing was 
> DEPLOYED. 
> 
> Here SIPS is not deployed, then why not deprecate it. (Pl 
> correct me, if I am wrong) Cost will be on the early implementers. 
> 
> The next version of cipher-suite draft will be more problem 
> centric and talking about the each bit of the problem with SIPS.
> 
> Thx
> Samir
> 
> [email-masked] for questions on current sip

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Mar 2007 18:31:57 -0500

The answer was, "yes, it has been considered".

But it has been determined that it would cause more harm to change from
SIPS to another mechanism at 
this point, because of the precedent in RFC 3261.

It's probably somewhere in the archives for and various reports.

> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: Tuesday, March 27, 2007 15:45
> To: Srivastava, Samir (SC100:8826); Sean Olson; Audet, 
> Francois (SC100:3055); IETF SIP List
> Cc: Dean Willis
> Subject: RE: [Sip] RE: Securing Other URI (Tel URI) scheme
> 
> 
> Hi,
> 
> In Prague I asked Francois whether Proxy-Require/Require had 
> been considered, but I don't remember what the answer was. So 
> maybe someone could repeat :)
> 
> I am a little confused when I hear "there is no secure TEL 
> URL". To me the encryption is more related to the SIP 
> signalling as such, rather than to what URL scheme is used...
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
>  
> 
> > Loose routing got adopted against the strict routing. Though we 
> > provided the backward compatibility as Strict Routing was DEPLOYED.
> > 
> correct me, 
> > if I am wrong) Cost will be on the early implementers.
> > 
> > The next version of cipher-suite draft will be more problem centric 
> > and talking about the each bit of the problem with SIPS.
> > 
> > Thx
> > Samir
> > 
> > > URIs for secure routing. Secure Routing requirement is 
> settled once
> > for

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Tue, 27 Mar 2007 20:03:04 -0400

I also agree upgrading should not be allowed to make life simpler, but my
concern is isn't it too late?

I mean how many 3261-compliant boxes out there will retarget upgrade?  So if
sips suddenly becomes a (more) popular thing, how would the UAS know if the
request traversed a 3261-only proxy which upgraded, vs. traversed this newer
proposal proxies only?

It will have to do the checks no matter what, no?  And the bad scenario of
sips contact can still occur. (or maybe I missed the point)
But at least if you specify NOT to do it and why in your draft then it will
help proxy makers avoid the sips contact issue.  So it still has some value.

-hadriel

> From: Francois Audet [mailto:[email-masked]]
> Sent: Tuesday, March 27, 2007 3:36 PM
> To: Jonathan Rosenberg; IETF SIP List
> Subject: RE: [Sip] sips: upgrading allowed or not
>

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Mar 2007 19:04:09 -0500

At the Prague meeting, there was a discussion on Future work in
specification for SIP security.

The idea was to discuss ideas on what we should tackle next after
finishing up
SIPS. There is an Appendix A in draft-ietf-sip-sips-02 on this.

For example, it could include one or many of the following:

- The SIPSEC proposal (i.e., proxies that upgrade to a mode that tunnel
TLS end-to-end)?

- Verifiable assertions that SIPS was used on each hops?

- (Bring your own ideas: proxy-require, etc.)

Countrary to expectations, we didn't get much enthousiasm from the group
at all in Prague. 
It seems now that it's moved to the mailing list, that there is a
renewed interest from a 
few people that were not in Prague or didn't care to comment at the
meeting.

I'd encourage people to bring in constructive ideas on those topics if
you really care
about it. It won't happen on it's own.

---

From: "Samir Srivastava" <[email-masked]>
Date: Tue, 27 Mar 2007 19:11:39 -0500

Looks like we are recommending to use tels etc. 

I have not seen even a single engineering reason to keep SIPS. Instead
of just giving the argument that SIPS is in 3261. So we want to pursue
it. 3261 has many bugs, I treat it as one of them, which is result of
series of mistakes.

Thx
Samir

PS: Email list consensus provides more matured decisions as it addresses
wider audience. 

> Sent: Tuesday, March 27, 2007 4:32 PM
> To: Christer Holmberg (JO/LMF); Sean Olson; IETF SIP List
> Cc: Dean Willis
centric

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 27 Mar 2007 19:17:39 -0500

I'm not sure I follow your point...

If you "upgrade", you will know soon enough because things will start
breaking, and you'll get customer complaints. This "breaking" part is
the
reason why I want to deprecate upgrades.

As for the "checks", it seems to me that using SIPS as a "check" is not
a good idea (at least on it's own) as it is very weak. To me, that's one
of the possible topic for "Furture work in specification". I think this
section on checks is misleading and it contradicts other parts of the 
document that explain that SIPS is not an indication that the request
was indeed forwarded over TLS on each hop.

If people think we need a indication of end-to-end security (of of
security
on each hop), then bring it in. That's what I tought people wanted to
talk
about in Prague...

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Tuesday, March 27, 2007 17:03
> To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF 
> SIP List'
> I also agree upgrading should not be allowed to make life 
> simpler, but my concern is isn't it too late?
> 
> I mean how many 3261-compliant boxes out there will retarget 
> upgrade?  So if sips suddenly becomes a (more) popular thing, 
> how would the UAS know if the request traversed a 3261-only 
> proxy which upgraded, vs. traversed this newer proposal proxies only?
> 
> It will have to do the checks no matter what, no?  And the 
> bad scenario of sips contact can still occur. (or maybe I 
> missed the point) But at least if you specify NOT to do it 
> and why in your draft then it will help proxy makers avoid 
> the sips contact issue.  So it still has some value.
> 
> -hadriel
> 
> 
> > rethorical arguments out of it, and stick to protocol.
> > 
> > - Disallowing re-targeting "upgrades" from SIP to SIPS by a proxy 
> > would be
> > - The fact that it is currently allowed means that the UAS 
> receiving 
> > the request
> >   has to go through some fairly esoteric logic to "guess" if the 
> > request was
> >   sent securily on each hop or not. This is described in 
> paragraph 4 
> > of p. 250,
> >   and section 4.1 of draft-ietf-sip-sips-02 also describes it, with 
> > some modifications.
> >   Those procedures are extremely cludgy and non-deterministic. They 
> > are also misleading
> >   (i.e., for the other scenarios of forwarding and retargeting). In 
> > all other instances,
> >   the idea is that when a request is forwarded/retargeted, 
> the scheme 
> > is preserve.
> > 	- Jonathan Peterson was proposing that the UAS inspect 
> the To header 
> > to see if
> >         the request was initially targeted at SIPS. This is 
> a subset 
> > of the procedures
> >         of 4.1/draft-ietf-sip-sips and of RFC 3261 (they add stuff 
> > like looking at
> >         Via and other fields).
> > 
> >   for downgrading, the SIPS-to-SIP Record-Route scenario will be 
> > removed from the
> > - Because of rules described in RFC 3261, if a UAS receives an 
> > incoming request with a
> >   If Record-Routing is not used, it will just plainly not work. The 
> > UAC will not be
> >   able to send further requests (like BYE for example). If 
> > Record-Route is used, it
> >   that the UAC might "choke" on the SIPS URI in the Contact 
> (because 
> > it doesn't understand
> >   how to parse it).
> > 
> > - Note that it would still be possible to "upgrade" by sending SIP 
> > over TLS. In fact, I would
> >   argue that we need to put a requirement to do so when there is 
> > already a TLS connection
> >   opened with the target (as would be the case if Outbound 
> was used, 
> > and the registration was
> >   done over TLS).
> > 
> > > During the Prague IETF, I shared some opinions on what I thought 
> > > sips needs to look like and why, and wanted to take these to the 
> > > list.
> > >
> > > that it can't get with TLS on some hops, as needed?
> > > The answer is that certain security benefits are afforded 
> if we can 
> > > assure that every single hop from UAC to UAS was TLS 
> protected, and 
> > > that furthermore, this fact can be definitively known by the UAC, 
> > > UAS, and all proxies along the way. If we make the 
> assumption that 
> > > the UA's trust their proxies (please don't question the 
> assumption 
> > > in this thread), then SIPS provides you some very nice security 
> > > Given that, sips is broken if it doesn't provide that 
> service (tls 
> > > on each hop with knowledge of such by all entities). FOr this 
> > > reason, I think we need to eliminate the last hop exception 
> > > (uncontroversial I think), but furthermore, I believe 
> this extends 
> > > to retargeting as well.
> downgrading from 
> > > a sips URI to a sip URI. I think that was also largely 
> > > non-controversial.
> from sip 
> > > inserts a sips URI into the To field and R-URI field when 
> it emits a 
> > > sips request, does not the presence of a sips URI in the 
> TO field, 
> > > and receipt over a TLS connection, assure that the request was 
> > > delivered over TLS at each hop? Had the request been sent 
> originally 
> > > to a sip URI and then upgraded, the TO field would not have been 
> > > sips, but rather sip.
> > >
> > > idea.
> redirection 
> > > was that the UAS *wanted* TLS on each hop, recursing in 
> the middle 
> > > UAC TO UAS*. To me, this is fundamentally at odds with 
> any notion of 
> > > upgrade or downgrade.
> > >
> eliminate the 
> > > easier. SIPS means one thing and one thing only and its terribly 
> > > clear what it means.
> > >

---

From: Dean Willis <[email-masked]>
Date: Tue, 27 Mar 2007 21:58:14 -0500

On Mar 27, 2007, at 7:03 PM, Hadriel Kaplan wrote:

> upgrade?  So if

That's the "Verifiable assertions that SIPS was used on each hop"  
question from the "Future work" section of the draft, right?

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 28 Mar 2007 07:36:57 +0300

> all using Proxy-Require / Require. 

and then you don't need sips either.  it makes no sense to have sips
without tels and i would like to get rid of both.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 28 Mar 2007 07:38:43 +0300

Sean Olson writes:

 > Ahhh, yes.  Now I remember why SIPS was a bad idea. A
 > proxy-require/require solution might work, just be prepared for zero
 > adoption.

what would be great.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 28 Mar 2007 07:52:40 +0300

> this point, because of the precedent in RFC 3261.

rfc 3261 precedent means nothing in case of fully broken sips.  if there
is another mechanism that does not require use of sips or tels uri
schemes, we much seriously consider it rather trying to sweep it under
the carpet.

-- juha

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Mar 2007 15:41:35 +0200

Hi,

The advantage of using Require/Proxy-Require (I use that as a generic
term for a non-SIPS solution) is that it would allow the change of the
scheme in the network, without affecting the signalling security.

Another advantage would be that it would be possible to also put
requirements not related to a specific security mechanism. For example,
if I require "security" I would reach the remote user even if some hop
is protected by a non-TLS mechanism (IPSEC, for example).

Regards,

Christer

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: 28. maaliskuuta 2007 7:53
> To: Francois Audet
> Cc: Christer Holmberg (JO/LMF); Sean Olson; IETF SIP List; Dean Willis
>  > But it has been determined that it would cause more harm 
> to change from  > SIPS to another mechanism at  > this point, 
> because of the precedent in RFC 3261.
> 
> rfc 3261 precedent means nothing in case of fully broken 
> sips.  if there is another mechanism that does not require 
> use of sips or tels uri schemes, we much seriously consider 
> it rather trying to sweep it under the carpet.
> 
> -- juha
>

---

From: EKR <[email-masked]>
Date: Wed, 28 Mar 2007 06:52:38 -0700

> is protected by a non-TLS mechanism (IPSEC, for example).

It's not clear that this is a good thing. The security (authentication)
properties of TLS are not necessarily the same as those offered by IPsec.

-Ekr

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Mar 2007 16:49:30 +0200

Hi, 

>>requirements not related to a specific security mechanism. For 
>>example, if I require "security" I would reach the remote user even if

>>some hop is protected by a non-TLS mechanism (IPSEC, for example).
> 
>It's not clear that this is a good thing. The security 
>(authentication) properties of TLS are not necessarily the 
>same as those offered by IPsec.

What are the security properties required by SIP?

Regards,

Christer

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 28 Mar 2007 10:03:16 -0500

> What are the security properties required by SIP?

A stab is in S13 of domain-certs:

    The goals of TLS include the following security guarantees at the
    transport layer:

    Confidentiality:  packets tunneled through TLS can only be read by
       the sender and receiver.
    Integrity:  packets tunneled through TLS can only be modified by the
       sender and receiver.
    Authenticity:  each principal is authenticated to the other as
       posessing a private key for which a certificate has been issued.
       Moreover, this certificate has not been revoked, and is backed by
       a certificate chain leading to a mutually trusted trust anchor.

    We expect that appropriate processing requirements of domain
    certificates will provide the following security guarantees at the
    application level: [...]

- vijay

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 28 Mar 2007 10:43:08 -0500

Yes. 

> Sent: Tuesday, March 27, 2007 19:58
> To: Hadriel Kaplan
> Cc: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF 
> SIP List'
> > I mean how many 3261-compliant boxes out there will 
> retarget upgrade?  
> > So if sips suddenly becomes a (more) popular thing, how 
> would the UAS 
> > know if the request traversed a 3261-only proxy which upgraded, vs. 
> > traversed this newer proposal proxies only?
> >
> > It will have to do the checks no matter what, no?  And the bad 
> > scenario of sips contact can still occur. (or maybe I missed the 
> > point) But at least if you specify NOT to do it and why in 
> your draft 
> > then it will help proxy makers avoid the sips contact issue.  So it 
> > still has some value.
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 28 Mar 2007 10:51:10 -0500

Chris,

I have a problem with the process here. We have reached a decision many
months ago.
The problem has not changed.

Please go back and read the archives. 

> Sent: Wednesday, March 28, 2007 07:50
> To: EKR
> Cc: Juha Heinanen; Audet, Francois (SC100:3055); IETF SIP 
> List; Sean Olson; Dean Willis
> >(authentication) properties of TLS are not necessarily the same as 
> >those offered by IPsec.
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Mar 2007 18:02:45 +0200

Hi Francois,

You wrote an e-mail ([Sip] Future work in specification on SIP
Security), asking to bring own ideas, but I missed the part saying that
it should be about what shall be done AFTER the SIPS work is done.

However, it does seem that some people (Juha etc) don't agre to the
decision which was made months ago, but I will let them speak for
themselves :)

Regards,

Christer

> Sent: 28. maaliskuuta 2007 18:51
> To: Christer Holmberg (JO/LMF)
> Cc: IETF SIP List; Dean Willis
> I have a problem with the process here. We have reached a 
> decision many months ago.

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Mar 2007 19:58:17 +0200

Hi,

I am not a security expert, but aren't the security properties rather
similar for IPSEC? And, IPSEC also works for UDP.

However, the point was not to compare TLS with IPSEC (IPSEC was just
given as an example), but to find the signalling security requirements
for SIP.

Regards,

Christer

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: 28. maaliskuuta 2007 18:03
> Subject: Re: [Sip] RE: Securing Other URI (Tel URI) scheme
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Mar 2007 11:03:50 -0800

"Christer Holmberg \(JO/LMF\)" <[email-masked]> writes:
> similar for IPSEC?

Well, it depends on exactly how you're running IPsec. Not if
(for instance) you have a VPN tunnel tied up between VPN
concentrators between the sites, no.

> And, IPSEC also works for UDP.

Cf. RFC 4347.

> given as an example), but to find the signalling security requirements

Yes, and part of the object is to have some predictability about
what those would be, which isn't served by saying "you must do
some kind of security". 

-Ekr

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 28 Mar 2007 20:17:34 +0200

Hi, 

>(for instance) you have a VPN tunnel tied up between VPN concentrators
between the sites, no.

>>for SIP.
> 
>Yes, and part of the object is to have some predictability 
>about what those would be, which isn't served by saying "you 
>must do some kind of security". 

Well, that "any kind of security" would of course have to be compliant
with whatever security requirements we have for SIP.

The security requirements COULD also be depending on the type of "link".
I am sure there are environments where VPN tunnels are used, and provide
sufficiant security, so should security mandated requests not be allowed
to use such tunnels?

The question is: IF we want to have a solution which requires security
between all nodes, UA-to-UA, will a you-must-use-TLS-only solution be
feasible? Calls could fail, OR people could choose to use other security
mechanisms anyway...

Regards,

Christer

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 28 Mar 2007 13:25:03 -0500

The worst part of this, SIPS will enforce the double encryption between
two SIP addressable entities if there is IPSEC tunnel between them.

I agreed only on the BCP/INFORMATIONAL doc. 

There has been earlier poll on the list before San Diego, what people
wanted. I have discussed in details the demerits of SIPS during that
time period.

Please wait for the next version of the cipher-suite draft, before
proceeding to make SIPS as STANDARDS track document. 

Thx
Samir

> Sent: Wednesday, March 28, 2007 10:58 AM
> To: Vijay K. Gurbani
> Cc: IETF SIP List

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 28 Mar 2007 18:59:26 -0400

Hmmm... then I think I did miss your point.
Your point then is to remove the upgrade scenario from the draft, and any
attempt to make it work, and instead disallow it - and thus any legacy-3261
proxy in the path still doing it will be found out if it breaks things, and
subsequently fixed to not do so?

So my only point to that then is that it won't mean you can remove section
4.1 of your draft (though it should be reworded I guess) - because a sips
request arriving at a UAS is still not known to have started as sips,
because it may have crossed an upgrading legacy-3261/2543 proxy en route.

-hadriel

> Sent: Tuesday, March 27, 2007 8:18 PM
> To: Hadriel Kaplan; Jonathan Rosenberg; IETF SIP List

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 28 Mar 2007 18:09:32 -0500

> Your point then is to remove the upgrade scenario from the 
> draft, and any attempt to make it work, and instead disallow it

Correct. There is no way to make it work in real life.

I mean, if you want to ugrade there is a way to do it that
does work: you Redirect instead of retargeting.

>  - and thus any legacy-3261 proxy in the path still doing 
> it will be found out if it breaks things, and subsequently 
> fixed to not do so?

Huh? Legacy-3261 proxies doing upgrades? I've never seen such a
think, and I'd argue that it would be broken anyways if it did.

> 4.1 of your draft (though it should be reworded I guess) - 
> because a sips request arriving at a UAS is still not known 
> to have started as sips, because it may have crossed an 
> upgrading legacy-3261/2543 proxy en route.

We could leave it in there for "theoretical" legacy 3261 proxies doing
upgrades, but I think it will just encourage people to do evil (and it
will still break things).

Note that there was no SIPS in 2543, so it wouldn't apply there.

> > the reason why I want to deprecate upgrades.
> > 
> > As for the "checks", it seems to me that using SIPS as a "check" is 
> > not a good idea (at least on it's own) as it is very weak. To me, 
> > that's one of the possible topic for "Furture work in 
> specification". 
> > I think this section on checks is misleading and it 
> contradicts other 
> > parts of the document that explain that SIPS is not an 
> indication that 
> > the request was indeed forwarded over TLS on each hop.
> > 
> > security on each hop), then bring it in. That's what I 
> tought people 
> > wanted to talk about in Prague...
> > 
> > 
> > > To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF SIP 
> > > List'
> > > upgrade?  So if sips suddenly becomes a (more) popular thing, how 
> > > would the UAS know if the request traversed a 3261-only 
> proxy which 
> > > upgraded, vs. traversed this newer proposal proxies only?
> > >
> > > point) But at least if you specify NOT to do it and why in your 
> > > draft then it will help proxy makers avoid the sips 
> contact issue.  
> > > So it still has some value.
> > >
> > > -hadriel
> > >
> > >
> > > >   and section 4.1 of draft-ietf-sip-sips-02 also describes it, 
> > > > with some modifications.
> > > >   Those procedures are extremely cludgy and non-deterministic. 
> > > > They are also misleading
> > > >   (i.e., for the other scenarios of forwarding and 
> retargeting). 
> > > > In all other instances,
> > > >   If Record-Routing is not used, it will just plainly not work. 
> > > > The UAC will not be
> > > > - It greatly simplifies the draft, eliminating sections 4.1 and 
> > > > 4.2 completely.
> > > >
> > > > > that furthermore, this fact can be definitively known by the 
> > > > > UAC, UAS, and all proxies along the way. If we make the
> > > assumption that
> non-trusted 
> > > > > works much better. Such a redirection would necesarily have to
> > > go all the
> > > > > way to the UAC. If we allow upgrades, a proxy in the middle 
> > > > > could recurse and upgrade. In that case, if the reason for the
> > > redirection
> > > > > Use [email-masked] for new developments on the 
> application of 
> > > > > sip
> > > > >
> > > >

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 28 Mar 2007 19:17:58 -0400

Hey Samir,
Inline...

> Sent: Tuesday, March 27, 2007 8:12 PM
> To: Francois Audet; Christer Holmberg (JO/LMF); Sean Olson; IETF SIP List
> Cc: Dean Willis

I don't think that's what people are saying.  I think they are just saying
that for sips.

> it. 3261 has many bugs, I treat it as one of them, which is result of

Well I can give one: it has the same semantics and security property you get
with a syntax of Require/Proxy-require:tls.  So the argument was made that
if you have the syntax already in place for those semantics with "sips", and
it's in the RFC, and a crap-load of other RFCs reference using it, then
fixing the mechanics but keeping the syntax is less work and time than a new
syntax.  It actually has another property which requires/proxy-require won't
as easily: namely that you know the tls requirement before sending the
request, because either the user entered sips, or it was discovered through
DNS.

> PS: Email list consensus provides more matured decisions as it addresses

...and seems to create discussion loops. ;)

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 28 Mar 2007 19:39:53 -0400

> think, and I'd argue that it would be broken anyways if it did.

Yup, me neither.  I wonder if openser or one of those did it.

> will still break things).

Yeah, I don't care much - just thinkin' it may be good to check such things
at the UAS regardless.  Rejecting the request for such will be a fine
deterrent, imho.

> Note that there was no SIPS in 2543, so it wouldn't apply there.

Huh.  Yup, my mistake.  Maybe we should make 2543 obsolete 3261, at least on
April 1st. :)

-hadriel

---

From: "Samir Srivastava" <[email-masked]>
Date: Wed, 28 Mar 2007 18:48:10 -0500

Hi Hadriel,

Sorry I am still catching up this thread.

My understanding was that this document will just state what SIPS
provides as per 3261 .
Nothing to modify the behaviour of 3261. Looks like, we are patching it
for STANDARDS track doc.

Let us stop worrying more about upgrade etc, till we see at one place
(in the next version of cipher-suites) ugliness of the SIPS and the need
for the clear defintion of secure protocols etc, and then decide do we
need to spend cycles on this stuff. 

BTW, there is no SIPS in 2543. I don't recollect which bis got it added.
Here legacy should mean 3261 only, if SIPS doesn't get deprecated, and
we start working on 3261 bis etc...

Thx
Samir

>Sent: Wednesday, March 28, 2007 3:59 PM
>To: Audet, Francois (SC100:3055); 'Jonathan Rosenberg'; 'IETF SIP List'
>draft, and any attempt to make it work, and instead disallow 
>it - and thus any legacy-3261 proxy in the path still doing it 
>will be found out if it breaks things, and subsequently fixed 
>to not do so?
>
>because a sips request arriving at a UAS is still not known to 
>have started as sips, because it may have crossed an upgrading 
>legacy-3261/2543 proxy en route.
>
>-hadriel
>
>
>> security on each hop), then bring it in. That's what I tought people 
>> > I also agree upgrading should not be allowed to make life simpler, 
>> > but my concern is isn't it too late?
>> >
>> > >   (i.e., for the other scenarios of forwarding and retargeting). 
>> > > In all other instances,

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 28 Mar 2007 20:18:19 -0400

But the cipher-suites draft does not show me the ugliness of sips.  I
believe your draft is trying to convince me what's broken about sips is that
you don't know how "secure" the links sips forces you to use are, and thus
the UAC/UAS need to control and know the level of that link security.
(whereby you define their security level as the used ciphersuite?)

Right?

If so I think we are in a 180-degree opposite view of what's "broken" about
sips.  To me, making sure the ciphersuite is "strong" enough is like adding
reinforcements to the Maginot line.

-hadriel

> Sent: Wednesday, March 28, 2007 7:48 PM
> To: Hadriel Kaplan; Francois Audet; Jonathan Rosenberg; IETF SIP List

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Mar 2007 11:40:28 -0500

On Mar 28, 2007, at 6:17 PM, Hadriel Kaplan wrote:

> with a syntax of Require/Proxy-require:tls.

not exactly, and this is exactly the point of been trying to make  
about why changing the behavior of sips: without making any other  
changes is pointless.

Assume we update 3261 with new mandatory behavior for sips: request  
URIs.

An existing proxy that doesn't conform to the new requirements (and  
therefore does up/downgrades) will still give us an indeterminate  
state. Was the request sips: on all hops? There is no evil required  
for this to happen, just obsolescence.

Assume instead a new extension option tag that requires proxies  
understanding it to implement the new behavior for sips:. We use this  
in Requires and Proxy-Requires whenever a "new behavior" UAC creates  
a request with a sips: r-uri. I'd call this mode "required sips:".

Any reasonable existing UA or proxy will reject a request that  
Requires/Proxy-Requires an option not understood by that UA or proxy.

Any reasonable new UA or proxy understanding the new extension can be  
expected to implement the new required behavior.

While this doesn't give us assurance that there were no evil proxies  
on the path, it does give us an assurance that there were no obsolete  
proxies that couldn't be reasonably expected to have done "the right  
thing" with sips:.

It's a "fail safe" instead of "fail dangerous" distinction.

If it turns out that we have an obsolete node on the path that don't  
understand the extension, we could (after informing the user of the  
problem) retry the request without the option tag, thereby falling  
back to the current "best effort" sips:.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 29 Mar 2007 12:01:39 -0500

I don't agree.

I think this is theoretical. I don't believe proxies that "upgrade" 
from SIP to SIPS using a retargeting exist in nature. And if they did,
they
would likely break stuff, or have some assumptions that makes them 
essentially proprietary. It just doesn't work except for some very
narrow sceanrios (e.g., transactions that don't create a dialog, or
dialogs
with double Record-Route used at the retargeting point, along with
endpoints that
don't understand SIPS but somehow don't choke on the scheme, use of SIP
outbound
which is not standard yet, etc.). Same Parsippany, NJ  
> > 07054-2711

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 29 Mar 2007 12:01:39 -0500

I don't agree.

which is not standard yet, etc.). Same applies for downgrades. 

So to me, it's a non-issue.

>From a standard's purist dreamland point of view, we could define
this extension: it would not "break" anything. It would just make
the spec more complicated for no good reason.

> Sent: Thursday, March 29, 2007 09:40
> To: Hadriel Kaplan
> Cc: Srivastava, Samir (SC100:8826); Audet, Francois 
> (SC100:3055); 'Christer Holmberg (JO/LMF)'; 'Sean Olson'; 
> 'IETF SIP List'
> > Well I can give one: it has the same semantics and security 
> property 
> > you get with a syntax of Require/Proxy-require:tls.
> 
> not exactly, and this is exactly the point of been trying to 
> make about why changing the behavior of sips: without making 
> any other changes is pointless.
> 
> Assume we update 3261 with new mandatory behavior for sips: 
> request URIs.
> 
> An existing proxy that doesn't conform to the new 
> requirements (and therefore does up/downgrades) will still 
> give us an indeterminate state. Was the request sips: on all 
> hops? There is no evil required for this to happen, just obsolescence.
> 
> 
> Assume instead a new extension option tag that requires 
> proxies understanding it to implement the new behavior for 
> sips:. We use this in Requires and Proxy-Requires whenever a 
> "new behavior" UAC creates a request with a sips: r-uri. I'd 
> call this mode "required sips:".
> 
> Any reasonable existing UA or proxy will reject a request 
> that Requires/Proxy-Requires an option not understood by that 
> UA or proxy.
> 
> Any reasonable new UA or proxy understanding the new 
> extension can be expected to implement the new required behavior.
> 
> While this doesn't give us assurance that there were no evil 
> proxies on the path, it does give us an assurance that there 
> were no obsolete proxies that couldn't be reasonably expected 
> to have done "the right thing" with sips:.
> 
> If it turns out that we have an obsolete node on the path 
> that don't understand the extension, we could (after 
> informing the user of the
> problem) retry the request without the option tag, thereby 
> falling back to the current "best effort" sips:.
> 
> --
> Dean
> 
> 
> 

applies for downgrades. 

So to me, it's a non-issue.

>From a standard's purist dreamland point of view, we could define
this extension: it would not "break" anything. It would just make
the spec more complicated for no good reason.

> Sent: Thursday, March 29, 2007 09:40
> To: Hadriel Kaplan
> Cc: Srivastava, Samir (SC100:8826); Audet, Francois 
> (SC100:3055); 'Christer Holmberg (JO/LMF)'; 'Sean Olson'; 
> 'IETF SIP List'
> > Well I can give one: it has the same semantics and security 
> property 
> > you get with a syntax of Require/Proxy-require:tls.
> 
> not exactly, and this is exactly the point of been trying to 
> make about why changing the behavior of sips: without making 
> any other changes is pointless.
> 
> Assume we update 3261 with new mandatory behavior for sips: 
> request URIs.
> 
> An existing proxy that doesn't conform to the new 
> requirements (and therefore does up/downgrades) will still 
> give us an indeterminate state. Was the request sips: on all 
> hops? There is no evil required for this to happen, just obsolescence.
> 
> 
> Assume instead a new extension option tag that requires 
> proxies understanding it to implement the new behavior for 
> sips:. We use this in Requires and Proxy-Requires whenever a 
> "new behavior" UAC creates a request with a sips: r-uri. I'd 
> call this mode "required sips:".
> 
> Any reasonable existing UA or proxy will reject a request 
> that Requires/Proxy-Requires an option not understood by that 
> UA or proxy.
> 
> Any reasonable new UA or proxy understanding the new 
> extension can be expected to implement the new required behavior.
> 
> While this doesn't give us assurance that there were no evil 
> proxies on the path, it does give us an assurance that there 
> were no obsolete proxies that couldn't be reasonably expected 
> to have done "the right thing" with sips:.
> 
> If it turns out that we have an obsolete node on the path 
> that don't understand the extension, we could (after 
> informing the user of the
> problem) retry the request without the option tag, thereby 
> falling back to the current "best effort" sips:.
> 
> --
> Dean
> 
> 
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 29 Mar 2007 12:37:54 -0500

Hi,

   When I wrote the 00 version of cipher-suite, I was in the impression
that community understands the ugliness of the SIPS. As there were many
wacky threads for it. So it was just talking about the solution.

Proxy-Require tag for Secure-Protocol/Cipher-suite makes the SIPS
REDUDANT
all together. Here it should be noted that we are talking about the
Secure-Protocol (Which can be DTLS too). Where current definition of
SIPS as per 3261 is completely broken. 3261 has tied the SIPS to TLS.
SIPS is no future proof with respect to secure protocol development too.

Thx
Samir

> Sent: Wednesday, March 28, 2007 5:18 PM
> To: Srivastava, Samir (SC100:8826); Audet, Francois (SC100:3055);
> 'Jonathan Rosenberg'; 'IETF SIP List'
> Subject: draft-srivastava-sip-e2e-ciphersuites-00 (was: upgrading
allowed
> or not)
> believe your draft is trying to convince me what's broken about sips
is
> that

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 29 Mar 2007 12:49:08 -0500

Hi,

Thx Dean for explanation.

> back to the current "best effort" sips:.

Alternatively consider the following scenario

UAC --- P1 ---- P2 ------- UAS
        |                   |
        |-------P3 ---------|

Here If Provider of Proxy P2 doesn't understand the secure-tag, P1 can
route the via P3 which understands the secure-tag. So owner of P2 will
start loosing the revenue. And he will be forced to upgrade. $ is the
biggest motivation.  

May I request the group to give me couple of weeks to update the
cipher-suite. 

Thx
Samir

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Mar 2007 14:11:44 -0500

> the spec more complicated for no good reason.

I used to have a proxy at the house that would retarget inbound from  
sips to sip to let my old 3Com phone work. It would also retarget sip  
to sips outbound so I could call sips (said proxy is why I insisted  
on last-hop exception in 3261). Such proxies do exist.

The good news is, I don't use it anymore (the bad news is I don't  
have a working SIP phone at home right now).

So (Chair Hat on): Anybody else out there have a proxy currently (or  
planned to be) in use that retargets sip to sips or vice versa?

If we can't come up with any, I suppose I'd be willing to concede the  
issue as "fixing an improbable problem"

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 29 Mar 2007 15:18:12 -0500

Dean,

Draw me a call flow on how your phone dealt with SIPS in the Contact of
that INVITE then. How did your phone NOT choke on it?

Did it ignore the Contact?

Did you proxy do Double Record-Route?

Or was your proxy really a B2BUA "fixing" all this stuff? 

My assertion is that without using a B2BUA you can't really fix this, or
you have to "cheat" somewhere.

> Sent: Thursday, March 29, 2007 12:12
> To: IETF SIP List
> Subject: Poll: Do we have sips/sip retageting in the wild 
> (was Re: [Sip] RE: Securing Other URI (Tel URI) scheme)
> 
> 
> > they would likely break stuff, or have some assumptions that makes 
> > them essentially proprietary. It just doesn't work except for some 
> > very narrow sceanrios (e.g., transactions that don't create 
> a dialog, 
> > or dialogs with double Record-Route used at the retargeting point, 
> > along with endpoints that don't understand SIPS but somehow don't 
> > choke on the scheme, use of SIP outbound which is not standard yet, 
> > etc.). Same applies for downgrades.
> >
> > From a standard's purist dreamland point of view, we could 
> define this 
> > extension: it would not "break" anything. It would just 
> make the spec 
> > more complicated for no good reason.
> 
> I used to have a proxy at the house that would retarget 
> inbound from sips to sip to let my old 3Com phone work. It 
> would also retarget sip to sips outbound so I could call sips 
> (said proxy is why I insisted on last-hop exception in 3261). 
> Such proxies do exist.
> 
> The good news is, I don't use it anymore (the bad news is I 
> don't have a working SIP phone at home right now).
> 
> So (Chair Hat on): Anybody else out there have a proxy 
> currently (or planned to be) in use that retargets sip to 
> sips or vice versa?
> 
> If we can't come up with any, I suppose I'd be willing to 
> concede the issue as "fixing an improbable problem"
> 
> --
> Dean
> 
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 29 Mar 2007 15:25:22 -0500

> issue as "fixing an improbable problem"

Thx for arriving to "fixing an improbable problem". I am more interested
in knowing the DEPLOYED part of this, instead of planning / implementing
/ coding etc part of SIPS.

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 29 Mar 2007 15:56:37 -0500

In-line.

Thx

Samir

> Sent: Thursday, March 29, 2007 1:18 PM

> To: Dean Willis; IETF SIP List

> Subject: RE: Poll: Do we have sips/sip retageting in the wild (was Re:

> [Sip] RE: Securing Other URI (Tel URI) scheme)

 

  Even if Dean draws the call flow, they will be hypothetical. 

They can be actual, only if he had stored somewhere.

As he doesn't have a working SIP phone. See the below highlighted
contents. 

I am more interested in knowing the DEPLOYED call flows of SIPS, 

not in those, which people wrote in the several RFCS.

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Mar 2007 18:03:36 -0500

> Did it ignore the Contact?

The phone, as I recall, just ignored the contact -- that is, assumed  
it was sip. It would have done very odd things with a tel: URL, I  
think. The code in the phone was maybe sip-04 (pre 2543) . . .

but it would be pretty straightforward to have the proxy patch the  
Contact: as it traverses. Not legal, but how many implementations  
strictly are?

> Did you proxy do Double Record-Route?

No, it replaced its entry with the "right thing" as it proxied.

> you have to "cheat" somewhere.

Back in those days, making ANYTHING work was a cheat.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 29 Mar 2007 18:13:40 -0500

> The phone, as I recall, just ignored the contact -- that is, 
> assumed it was sip. It would have done very odd things with a 
> tel: URL, I think. The code in the phone was maybe sip-04 
> (pre 2543) . . .
> 
> Contact: as it traverses. Not legal, but how many 
> implementations strictly are?

That was exactly my point about using a B2BUA (i.e., "patching" the 
signalling) and about cheating (i.e., "ignoring" the contact and respond
to where the message came from). Looks like I guessed right.

To me solutions like this "don't count" because they are not
SIP-compliant. 

In fact, even with us deprecating upgrades and downgrades, the reality
is that a B2BUA or SBC will still be able to "patch" everything to 
do upgrades or downgrades in the way you describe.

That is why I see this "upgrade" requirement as a red herring. I'd
rather
we make it clean for SIP (and if people do B2BUA stuff, that's their
right).

---

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 29 Mar 2007 18:15:49 -0500

Hi,

   So for me it is no more valid case. If there is no SIPS deployments,
why we keep trying to patch it. We already seen so many pitfalls of it
on the list.

  In couple of weeks, we will be having next version of cipher-suite,
till then can we postpone the discussions on the patching the SIPS.

Thx
Samir

> Sent: Thursday, March 29, 2007 4:04 PM
> To: Audet, Francois (SC100:3055)
> Cc: IETF SIP List
> Subject: Re: Poll: Do we have sips/sip retageting in the wild (was Re:

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 29 Mar 2007 22:24:22 -0400

But your solution for the problem implies the problem with sips is it does
not let the UAC define the specific ciphersuites to use hop-by-hop, and in
particular as if defining new "stronger" ones will make it more secure and
thus more popular.

To me that is not the problem.  It is not because sips does not provide
strong enough security between hops that people don't use sips broadly.
People don't use it because (a) the request fails too often because the odds
of having TLS for the full hop path is very low, or (b) they either don't
perceive the dangers, or don't consider their communication sensitive enough
to justify the cost burden.  Obviously there is a third camp of people who
don't trust the hop-by-hop nature to begin with, but for them there is no
possible solution short of direct end-end communication or a sipsec model.

For the group that's in (a), in some ways that's by design.  If you consider
your request sensitive such that only hop-by-hop TLS is good enough, then
you should want the request to fail if it cannot meet those constraints.

-hadriel

> Sent: Thursday, March 29, 2007 1:38 PM
> Subject: RE: draft-srivastava-sip-e2e-ciphersuites-00 (was: upgrading
> allowed or not)
> 
> Hi,
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Mar 2007 22:52:42 -0500

> To me solutions like this "don't count" because they are not

But they're deployed. And if we advance a solution that makes real  
deployments worse without providing an error detection and correction  
mechanism, I'm not sure I'd feel good about it. OTOH, if we can't  
find any real deployments actually doing this any more, I'll feel  
less bad..

> do upgrades or downgrades in the way you describe.

True. And that's my other point -- given the way that sips works, you  
really can't assume that things really were properly secured just  
because the r-uri and To: had "sips:" in them.

> we make it clean for SIP (and if people do B2BUA stuff, that's their

Both the "just do it" and "Requires" model are reasonably clean for SIP.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 29 Mar 2007 22:55:01 -0500

> why we keep trying to patch it. We already seen so many pitfalls of it

There ARE some sips: deployments. There may not be any that are doing  
upgrading and downgrading.

I believe that sips: is valuable enough to fix, even if it isn't  
perfect.

I would ALSO like to have something that goes beyond sips: and  
provides real end-to-end protection but is actually deployable (which  
I'm not quite sure the s/mime proposals are).

--
Dean

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 30 Mar 2007 00:43:11 -0500

Hi Dean,

    In-line. Changed the Subject too and avoided cascaded References
there.

Thx
Samir

>
>There ARE some sips: deployments. There may not be any that 
>are doing upgrading and downgrading.

This is the first time, I am hearing on the list that there are SIPS
DEPLOYMENTS.

Now I would like to know more details about it. Whether they are within
the controlled domains likes within the enterprise? Are they across the
providers domains ? I am assuming that they are not like the ones you
mentioned earlier. 

If it has prevailing reasons, then I might have to think on the BACKWARD
COMPATIBLE solutions. 

>
>I believe that sips: is valuable enough to fix, even if it 
>isn't perfect.

This is where I have complete disconnect. Whatever solution
Proxy-Require/Require with
Secure protocols etc or any other we come up, they will not be able to
provide any ASSURED level of security feeling, once they hit SIPS
islands. I will restate my earlier analogy "strength of a chain is the
strength of the weakest link".  

When we don't care about "when the request hits PSTN cloud, and what
happens afterwards." As this is UNSOLVABLE problem, due to ubiquitous
nature of PSTN, and we cannnot have anything like security defined
there. 

In the light of above point "Should we at all consider SIPS islands." It
is left for readers to calculate the SIPS deployment % w.r.t. PSTN
clouds. Is it not worth to deprecate SIPS ? If we don't deprecate SIPS,
there will be cases of interops etc even if we move to complete IP
world....

>provides real end-to-end protection but is actually deployable 
>(which I'm not quite sure the s/mime proposals are).

Great. Sorry I haven't read till now, your referenced RFC for IETF
opinion on CALEA. But as far as I know, FCC will not let anything
deployed which cannot be tapped. I have yet to look into the Vijay's and
your replies on the SIPSEC.

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 30 Mar 2007 02:05:51 -0500

Added to the given arguments, do we want similar pains of SIP over UDP,
with SIPS in the coming future ? If we don't deprecate it now, I fear it
will be never.... 

We have been discussing about the SIPS for a long time, good luck to
those who are using it. How big are these deployments ? 

If they don't do retargeting, how they do REFER ? Loose Routing/Strict
Routing etc.. How do they support feature control for the REG-EV and
Presence watchers ?

Thx
Samir

>Sent: Thursday, March 29, 2007 10:43 PM
>To: Dean Willis
>Cc: IETF SIP List; Audet, Francois (SC100:3055)
>Subject: [Sip] SIPS Deployments ( Was Re: Poll: Do we have 
>sips/sip retageting in the wild )
>
>Hi Dean,
>
>    In-line. Changed the Subject too and avoided cascaded 
>References there.
>
>Thx
>Samir
>
>>
>This is the first time, I am hearing on the list that there 
>are SIPS DEPLOYMENTS.
>
>Now I would like to know more details about it. Whether they 
>are within the controlled domains likes within the enterprise? 
>Are they across the providers domains ? I am assuming that 
>they are not like the ones you mentioned earlier. 
>
>If it has prevailing reasons, then I might have to think on 
>the BACKWARD COMPATIBLE solutions. 
>
>>
>Proxy-Require/Require with Secure protocols etc or any other 
>we come up, they will not be able to provide any ASSURED level 
>of security feeling, once they hit SIPS islands. I will 
>restate my earlier analogy "strength of a chain is the 
>When we don't care about "when the request hits PSTN cloud, 
>and what happens afterwards." As this is UNSOLVABLE problem, 
>due to ubiquitous nature of PSTN, and we cannnot have anything 
>like security defined there. 
>
>In the light of above point "Should we at all consider SIPS 
>islands." It is left for readers to calculate the SIPS 
>deployment % w.r.t. PSTN clouds. Is it not worth to deprecate 
>SIPS ? If we don't deprecate SIPS, there will be cases of 
>interops etc even if we move to complete IP world....
>
>>
>>I would ALSO like to have something that goes beyond sips: 
>and provides 
>>real end-to-end protection but is actually deployable (which I'm not 
>>quite sure the s/mime proposals are).
>
>Great. Sorry I haven't read till now, your referenced RFC for 
>IETF opinion on CALEA. But as far as I know, FCC will not let 
>anything deployed which cannot be tapped. I have yet to look 
>into the Vijay's and your replies on the SIPSEC. 
>
>>
>>--
>>Dean
>>
>>
>

---

From: <[email-masked]>
Date: Fri, 30 Mar 2007 11:56:46 +0300

Hi,

In many discussions on this list and especially in the face-to-face
meetings people are often refering to "deployments" (or even
"large-scale deployments") of certain features. Recently this popped up
in the sips: URI discussion, where people are arguing whether sips: has
been deployed anywhere or not. The deployment claim is often used to
argue against changing or deprecating a certain mechanim. (Such as "we
can't change X in a non-backwards-compatible manner as it has been
widely 'deployed' already.) In some cases the argument is even used to
force the WG to develop solutions that are backwards compatible with
certain non-standards-compliant behaviour, which is supposedly already
widely deployed.  

It seems that in almost all such cases deployment references are done in
an extremely vague manner. It is very hard to verify anything if the
only information that is given is that "there are deployments". I
understand that some of the details can be confidential and people can't
talk about them. However, I feel that if these claims are always made
without any facts and they actually affect the decisions of the WGs,
there is a risk of abuse.

So, from now on when people talk about deployments or implementations, I
would appreciate a bit more information. For instance if someone claims
that something is deployed, I think that it is reasonable they should be
able to point out at least a *single* real implementation (product
model, stack, ...) which actually supports the feature. Even more
precise information would be even better. This way the WG would be given
at least some facts to back the statements, and it would not be so easy
to just throw them into the discussions. 

Regards,
	Markus

---

From: "Steve Langstaff" <[email-masked]>
Date: Fri, 30 Mar 2007 02:18:14 -0700

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 30 March 2007 09:57
> To: [email-masked]
> Subject: [Sip] "Deployments" (sips: and so on)
> 
> So, from now on when people talk about deployments or 
> implementations, I would appreciate a bit more information. 
> For instance if someone claims that something is deployed, I 
> think that it is reasonable they should be able to point out 
> at least a *single* real implementation (product model, 
> stack, ...) which actually supports the feature. Even more 
> precise information would be even better. This way the WG 
> would be given at least some facts to back the statements, 
> and it would not be so easy to just throw them into the discussions. 

How's this for a (heretical?) idea.

If there was a service run by a body (e.g. the IETF) to test and verify
product compliance to the various standards, then the body running the
tests would be able to gather the facts about which products implement
which features - they might also be able to provide guidance for
implementers or standards writers to straighten out kinks in the
implementations or standards.

I know that would not necessarily mean that the features are deployed in
the wild, but it might allow people to make statements like:
	"No 'IETF Certified' products implement feature X, so it's
unlikely that feature X is deployed amongst discerning customers".

Anyway, I've got to get back to coding this implementation. Bye.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 30 Mar 2007 09:28:39 -0500

Steve Langstaff wrote:
> If there was a service run by a body (e.g. the IETF) to test and
> verify product compliance to the various standards, then the body
> running the tests would be able to gather the facts about which
> products implement which features - they might also be able to
> provide guidance for implementers or standards writers to straighten
> out kinks in the implementations or standards.

For SIP, we have had SIP interoperability tests (used to be called
"bakeoffs" until Betty Crocker threatned to sue) for a while
now.  These do exactly what you note above, and RjS does an
excellent job of collating interoperability problems witnessed
and logging bugs against the specification to ensure that the
next revision of the specification addresses these problems.

The SIPiTs are held twice a year, co-ordinated by the SIP Forum.
The next SIPiT is in April, and the deadline for registration
expires today, I believe (see https://www.sipit.net/Main_Page).

> I know that would not necessarily mean that the features are deployed
> in the wild, but it might allow people to make statements like: "No
> 'IETF Certified' products implement feature X, so it's unlikely that
> feature X is deployed amongst discerning customers".

Certification is an interesting goal.  I note that IEEE has been
very successful in "certifying" its protocols and technologies.
Think of all the times you go to your favorite geek tech shop
and see devices branded as "IEEE 802.11 a/b/g", or
"IEEE 1394 (FireWire)" staring you in the face.

For some reason we at the IETF have not been as successful in
branding something as "IETF RFC3261" compliant.  One school of
thought is that as you move up from link layer technologies
to application layer protocols, certification becomes an
elusive, though not completely unacheivable, goal.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 30 Mar 2007 09:43:36 -0500

[email-masked] wrote:
> model, stack, ...) which actually supports the feature. 

Some statistics, just for fun.

At the last SIPit (19), "Two-thirds of the proxies claimed to handle
SIPS" (see
http://www1.ietf.org/mail-archive/web/sip/current/msg16869.html).

Support for TLS has been gradually increasing:

SIPiT 19 - 90 distinct implementations
   TLS support 45% (server auth only), 36% (mutual auth)

SIPiT 18 - 73 distinct implementations
   TLS support 41%

SIPiT 17 - *** CANNOT FIND DATA ***

SIPiT 16 - 57 distinct implementations
   TLS support 44%

SIPiT 15 - *** CANNOT FIND DATA ***

SIPiT 14 - 55 distinct implementations
   TLS support 63% (!)
   sips support 11%

Thanks,

- vijay

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 30 Mar 2007 17:44:19 +0200

Hi Markus,

it is really very pleasing to hear this kind of common-sense concerns.
The pseudo-arguments "deployments" and "customers say to us" etc appear
to have really great confusion (and nerving) power and do not necessarily 
relate to the "running-code" legacy.

I think actually a great step forward is the sipit statistics which
are a very good measure of where we are with running code. This is
IMO solid input material to the debates (as opposed to various 
customer-say-to-us and once-upon-a-time-there-was-a-big-deployment
hearsays).

The question is if it makes sense to collect more extensive field
feedback. (I occur to think so to have better material for resolving
some of the debates like about backward-compatiblity.)

If so, one way would be extending the sipits stats. Particularly knwoeldge of
the necessity for backwards compatiblity would appear helpful to me
(e.g., strict versus loose routing, and changable versus unchangable 
URIs in in-dialog requests). Do other folks consider this useful too?

Another possible way would be kind of wiki approach with implementors putting 
their feedback in it (even though subject to concerns about reliability of the 
data). This would allow to get information even from folks who don't particpate
in sipits, for example because they license SIP stacks, and still add weight
to a problem by their own products. Are there folks who think this is worth trying?

Thanks again!

-jiri

p.s. I think it would be most useful to link the sipit stats most directly
from SIP WG's supplemental webpage. (and when updating it, also fixing
the [Bugs] link) Would the esteemed webpage maintained like to do so?

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 30 Mar 2007 10:52:38 -0500

Ok, here is what I propose.

We keep the information about double record-routing in the document, and
explain that could be used by legacy proxies that have not deprecated
upgrades and downgrades.

But explain that these procedures are not used when using proxies
compliant
with this spec (which do not use upgrades and downgrades).

> Sent: Thursday, March 29, 2007 20:53
> Subject: Re: Poll: Do we have sips/sip retageting in the wild 
> But they're deployed. And if we advance a solution that makes 
> real deployments worse without providing an error detection 
> and correction mechanism, I'm not sure I'd feel good about 
> it. OTOH, if we can't find any real deployments actually 
> doing this any more, I'll feel less bad..
> 
> > is that a B2BUA or SBC will still be able to "patch" 
> everything to do 
> > upgrades or downgrades in the way you describe.
> 
> True. And that's my other point -- given the way that sips 
> works, you really can't assume that things really were 
> properly secured just because the r-uri and To: had "sips:" in them.
> 
> > rather we make it clean for SIP (and if people do B2BUA 
> stuff, that's 
> > their right).
>

---

From: "Samir Srivastava" <[email-masked]>
Date: Fri, 30 Mar 2007 13:19:53 -0500

The data given only reflects the IMPLEMENTATION adoption rate. It
doesn't mean in any way the DEPLOYMENT.

This shows that vendors who are implementing, they have not even thought
of the complete picture. This is what is the risk you are at. If you
want to take a lead, then you should have done the proper analysis also
as you are the few early ones implementing the specs.

Can't we call these claimed SIPS deployments as CHEAT deployments too ?
As users don't even know what kind of security is provided. Is it 40 bit
cipher, or AES 256 ?
What this TLS mean ? What is stopping them not to use any weaker cipher
itself. 
I have already asked about the broken features in earlier emails.

I agree with Markus, unless we see some more details about the
deployment, then it is no point considering them for the group. They
don't do retargeting, then what else they don't do. It's real wastage of
cycles to consider these deployments for the group. 

I will state "stop fooling around SIPS". Though it is strong language,
but I am getting sick of going around and around in cycles. It has been
shown on the poll over the list that people wanted "DEPREACTE SIPS"
before the San Diego.  

First group made a hurried decision to adopt this draft as the working
group item. Then some tried to save the face for it to make it
BCP/INFORMATIONAL doc that it will be documenting what SIPS means.
Though I was not in the agreement even for the BCP, as there are
numerous other exmaples of broken specs for which we didn't write the
BCP. Now in Prague (Where I was not there) it is being pushed to move it
to the STANDARDS track document. What is this ? For all that, I hope I
don't need to pull the email links from the archive.

Thx
Samir

---

From: Dean Willis <[email-masked]>
Date: Fri, 30 Mar 2007 16:34:41 -0500

> with this spec (which do not use upgrades and downgrades).

Works for me.

--
Dean