Subject: Re: [MSEC] Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt

From: "David A. McGrew" <[email-masked]>
Date: Tue, 03 Jul 2001 09:11:14 -0400

Andrea,

Andrea Colegrove wrote:
> 4.  In general all the requirements for a group key management protocol refer
> to a group security management protocol.  For example:  Changes in algorithms,
> access, etc are changes to POLICY.  Policy is _so_ much more than "meta-data
> describing the keys."

what data do you think should be included in the definition of policy?  From
GSAKMP Section 4.4:

The Policy Token Payload contains group specific information that describes
the group security relevant behaviors, access control parameters, and
security mechanisms. 

Is there a more concrete definition of these policy elements in the GSAKMP
document, or could you please describe what policy elements that you have in
mind?

thanks,

[email-masked]

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

---

From: Andrea Colegrove <[email-masked]>
Date: Tue, 03 Jul 2001 15:52:57 -0400

David,
    Group policy is the collection of security rules that the group will adhere to.
It can include, as stated in the GSAKMP doc, security association parameters, access
control rules, and even host-based properties such as certification.  It is what a
new member uses to determine if it wants to join (potentially share data with) a
group and it is what a GCKS uses to determine if a new member should be given access
to the group.
    Because the policy for groups will vary, the actual policy elements in a
specific policy will vary as well.  Thus, static policy statements for all groups
would probably be inadequate.  I am afraid I cannot give a more concrete definition
than that.
    The policy building block touches upon these issues, but last I checked the link
from the msec page was broken anyway.  We also discuss trust reasoning based upon
policy in "Principles of Policy in Secure Groups" presented at NDSS '01.  The url is
http://www.eecs.umich.edu/~pdmcdan/docs/ndss01.pdf.
    I hope this answers your question somewhat.

Thanks,

Andrea

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 03 Jul 2001 15:39:52 -0400

Dave,

The Group Security Policy Token (GSPT) draft should hopefully be out
before the London IETF.

cheers,

thomas
------

---

From: Thomas Hardjono <[email-masked]>
Date: Tue, 03 Jul 2001 18:27:22 -0400

Andrea, David,

I think one of the main issues with Group Policy within MSEC
is to define (if possible) the suitable "amount" of policy
information that is conveyed within the Group Security Policy Token (GSPT).

The problem also is which parts of the GSPT is made public so that
newcomers can find-out about the group and the requirements to join.

Now, we don't want to end-up saying we need "policy" to say
which parts of the GSPT are public and which parts are conveyed
after the newcomer has user-authenticated themselves to the KDC
(or one of the KDCs).  That is, we don't want policies to
govern "meta-policies", and so on.

Also, one of the things that needs to be identified within the
SEC architecture
is:
   (a) which parts of the GSPT is made public, common across all
       key management protocol instantiations (ie. GSAKMP, GDOI).

   (b) which parts are downloaded within Cat-1/Registration (if any).
       eg. GSAKMP pushes it down in the 5th flow (as I recall).

So, I see a tight inter-relationship/feedback-loop between the
Key Management Architecture draft and the GSPT draft.

If the Key Management Architecture draft is decidedly not the place
to do this, then we might have to push it up to the umbrella
MSEC Architecture document.

thomas
------