Subject: [MSEC] GSAKMP access control

From: "Prashant Pillai" <[email-masked]>
Date: Tue, 13 Jun 2006 20:16:01 +0100

Hi All,

I have some questions related to the access control mechanisms in GSAKMP:

1.      What are the access control rules present in the Policy Token? What
kind of access control policy does this define?

2.      Does the access control rules/policy contain the list of allowed
users? What if there are users who were not initially registered to the
multicast group but want to join later?

3.      How does the GC/KS get the user (GM) credentials to perform the
access control?

Regards

Prashant
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: George Gross <[email-masked]>
Date: Wed, 14 Jun 2006 05:39:22 -0400 (EDT)

Hi Prashant,

inline below...

> kind of access control policy does this define?

I would start by taking a look at section B.1.2 within the "Group Security
Policy Token v1"  specification, the ID file is:

draft-ietf-msec-policy-token-sec-06.txt

The "AccessControl" construct contains a sequence of include/exclusion
rules. The GCKS matchs these rules against the candidate Group Member's
identity to decide whether to grant a request to join the group.

Other rules in the Policy Token authorize the GCKS and S-GCKS roles.

> multicast group but want to join later?

The Group Owner decides the group membership policy, then creates a signed
Policy Token and hands it off to the GCKS, who then downloads it to new
group members as they arrive. When the Group Owner revises that policy,
then a fresh Policy Token gets created and distributed. In GSAKMP, the
Re-Key Event message multicasts this change in policy to the group
membership. Therefore, the membership policy is dynamic.

Of course, any of the group members who are authorized by the active
Policy Token's AccessControl rules can join the group.

> 3.      How does the GC/KS get the user (GM) credentials to perform the

The certificate path validation uses either in-band and/or out-of-band
methods:

1) Inband: The user appends Certificate payload(s) to their RTJ message.
See GSAKMP spec section 7.7.

2) Out of band: The GCKS may have a local certificate cache, or do an LDAP
or OCSP query, or some other cert path retrieval/validation method.

The Policy Token "UserCAPair" construct specifies the trusted root
KeyIdentifier for each user identity.

hth,
	George

---

From: "Prashant Pillai" <[email-masked]>
Date: Mon, 19 Jun 2006 10:42:33 +0100

Hi George,

Thanx for your reply.

Some more doubts. see inline

> Other rules in the Policy Token authorize the GCKS and S-GCKS roles.

I have read this section. But what does the permissions rules signify? Also
regarding the accessrule, which is a sequence of UserCApairs, what is this
GSAKMPID (which denotes the groupentity)? Who assigns this? CA is the
certifying authority..right?

> Policy Token and hands it off to the GCKS,

This (the GO passing the policy to the GCKS) is not done using GSAKMP
message..right?

who then downloads it to new
> membership. Therefore, the membership policy is dynamic.

The rey-key is even os only from GC/KS to GM and not from GO(as in the
previous question)?

Regards

Prashant Pillai

---

From: George Gross <[email-masked]>
Date: Mon, 19 Jun 2006 08:50:44 -0400 (EDT)

Hi Prashant,

inline below....

On Mon, 19 Jun 2006, Prashant Pillai wrote:

<snip for brevity>

> I have read this section. But what does the permissions rules signify?

The interpretation of the permission rules is application-specific, and
would be specified in a profile on the GSAKMP framework. Some applications
may disregard the permissions entirely, others might evaluate a RTJ Notify
Payload's request for a particular type of group data access versus the
permissions.

> Also
> GSAKMPID (which denotes the groupentity)?

The GSAKMPID refers to the identity asserted in the Signature Payload, as
described in the GSAKMP specification section 7.8. A GSAKMPID is a 2-tuple
of the form {identification type, identification value}. Take a look at
the GSAKMP spec's Table 19 for the list of the identification types.

> Who assigns this?

Not sure what you meant by "this". The Group Owner decides on the set of
UserCApairs to put into the Policy Token. The GSAKMPID identification
value usually matchs either the Subject field or one of the
SubjectAlternativeNames fields within a GM's end-entity public key
certificate.

> CA is the

Yes.

> This (the GO passing the policy to the GCKS) is not done using GSAKMP

Correct, the transfer of the PT from GO to GCKS is through an
implementation-specific trusted interface outside the scope of the
standard.

> The rey-key is even os only from GC/KS to GM and not from GO(as in the

The GCKS has responsibility for generating the group's key and then
distributing it via the Re-Key Event multicast message. If the GCKS has a
revised Policy Token from the GO, then it will include that Policy Token
in the Re-Key Event message as a Policy Token payload.

br,

	George

<snip the rest>