Subject: [P2PSIP] P2PSIP Security Requirements Taken Out From draft-matuszewski-p2psip-security-requirements-04

From: Song Haibin <[email-masked]>
Date: Wed, 01 Jul 2009 10:10:33 +0800

Dear all,

According to the comments from IETF 73 meeting in Minneapolis, the security
requirements in the merged draft-matuszewski-p2psip-security-requirements-04
should be transferred to the base draft, and the remaining part will become
an informational i-d on p2psip security analysis and tutorial.

The authors of draft-matuszewski-p2psip-security-requirements have taken the
security requirements out, and list it in the attached document. We had a
few email exchange with the authors of the base draft several weeks ago, but
not covered all the requirements. More discussion is welcome.  

Best Regards,
Haibin
Skype: alexsonghw

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2009 19:22:19 -0700

At Wed, 01 Jul 2009 10:10:33 +0800,
Song Haibin wrote:
> 
> [1  <text/plain; us-ascii (7bit)>]
> Dear all,
> 

My memory of the discussion is a little different. Namely, that 
any security requirements that weren't already reflected in
the RELOAD design would be discussed for appropriateness and
merged into RELOAD if appropriate.

Which of the requirements in this document do you believe fit
that description?

-Ekr

---

From: Song Haibin <[email-masked]>
Date: Wed, 01 Jul 2009 11:01:34 +0800

Hi Ekr,

>-----Original Message-----
>From: Eric Rescorla [mailto:[email-masked]] 
>Sent: Wednesday, July 01, 2009 10:22 AM
>To: Song Haibin
>Cc: 'P2PSIP WG'
>Subject: Re: [P2PSIP] P2PSIP Security Requirements Taken Out 
>From draft-matuszewski-p2psip-security-requirements-04
>
>> According to the comments from IETF 73 meeting in Minneapolis, the 
>> security requirements in the merged 
>> draft-matuszewski-p2psip-security-requirements-04
>> should be transferred to the base draft, and the remaining part will 
>> become an informational i-d on p2psip security analysis and tutorial.
>
>My memory of the discussion is a little different. Namely, 
>that any security requirements that weren't already reflected 
>in the RELOAD design would be discussed for appropriateness 
>and merged into RELOAD if appropriate.
>
Okay.

>Which of the requirements in this document do you believe fit 

What about system security requirement 6, 11 and 12?

-Haibin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 30 Jun 2009 20:15:56 -0700

At Wed, 01 Jul 2009 11:01:34 +0800,

For those of you who can't read Word, these are:

> Req. 6: The system must be able to identify repeat and delay attacks

Well, these are both normal functions of a best-effort network,
so I'm not sure how one would determine whether a node was
misbehaving.

> Req. 11: An owner of P2PSIP resource (user) record MAY indicate
> which users or network entities can retrieve, modify, and delete
> data stored in their P2PSIP resource (user) records.

I actually think this is a bad idea. Previous experiences
with trying to design access control systems (see WebDAV ACLs)
have turned out to be really overcomplicated. As far as I
can tell, this isn't necessary for the SIP use cases.

> Req. 12: It SHOULD be possible to limit the impact of badly behaving
> P2PSIP nodes on the overall system security.  There SHOULD be an
> option to identify malfunctioning or badly behaving nodes, and exclude
> or reject them from the P2PSIP system.

Hmm... It seems to me that this is already possible at least in
some sense: you use short-lived certificates and then refuse to
reissue their certificates. Did you have something else in
mind? CRLs?

-Ekr

---

From: Song Haibin <[email-masked]>
Date: Wed, 01 Jul 2009 12:16:12 +0800

Hi Ekr,

Thanks!
Haibin

>Sent: Wednesday, July 01, 2009 11:16 AM
>To: Song Haibin
>Cc: 'Eric Rescorla'; 'P2PSIP WG'
>> >Which of the requirements in this document do you believe fit that 
>> >description?
>> 
>Well, these are both normal functions of a best-effort 
>network, so I'm not sure how one would determine whether a 
>node was misbehaving.
>
>
>> Req. 11: An owner of P2PSIP resource (user) record MAY 
>indicate which 
>> users or network entities can retrieve, modify, and delete 
>data stored 
>I actually think this is a bad idea. Previous experiences with 
>trying to design access control systems (see WebDAV ACLs) have 
>turned out to be really overcomplicated. As far as I can tell, 
>this isn't necessary for the SIP use cases.
>

As RELOAD is designed to support various usages. Other usages may have this
requirement. For example, we can image group communication scenarios, only
members of a group can retrieve and modify the files belonging to this
group. I think ACL might work. Could you tell me what causes the WebDAV ACLs
overcomplicated?

>Hmm... It seems to me that this is already possible at least 
>in some sense: you use short-lived certificates and then 
>refuse to reissue their certificates. Did you have something 
>else in mind? CRLs?
>
I'm not sure about the solution here. I think it may be hard to determine
the TTL for such kind shor-lived certificates. Misbehaving nodes still
function in the overlay until its certificate expires. Too short TTL may
overload the CA anyway. I don't know how CRLs work in the overlay, in a p2p
fashion or in a c/s fashion.

-Haibin