Subject: [p2p-sip] What consensus? (was: What controls the lock icon? (Was RE:[Sip] RE: TLS meaning))

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 1 Nov 2006 05:52:26 -0800

Avshalom Houri writes:

>Other then a secure channel or S/MIME I do not think that it will be 

>possible to send a SIP message and get real assurance that the message 
>will be sent securely in every hop.

As you correctly conclude, P2P SIP has the opportunity to finally make
SIP secure.

Thanks, Henry

________________________________

From: Avshalom Houri [mailto:AVSHALOM at il.ibm.com] 
Sent: Wednesday, November 01, 2006 5:55 AM
To: sip at ietf.org
Subject: Re: What consensus? (was: What controls the lock icon? (Was
RE:[Sip] RE: TLS meaning))

Seems that we need a mechanism to create a trusted "channel" between 
endpoints that goes through all the intermediaries. The channel should 
verifiable as secure between the endpoints. After the channel is created

then the SIP signalling can go securely over the channel. 

The protocol for creating such a channel may be SIP based on 
external to SIP and after we have such a mechanism we can decide if we 
will use SIPS for messages that need to go over the secure channel 
or we will use new URI type (e.g. SSIP) or just use some 
header in the SIP message. 

The other alternative is the usage of S/MIME which has its drawbacks as 
we can see in another thread. 

Other then a secure channel or S/MIME I do not think that it will be 
possible to send a SIP message and get real assurance that the message 
will be sent securely in every hop. 

--Avshalom 

Dean Willis <dean.willis at softarmor.com> 

31/10/2006 18:51 

To

Michael Thomas <mat at cisco.com> 

cc

"Joel M. Halpern" <joel at stevecrocker.com>, "'IETF SIP List'"
<sip at ietf.org>, Juha Heinanen <jh at tutpro.com>, "Elwell, John"
<john.elwell at siemens.com> 

Subject

Re: What consensus? (was: What controls the lock icon? (Was RE: [Sip]
RE: TLS meaning))

On Oct 31, 2006, at 8:47 AM, Michael Thomas wrote:

> My advise to the working group is to just start over from first  
> principles as if
> SIPS didn't even exist -- which in reality it doesn't. We need to  
> be thinking
> about these things for the long term, and if it's not baked it's  
> not baked. There
> have been many drafts that have lingered on and completely  
> overhauled over
> the years. Why SIPS is treated so differently in that respect is  
> somewhat
> mystifying because dealing with security for SIP is a genuinely  
> hard problem.
> It shouldn't be rushed, and it deserves better than a kludgey  
> security patina
> airbrushed in to get past the IESG.

I'm very tempted to endorse this, but I think you're missing one thing.

Flimsy as it is, I believe that sips: is as strong as the rest of the  
current SIP security model since it depends on the same trust  
assumptions.

We can't just restart on sips: without restarting from those  
fundamental trust assumptions.

This is not trivial. Many people would argue that it would turn SIP  
into a fundamentally different protocol. I think it needs to be done,  
but I also think we need to clearly document how the current trust  
model (including sips:) works, because that's what's going to be  
deployed in the real world for a relatively long time.

The P2PSIP work is having to re-examine those fundamental trust  
assumptions. My current hope is we can do some work there that can be  
"ported back" into SIP.

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061101/46595181/attachment-0001.html

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Wed, 1 Nov 2006 06:40:07 -0800

The disentrance for a secure channel is sweet. It seems to me the first of
the keypoints that will make P2PSIP win. SIP itself seems never one :(

Peter
----- Original Message -----
From: Henry Sinnreich
To: Avshalom Houri ; sip at ietf.org
Cc: p2p-sip at cs.columbia.edu
Sent: Wednesday, November 01, 2006 5:52 AM
Subject: Re: [p2p-sip] What consensus? (was: What controls the lock
icon?(Was RE:[Sip] RE: TLS meaning))

>will be sent securely in every hop.

As you correctly conclude, P2P SIP has the opportunity to finally make SIP
secure.

Thanks, Henry

--Avshalom

Dean Willis <dean.willis at softarmor.com>
31/10/2006 18:51 ToMichael Thomas <mat at cisco.com>
cc"Joel M. Halpern" <joel at stevecrocker.com>, "'IETF SIP List'"
<sip at ietf.org>, Juha Heinanen <jh at tutpro.com>, "Elwell, John"
<john.elwell at siemens.com>
SubjectRe: What consensus? (was: What controls the lock icon? (Was RE: [Sip]
RE: TLS meaning))

--
Dean

_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: edpimentl at gmail.com (Ed Pimentel)
Date: Wed, 1 Nov 2006 09:58:51 -0500

What is missing is the concept of a federated SAML / OpenID / Yadis   
"iD Provider"
Or even an adaptation of what was with H.350 (Internet2.0) but  for  
P2P-SIP
Sincerely,
-EdPimentl

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Wed, 1 Nov 2006 05:52:26 -0800

Thanks, Henry

--Avshalom 

31/10/2006 18:51 

To

cc

Subject

 

--
Dean

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20061101/46595181/attachment-0002.html