Subject: Re: [MSEC] msec architecture draft and email flow

From: Hugh Harney <[email-masked]>
Date: Thu, 05 Jul 2001 09:23:30 -0400

Mark,

Sorry about the delay. I've been writing and reviewing like mad.
>>>>Bullet two is critical for a joining member to trust the key. It should 
>>>>be inside. This is an extension of the explicitness principle. If you 
>>>>are using an attribute certificate (or delegation cert) then this is 
>>>>passed via an LDAP or certificate payload. In either case the KM 
>>>>protocol needs to review that certificate and determine the GCKS is 
>>>>authorized. It is still part of the KM protocol.
>>>
>>>By virtue of the fact that a member is contacting a KDC/GCKS, it seems 
>>>that we have resolved the question of who the KDC/GCKS is.  What am I 
>>>missing?  How would this identification of policy take place within key 
>>>management?
>>
>>Anyone can reply to a join/registration request. We need to know that 
>>whomever replies is authorized to handout key for the group.
>
>Or the member can direct the request to the authorized server based on, 
>say, a secure website or email attachment.  There could be a Session 
>Description Protocol (SDP) announcement that gets sent as securely as it 
>needs to be that causes the member to contact the correct GCKS.  So this 
>request is often out-of-band from the key management protocol for a lot of 
>interesting applications.

There is value in keeping a data structure that explicitly states all 
relevant security policy for a group. As per my contribution to this 
section of the GDOI document, I don't mandate the delivery mechanisms to 
get policy information to ALL policy enforcement agents in the group, but I 
do believe the policy must be enforced.

Essentially, I believe that the group key management entities have to 
enforce all relevant policy. That policy may be posted, sent in the KM 
protocol, or known a priori. I don't necessarily mandate in band 
transmission of policy, but it does make the KM protocol self sufficient. I 
do see value in having an optional payload for policy information.

>>It is critical to the acceptance of the key to know that the GC/KS is 
>>authorized to hand out the key. This is something that has to be enforced 
>>by the joining member. The decision has to be based on some security 
>>policy (singed by the GO) that the member has received. Yes, we can use 
>>attribute/delegation certificates, but the member must enforce the 
>>authorization policy before it can trust the key.
>
>And the KDC/GCKS must enforce the policy before it can trust the member.

My point was that GCKS and group members both have policy enforcement roles.

>>This is different from IKE or pairwise key management protocols. Peer 
>>protocols are talking to the entity they will be using the key with. They 
>>directly exchange signed certificates with the other side. The 
>>verirfication of the certificate implies authorization to create key for 
>>that party. The know who they are talking to. In groups we are accepting 
>>a key download on behalf of an abstract GSA.
>
>"GSA" or "GO?"  I don't understand this abstraction.  In GDOI, the 
>KDC/GCKS exchanges credentials (performs authorization and authentication) 
>with the member in pairwise key exchange (IKE Phase 1) and then the 
>KDC/GCKS downloads a key on behalf of the group owner (GDOI Phase 2).  As 
>you know, the Phase 2 can have an identity with a proof of 
>possession.  The identity for the member is a credential that shows 
>authorization from the group owner to get key material (e.g., KEK, TEKs) 
>for the group.  The identity for the KDC/GCKS shows authorization from the 
>group owner to give key material to prospective members of the 
>group.  This latter credential may be delegated.

I agree with your example for authorization to download key only. However, 
this does not give the member enough information to determine if the 
members data should be shared with the group.

I think every entity in a group that owns data, must be able to determine 
if the group is adequate to protect that data. This means that every data 
owning entity needs to see full group protection mechanisms, full access 
control rules ... This was all listed in the Group Policy Building Block 
I-D. The link however has been killed.

I think many of my positions on policy enforcement may also be explained in 
more detail in the following: "Principles of Policy in Secure Groups" 
presented at NDSS '01. The url is 
http://www.eecs.umich.edu/~pdmcdan/docs/ndss01.pdf.

>>>>Bullet 3 is critical only if the group members are going to be adding 
>>>>data to the group. The data contributors must be able to review the 
>>>>access control criteria to determine if their data is protected by that 
>>>>criteria.
>>>
>>>Would you see this as being necessarily inside of the key management 
>>>protocol?  It might be useful to list the policy items that are inside GSAKMP.
>>
>>For multi source groups it is essential to be in the KM protocol. This 
>>again relates to the abstract nature of the group. I'm accepting a key 
>>from an authorized source. That key is to be used to protect my data. 
>>Without the inclusion of this security policy information, all I know is 
>>that I'm authorized to have the key to this group. What I need (as a data 
>>sharing member) is knowledge of how much other members may be trusted. If 
>>they have the key they have access to my data.
>
>I say "trusted with what" rather than "how much other members may be 
>trusted."  Can they be trusted with the data I might send to this 
>group?  Can they be trusted to give me data that I may use?
>
>A multi-source group is protected by a data security SA.  What goes into 
>this is peculiar to the data security protocol (viz. the Appendices in the 
>GDOI draft).

I agree that you statement is more precise. How about this for more 
precision. The security policy must be specific enough for a data owning 
group member to determine what data I may share with the members of this 
group, using these mechanisms to protect that data, and with these entities 
making security relevant management decisions.

