Subject: [P2PSIP] draft-knauf-p2psip-share-00

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 13 May 2011 16:41:22 -0700

I am trying to find out how to implement the USER-CHAIN-ACL access control
policy defined in this I-D as a script, and there is something I do not understand.

First of all, I assume that this draft is using the features defined in base-13
and that no modifications in the -base document is needed to develop this policy.

My problem is with the 4th paragraph of section 3:

"Access Control Policy:  To ensure write access to Shared Resource by
   Authorized Peers, each Usage MUST permit the USER-CHAIN-ACL access
   policy (see Section 5.4) in addition to its regular access
   policies (USER-MATCH, USER-NODE-MATCH, etc.)."

I do not see in -base how two (or more) Access Control Policies can be used for
one Kind.  We have the same thing in draft-knauf-p2psip-disco:

"Access Control Policy:  Authorized focus peers are allowed to write
   the DisCo-Registration using the USER-CHAIN-ACL access policy.
   The conference creator (and resource owner) is the only exception:
   he is allowed to write based on the USER-MATCH or USER-PATTERN-
   MATCH policy."

How a kind (DisCo-Registration in this case) can use two different access
control policy?

(Note that the configuration schema clearly states that a kind element contains
one data-model element and one access-control element).

Thanks.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Alexander Knauf <[email-masked]>
Date: Mon, 16 May 2011 11:41:18 +0200

Hi Marc,

thanks for your feedback!

On 14.05.2011 01:41, Marc Petit-Huguenin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> one Kind.
I also see this conflict in the XML overlay config. document that only 
allows a single access control policy per Kind. If it would support 
multiple access policies, something like this:

kind-parameter&= element access-control { access-control-type }*<-- note the asterisk, compare with base -13  p.122

the receiver of a store request could iterate over the those policies, 
trying if any of them is true.

> We have the same thing in draft-knauf-p2psip-disco:
>
same as above
> one data-model element and one access-control element).
If the base document keeps this rule, we have to think about an 
alternative in ShaRe/DisCo..

regards,

Alexander
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
>
> iEYEARECAAYFAk3NwaAACgkQ9RoMZyVa61dlZwCeNlDcg0W7NiYYF7AuiXCmvWkS
> 6V4AniHrLWAEQjTYb3M3JqQ8jvO5BOD3
> =U1x+
> -----END PGP SIGNATURE-----
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/p2psip

-- 
/*************************************************
* Alexander Knauf B.Sc.
* AG INET
* Dept. Informatik
* HAW Hamburg
* Berliner Tor 7
* D-20099 Hamburg, Germany
* Room: 580
* Net: http://inet.cpt.haw-hamburg.de/members/knauf
* Phone: +49 40 42875 - 8067
* Fax: +49 40 42875 - 8409
*************************************************/

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 16 May 2011 16:15:29 -0700

Hi Alexander,

On 05/16/2011 02:41 AM, Alexander Knauf wrote:
>> I also see this conflict in the XML overlay config. document that only allows a
>> single access control policy per Kind. If it would support multiple access
>> policies, something like this:
> 
>> kind-parameter &= element access-control { access-control-type }* <-- note the asterisk, compare with base -13  p.122
> 
> 
>> the receiver of a store request could iterate over the those policies, trying if
>> any of them is true.

Well, in this case I suggest that you talk to the -base authors to add this
behavior in the spec (Note that I am not saying that this is a good idea).

I will send a more detailed review (and will update my access control I-D with
the modifications needed to implement this) when this is decided.

As for the USER-PATTERN-MATCH policy, one problem I see is that the spec does
not define strongly enough the resource_name field.  The problem here is that
when storing a value, a peer does not have access to the definition on this
value - and cannot as each kind will have a different definition.  This is why
you need to say in the spec something like '... MUST define an "opaque
<0..2^16-1>" field as the first field within the Kind data structure,...". With
this field always defined as being the first in a Kind using USER-PATTERN-MATCH,
the policy code will have no problem finding it.

Also I think that the variable-resource-names element should be inside the kind
element, and that you should also define its namespace.

Thanks.

- -- 
Marc Petit-Huguenin

---

From: Alexander Knauf <[email-masked]>
Date: Fri, 20 May 2011 16:15:37 +0200

Hi again,

> behavior in the spec (Note that I am not saying that this is a good idea).
Well, we were discussing alternatives to this and have the idea of some 
kind of "all-in-one" access control policy. Lets say the USER-CHAIN-ACL 
could be defined like:

"a given value must be written if the request is signed with a private 
key whose hash..and-so-on"
OR
"must be written if <some text for the other policy> "

We only specify one access policy per Kind that allows two variants for 
storage access.

> element, and that you should also define its namespace.
Thanks for this comment and I agree. We will keep this in mind for next 
draft version.

best regards,

Alexander

* Net:http://inet.cpt.haw-hamburg.de/members/knauf

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Fri, 20 May 2011 07:44:20 -0700

On 05/20/2011 07:15 AM, Alexander Knauf wrote:
> Well, we were discussing alternatives to this and have the idea of some kind of
> "all-in-one" access control policy. Lets say the USER-CHAIN-ACL could be defined
> like:
> 
> "a given value must be written if the request is signed with a private key whose
> hash..and-so-on"
> OR
> We only specify one access policy per Kind that allows two variants for storage
> access.

OK, I think that with that I can write the scripts for the access policies, and
be sure that the next version of my draft contains everything to implement them.

I'll publish it (and the updated code for the tester) just after you publish
your updated draft.

Thanks.

- -- 
Marc Petit-Huguenin