Subject: [Sip] draft-audet-sip-sips-guidelines: Meaning of sips

From: "Francois Audet" <[email-masked]>
Date: Wed, 17 May 2006 15:53:18 -0500

I will break out the various topics regarding this draft into threads, 
in order to facilite resolution.

This thread is on the meaning of sips.

Johnathan proposed the following:

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

2. there is no upgrading or downgrading, period

Personally, I agree with point 1. As pointed out by others, it doesn't 
necessarily mean it's more or less secure than IPsec (or whatever): it
would
just mean that TLS is to be used hop-by-hop, end-to-end. Period.

The problem with the current weasel-words about IPsec in RFC3261 is that

it makes it almost impossible to anybody to figure out what it means. At
least "sips == tls required on all hops" is something very concrete.

Before we agree to this, it might be good to hear the point of view of
some
3GPP folks.

As for point 2, as pointed out by Paul, this is more complicated.
Upgrading/
Downgrading means different things depending if we are talking R-URI or
Contact or AOR.

Personally, I would agree that upgrading/dowgrading in a R-URI should be
banned. (I think this is what Johnathan meant).

Futher points made by Johnathan regarding Registration in fact were
pointing
to quasi mandating upgrading/downgrating when talking about contacts and
AOR. 
I want to defer that particular discussion to another thread that I'll
start 
soon.

So.....

Can we agree on the following:

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

2. there is no upgrading or downgrading of R-URIs, period

PS: If we don't get a mailing group consensus, I'll just mark it as Open
Issue
on the next version of the draft.

_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 17 May 2006 17:35:31 -0400

> banned. (I think this is what Johnathan meant).

I think this still needs more clarification of what it means.

How about the following:

If the R-URI of a message contains a SIPS URI, then it MAY be replaced 
with some other SIPS URI (when allowed by the rules of 3261) but MUST 
NOT be replaced with a URI having any other scheme, even if otherwise 
allowed by 3261.

> 1. SIPS in a R-URI requires the usage of TLS at every hop - none of this

I'm not ready to agree with this. I am expecially persuaded by Dave O 
and others that knowing SIPS is in use end to end doesn't actually 
guarantee anything about the security properties of the session, even if 
you do trust all the intervening hops.

Clarifying the meaning of SIPS does no good if the result is that the 
meaning is "nothing".

I guess if we know every hop uses SIPS, it means that we transitively 
know that the callee has been verified to be who he claims to be, 
whoever that is. Is that enough?

I thought that security of the session is an essential property of SIPS 
- that if I use SIPS I can then safely do something like exchange media 
keys using sdescriptions. If that is a goal, then we need to find a way 
for use of SIPS to provide that guarantee. That may or may not require 
use of TLS at every hop.

> 2. there is no upgrading or downgrading of R-URIs, period

I'm ok with the interpretation of this I gave above.

	Paul

---

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

On May 17, 2006, at 4:35 PM, Paul Kyzivat wrote:

>
> I guess if we know every hop uses SIPS, it means that we  
> transitively know that the callee has been verified to be who he  
> claims to be, whoever that is. Is that enough?
>

Nope. can't make that assertion. A UAC can establish single-ended TLS  
to a server that might not bother to do secondary authentication, but  
still be completely requirement with "TLS was used at every hop".

> I thought that security of the session is an essential property of  
> SIPS - that if I use SIPS I can then safely do something like  
> exchange media keys using sdescriptions. If that is a goal, then we  
> need to find a way for use of SIPS to provide that guarantee. That  
> may or may not require use of TLS at every hop.

If the sdescriptions are revealed to every intervening proxy, I don't  
think you have much in the way of security. A proxy can be  
identifiable (via TLS assertion) without being trustworthy.

--
Dean

---

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

> identifiable (via TLS assertion) without being trustworthy.

Right. I've had my suspicions about SIPS for a long while, and if Paul's 
interpretation
is common, then I'd say that SIPS is actually harmful.

          Mike, even though as a Please Do This mechanism it has utility.

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 18 May 2006 09:22:30 +0300

Michael Thomas writes:

 > interpretation is common, then I'd say that SIPS is actually
 > harmful.

SIPS was added to rfc3261 at the very last minute without any
implementation or even interpretation experience.  because it doesn't
give any end-to-end guarantees, i agree that it is useless.
transport=tls, on the other hand, is useful and should be kept.

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Thu, 18 May 2006 09:22:30 +0300

-- juha