>>The example I use is my bank asking me to share my SSN via a group key. I 
>>trust the bank, I trust myself, but I don't know who they gave the key 
>>to. If they tell me that the key is held by the bank, the IRS, and myself 
>>I'll send my SSN. If they tell me the key is held by all customers of the 
>>bank I'd balk.
>>
>>The access control rules have to be disclosed to any member risking 
>>personal data on that key. Again, If I'm just listening passively no 
>>problem (then I wouldn't need to know the access rules).
>
>Does this need a representation in group key management?

In many applications, yes. This is far more tractable if we use access 
control rules, in stead of a list.

>>>>Hey we may agree soon. Then where will the fun be?
>>>
>>>In making progress.  We would make a lot of progress if we could merge 
>>>GSAKMP and GDOI into one protocol.
>>
>>Mark this was a joke. Yes convergence of GDOI and GSAKMP would be great.
>
>Or at least, we could work towards interoperability if we used the same 
>header.  GDOI needs to support an ISAKMP header since it is an IKE 
>DOI.  Why can't GSAKMP use an ISAKMP header?

I'm going to release a simpler profile of GSAKMP soon. I think we may be 
closer to a merged protocol effort than we think. I'm looking into your 
suggestions.

Hugh

________________________________________________________
Hugh Harney             [email-masked]           410-381-9400 x203
________________________________________________________

---

From: Mark Baugher <[email-masked]>
Date: Thu, 05 Jul 2001 09:48:45 -0700

Hugh
    I'm taking some time away from editing the next GDOI I-D.  The crux of 
the matter we're discussing IMHO is what gets enforced in key management 
and what gets enforced in the application that uses/incorporates key 
management.  I did get your point, however, that policy is important for 
the joining member as it is with the KDC/GCKS that admits the member.  With 
our emphasis on source-specific multicast applications where receiving 
members dominate, I tend to overlook the needs of the sending member(s), 
which tend to be specially managed in source-specific multicast 
applications such as video broadcast.  I admit that policy is important for 
members.

   The word "policy," however, means much different things in different 
contexts.  For all practical purposes, most policy is outside ISAKMP/IKE 
where policy definition is restricted to SA/Proposal/Transform payloads 
(Section 3.6 in http://www.ietf.org/rfc/rfc2408.txt).  That's a good thing 
in at least one way:  A variety of applications can use ISAKMP/IKE without 
having to understand the policies of other applications that use 
ISAKMP/IKE.  In group key management, we have the same diversity because it 
can be used among a group of four routers, fifteen military conferencers, 
or millions of TV viewers.  It may be that one group key management system 
cannot support such diverse environments.  But if one can, it will make 
minimal assumptions regarding policy:  It may be that collecting the 
identities of fifteen generals just does not scale to collecting the 
identities of TV viewers.  In fact, I'm sure this is true.

Best Regards, Mark

At 09:23 AM 7/5/2001 -0400, Hugh Harney wrote:
>>>>>Bullet two is critical for a joining member to trust the key. It 
>>>>>should be inside. This is an extension of the explicitness principle. 
>>>>>If you are using an attribute certificate (or delegation cert) then 
>>>>>this is passed via an LDAP or certificate payload. In either case the 
>>>>>KM protocol needs to review that certificate and determine the GCKS is 
>>request is often out-of-band from the key management protocol for a lot 
>>of interesting applications.
>
>
>get policy information to ALL policy enforcement agents in the group, but 
>I do believe the policy must be enforced.
>
>transmission of policy, but it does make the KM protocol self sufficient. 
>I do see value in having an optional payload for policy information.
>
>
>>>authorized to hand out the key. This is something that has to be 
>>>enforced by the joining member. The decision has to be based on some 
>>>security policy (singed by the GO) that the member has received. Yes, we 
>>>can use attribute/delegation certificates, but the member must enforce 
>>>the authorization policy before it can trust the key.
>>
>>>protocols are talking to the entity they will be using the key with. 
>>>They directly exchange signed certificates with the other side. The 
>>KDC/GCKS exchanges credentials (performs authorization and 
>>authentication) with the member in pairwise key exchange (IKE Phase 1) 
>>and then the KDC/GCKS downloads a key on behalf of the group owner (GDOI 
>>Phase 2).  As you know, the Phase 2 can have an identity with a proof of 
>>for the group.  The identity for the KDC/GCKS shows authorization from 
>>the group owner to give key material to prospective members of the 
>I think many of my positions on policy enforcement may also be explained 
>in more detail in the following: "Principles of Policy in Secure Groups" 
>>>>>access control criteria to determine if their data is protected by 
>>>>>that criteria.
>>>>
>>>that I'm authorized to have the key to this group. What I need (as a 
>>>data sharing member) is knowledge of how much other members may be 
>>>trusted. If they have the key they have access to my data.
>>
>>this is peculiar to the data security protocol (viz. the Appendices in 
>>the GDOI draft).
>
>group, using these mechanisms to protect that data, and with these 
>entities making security relevant management decisions.
>
>
>>>The example I use is my bank asking me to share my SSN via a group key. 
>>>I trust the bank, I trust myself, but I don't know who they gave the key 
>>>to. If they tell me that the key is held by the bank, the IRS, and 
>>>myself I'll send my SSN. If they tell me the key is held by all 
>>>customers of the bank I'd balk.
>>>