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

From: Eric Rescorla <[email-masked]>
Date: Wed, 01 Jul 2009 20:56:08 -0700

At Wed, 01 Jul 2009 12:16:12 +0800,
Song Haibin wrote:
> >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.

Sure. I'm not saying that one couldn't do an ACL extension to RELOAD
at some point in the future to support some future usages. My point
is that we don't need it for the current set of applications.

> Could you tell me what causes the WebDAV ACLs
> overcomplicated?

That people want to be able to specify complicated policies,
so once you open the door to ACLs it gets complicated.
And of course the situation here is inherently more complicated
since you're asking people you basically don't trust to enforce
access control for you.

> >> 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?
> >
> 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.

Me neither. And since overlays are resistant to a certain amount 
of misbehavior, I don't know if we need to solve this right now.

-Ekr

---

From: Song Haibin <[email-masked]>
Date: Thu, 02 Jul 2009 17:23:45 +0800

>> >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.
>
>Sure. I'm not saying that one couldn't do an ACL extension to 
>RELOAD at some point in the future to support some future 
>usages. My point is that we don't need it for the current set 
>of applications.
>
>
>> Could you tell me what causes the WebDAV ACLs overcomplicated?
>
>And of course the situation here is inherently more 
>complicated since you're asking people you basically don't 
>trust to enforce access control for you.
>

Thanks for explaining. I agree. I guess a shared group key may be a better
choice, at least in p2p scenarios, it does not depend on a third party that
you don't trust to enforce the access control.

>
>> >> 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
>> >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.
>
>Me neither. And since overlays are resistant to a certain 
>amount of misbehavior, I don't know if we need to solve this right now.
>

I prefer to mention the consideration to this problem in the security
considerations of the base draft.

Haibin

---

From: "Schmidt, Christian 1. (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 2 Jul 2009 15:32:40 +0200

Hi Eric,

Can you please explain your following statement a bit more:
 
"Me neither. And since overlays are resistant to a certain amount 
of misbehavior, I don't know if we need to solve this right now."Eric
Rescorla:

What does this mean? 
Dependent from the percentage of misbehaving peers, a certain percentage
of calls will fail?
Is this really acceptable?
If a call attempt fails, wouldn't this happen to a repeated call attempt
as well?

Regards
Christian Schmidt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of ext Eric Rescorla
Sent: Thursday, July 02, 2009 5:56 AM
To: Song Haibin
Cc: 'P2PSIP WG'
Subject: Re: [P2PSIP] P2PSIP Security Requirements Taken Out
Fromdraft-matuszewski-p2psip-security-requirements-04

> >> Req. 12: It SHOULD be possible to limit the impact of badly
behaving 
> I'm not sure about the solution here. I think it may be hard to
determine

-Ekr
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2psip

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 02 Jul 2009 06:39:11 -0700

At Thu, 2 Jul 2009 15:32:40 +0200,
> If a call attempt fails, wouldn't this happen to a repeated call attempt

Quite possibly, but it's pretty much inherent in the fact
that this is operated over a best-effort network and is 
itself a best-effort network.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 08 Jul 2009 09:42:34 -0700

At Thu, 02 Jul 2009 17:23:45 +0800,
> considerations of the base draft.

I don't have a problem with mentioning this issue.

-Ekr