Subject: [p2p-sip] Security update for charter

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 15 Jan 2007 19:16:35 -0800

While this IETF LC of the charter is happening, I would like to  
sort out a few updates to the charter.

Sam Hartman pointed out that we have no mention of security in the  
charter. We need to fix this and put in some text that outlines what  
security assumptions we have and what "bar" we will hold this work  
to. Added EKR as he is the usual security advisor for the RAI WGs and  
certainly up to speed on P2PSIP.

Cullen

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Mon, 15 Jan 2007 23:23:15 -0500

Some thoughts on security:

P2PSIP assumes that attackers have the ability to intercept and alter
messages.  An attacker may be able to compromise one or more
individual peers.  A P2PSIP overlay must preserve routing integrity in
the event of a single compromised peer, or a small percentage of
random peers being compromised.  If a peer  is compromised, the
routing protocol must not offer an attacker amplification attacks nor
should an attacker be able to insert arbitrary amounts of resource
registrations into the overlay to overload the other peers.  A P2PSIP
protocol may offer varying levels of security to be chosen depending
on the type, scale, and vulnerability of a particular deployment.
Currently available methods of certificate-chain based security and
shared secret security will be chosen for integrity, authentication,
and secrecy rather than trying to solve more general distributed
security problems.  Limited amounts of centralization at enrollment
time are likely to be required.

Bruce

On 1/15/07, Cullen Jennings <fluffy at cisco.com> wrote:
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>
>

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Mon, 15 Jan 2007 22:56:30 -0600

I'm not quite sure how to say this, so I'll just say it...

The now-expired individual draft on Use Cases described a huge range of 
deployment scenarios, from global P2PSIP service providers to two devices I 
own using P2PSIP between those two devices.

It seems to me that if the charter is very explicit about security 
assumptions, it's also very going to be explicit about deployment scenario 
assumptions, and it seemed to me that we should not be forcing decisions 
about these assumptions before a working group forms.

Discussing the "bar" DOES seem appropriate in the charter. Could we focus on 
that, saying (much like we say on anonymity) that we must not do things that 
prevent authentication, confidentiality, etc?

I note that even the question of whether request bodies are 
cryptotransparent to peers that handle requests is still an open issue in 
the Concepts draft (section 4.5), so I hope I'm not the only one who thinks 
the working group has some work to do, before security is fully nailed down.

Thanks,

Spencer

---

From: zhuxian at huawei.com (zhuxian)
Date: Tue, 16 Jan 2007 15:20:25 +0800

I think we may add some sentences about secure peer ID and resource
namespace.  It's very important in the P2P environment to provide the
mechanism about secure peer ID. And the resource location is the main task
in the P2PSIP.

See inline.

>-----Original Message-----
>From: p2p-sip-bounces at cs.columbia.edu 
>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Bruce Lowekamp
>Sent: Tuesday, January 16, 2007 12:23 PM
>To: Cullen Jennings
>Cc: P2P-SIP
>Subject: Re: [p2p-sip] Security update for charter
>
>P2PSIP assumes that attackers have the ability to intercept 
>and alter messages.  An attacker may be able to compromise one 
>or more individual peers. A P2PSIP overlay must preserve 
>routing integrity in the event of a single compromised peer, 
>or a small percentage of random peers being compromised.  If a 
>peer  is compromised, the routing protocol must not offer an 
>attacker amplification attacks nor should an attacker be able 
>to insert arbitrary amounts of resource registrations into the 
>overlay to overload the other peers.
 
A P2PSIP overlay must also protect the peer identity namespace and the
resource namespace.

> A P2PSIP protocol may 
>offer varying levels of security to be chosen depending on the 
>type, scale, and vulnerability of a particular deployment.
>Currently available methods of certificate-chain based 
>security and shared secret security will be chosen for 
>integrity, authentication, and secrecy rather than trying to 
>solve more general distributed security problems.  Limited 
>amounts of centralization at enrollment time are likely to be required.
>
>Bruce
>
>
>
>
>>   While this IETF LC of the charter is happening, I would 
>like to sort 
>> out a few updates to the charter.
>>
>> security assumptions we have and what "bar" we will hold 
>this work to. 
>> Added EKR as he is the usual security advisor for the RAI WGs and

---

From: vkg at alcatel-lucent.com (Vijay K. Gurbani)
Date: Tue, 16 Jan 2007 14:03:03 -0600

Spencer Dawkins wrote:
> cryptotransparent to peers that handle requests is still an open
> issue in the Concepts draft (section 4.5)

We have done some work on this.  We have implemented the idea of
the sipsec URI to do end-to-end authentication and cryptotransparency
across SIP proxies, especially in cases (NATs) where you need the
proxies but do not trust them.

The results indicate that:

   (a) it can be done (but we already knew that);
   (b) signaling latency is reduced by 1/2 when cryptotransparent
       proxies are used;
   (c) introducing a traditional TLS SIP proxy increases the
       latency by about 1/2 as much as it was before; introducing
       a cryptotransparent proxy has a much smaller impact
       on latency (10%).
   (d) System load as measured by CPU occupancy is negligible to
       the cryptotransparent proxies (CPU below 1% occupancy for
       the duration of processing 100 calls per second).

We will be presenting these results as part of an upcoming paper.

Thanks.

- 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