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

From: Hugh Harney <[email-masked]>
Date: Mon, 02 Jul 2001 11:40:36 -0400

Mark,

>>>>GDOI assumes that at least the following group-policy information is 
>>>>externally managed.
>>>>         o Group owner, authentication method, and delegation method 
>>>> for identifying a GCKS for the group
>>>>         o Group GCKS, authentication method, and any method used for 
>>>> delegating another GCKS for the group
>>>>         o Group membership rules or list and authentication method
>>>>
>>>>There is a team of individuals who are working on group policy within 
>>>>MSEC. This team may develop alternative group policy models that will 
>>>>necessitate update to the way group policy is referenced in GDOI. For 
>>>>example, the current GDOI draft assumes the existence of a group owner 
>>>>or owners who delegate key-distribution authority to a GCKS, which 
>>>>validates a member's credentials before adding a member to a particular 
>>>>group. Alternative group policy models might require changes to GDOI 
>>>>payloads, exchanges, or processing.
>>>><end GDOI quote>
>>>
>>>Which items in the three bullets might belong in key management?
>>
>>Bullet one is ok outside.
>
>I always wondered why this would not be mandatory to be outside:  The 
>Group Owner tells you which KDC/GCKS to trust.  Would you go to the 
>KDC/GCKS and ask "who is the Group Owner that tells me to trust you?"

Just as the root certificate is self signed, there has to be a core to 
start the trust. The group owner is that core. I think Carl's idea of 
passing out your business card with your fingerprint on the back is a good 
idea. If the group owner is someone you know and they give you their card, 
then they can be an owner of a group (in a reasonable domain) and you can 
verify it is them. People get involved somewhere.

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

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.

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.

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

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

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

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

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

---

From: Mark Baugher <[email-masked]>
Date: Mon, 02 Jul 2001 08:19:48 -0700

Hi Hugh,
   I think it's useful to identify the policy that must be in key 
management from what may be in key management.  Finally, there are some 
things that won't or should not be in key management.

At 08:52 AM 7/2/2001 -0400, Hugh Harney wrote:
>Mark,
>
>
>
>>><begin second quote from GDOI>
>>>A security policy repository having some access protocol may need to be 
>>>queried prior to key-management session establishment to determine what 
>>>the initial cryptographic policies are for that establishment. GDOI 
>>>assumes the existence of such a repository and protocol for GCKS and 
>>>member policy queries. Thus GDOI requires that group-security policy be 
>>>represented in a policy repository and accessible using a policy protocol.
>>>
>>>         o Group owner, authentication method, and delegation method for 
>>> identifying a GCKS for the group

I always wondered why this would not be mandatory to be outside:  The Group 
Owner tells you which KDC/GCKS to trust.  Would you go to the KDC/GCKS and 
ask "who is the Group Owner that tells me to trust you?"

>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 

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?

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

thanks, Mark

---

From: Mark Baugher <[email-masked]>
Date: Mon, 02 Jul 2001 12:43:40 -0700

Hugh,
    I'd like it if you would copy [email-masked] on your 
responses.  That way, others can contribute, correct and learn from the 
exchange; we'll also have an archive so we don't have to re-discuss these 
issues in six or nine months, when hopefully we are finalizing standards 
for secure multicast.

At 08:52 AM 7/2/2001 -0400, Hugh Harney wrote:
>Mark,
>
>
>
>>what if GSAKMP did not incorporate "policy definition and dissemination 
>>mechanisms?"  How would this lead to a reduction in GSAKMP protocol complexity?
>
>Actually, it would only increases the complexity of one messages by one 
>payload. Most of the complexity was introduced by the assumption that the 
>security infrastructure is totally unknown and needs to be discovered.

There has been practically no discussion on this list of GSAKMP and little 
on GDOI.  So it's good to examine this difference between the 
protocols.  Is the measure of complexity simply messages and 
payloads?  When you add a new payload, you often need to understand and 
process the payload in key management.  One exception is for data security 
SAs where key management can simply pass parameters (viz. Appendices in 
http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-00.txt).  But for 
Cat-1 and Cat-2 SAs ("registration" and re-key SAs, respectively), key 
management parses and acts on the "one payload" in "one message."  That's 
not necessarily simple.

>>If we meant "THE ONLY valid key management protocol for IPsec" then why 
>>did we write "probably the best solution."  Obviously you're reading 
>>quite a bit into this.
>
>It is a very strong statement in an overall working group document. Anyone 
>reading it without a background in the field would look only at GDOI for a 
>solution. I think both protocols have their place. Working group documents 
>should either make the case for both or avoid making the case for either.

When I write "probably the best" I do not mean "one MUST use."  I'm willing 
to change the offending sentences, but I think it's kinda paranoid to take 
offense at the sentence.  It is true that GSAKMP can key IPsec AH and ESP 
as well as GDOI can.  So it makes no sense to force GDOI on an IPsec 
implementation; both GSAKMP and GDOI can update the IPsec SAD.  GDOI is a 
3kloc (thousand lines of code) extension to IKE, however, which allows 
IPsec to continue to use the same key management protocol implementation, 
namely IKE running the Group Domain of Interpretation in addition to the 
Internet Domain of Interpretation.  What GDOI can't do, alas, is run over 
IPsec or TLS/SSL.  GSAKMP does that.  We have a division of labor between 
the two group key management protocols.  If GSAKMP would adopt an ISAKMP 
header, we could merge them.

>>>nd important work. In fact, I believe policy is critical for MSEC to 
>>>specify.
>
>I think MSEC will at least start defining those things that are important 
>to group policy. The work may be taken up and expanded elsewhere, but the 
>group building secure groups should state the requirements for the policy 
>to support those groups.
>
>Simply stated, my opinion is that a key management protocol that does not 
>address policy enforcement is not providing security. Keys are only useful 
>if they represent a trusted enforcement of a policy. Passing mechanisms 
>and a random field to use as a key is meaningless, unless there is some 
>sort of policy enforcement.

"Providing security" is too vague a term.  Group key management could be 
used in a very secure system, such as a national security application 
environment.  Or it could be used in places where 10% of the members are 
trying to break the system, such as a television application 
environment.  Let's assume a national security application 
environment.  What policy must key management enforce?  Key algorithms, 
sizes, modes are one thing.  It may need to enforce authorization, which 
means that it will do what an authorization application tells it to do: It 
will go to a particular KDC/GCKS to request KEKs and/or TEKs for specific 
groups and data security SAs within those groups when an authorization app 
tells it to.

>Before you ask, yes I have a problem with several implementations of 
>IPSec. They negotiate to any common configuration without having a 
>mechanism to review if that configuration is adequate to protect the data. 
>There are policy enforcement words are in the IPSec architecture, but most 
>implementations make the SPD and SAD so difficult to configure that users 
>just make the settings generic.

This is being addressed in 
http://www.ietf.org/html.charters/ipsp-charter.html.  I don't expect that 
we will be incorporating new features into IKE, but I'm not following this 
group closely.  msec policy people should be following it closely, I think.

>>>The above represents a boolean expression. IF GDOI restricts it's policy 
>>>to cryptographic mechanisms, THEN we have to rely on an external 
>>>infrastructure to provide the services expressed in the second GDOI 
>>>quote. I believe GDOI can operate securely with this conditional boolean 
>>>statement.
>>
>>Yes, I agree with this too.  I'll add that we are able to eliminate 
>>additional parameters and options from GDOI by making this assumption.
>
>I was clarifying. I'm glad you agree. I also agree that GDOI was able to 
>gain simplicity by making these assumptions.
>
>
>>>This does not mean that I believe all MSec key management algorithms 
>>>MUST restrict themselves to only handling policy that refers to 
>>>cryptographic mechanisms, AND MUST therefor rely on an external policy 
>>>infrastructure.
>>
>>uh, why doesn't it?
>
>If you have mechanisms to pass policy then the protocol can operate with 
>only a simple PKI.

No assumptions being made about an authorization application?

Mark

---

From: Mark Baugher <[email-masked]>
Date: Tue, 03 Jul 2001 12:30:26 -0700

Hugh
   I think it's good for msec that we have this discussion on the mailing 
list.

At 11:40 AM 7/2/2001 -0400, Hugh Harney wrote:
>>>>>validates a member's credentials before adding a member to a 
>>>>>particular group. Alternative group policy models might require 
>>>>>changes to GDOI payloads, exchanges, or processing.
>>>>><end GDOI quote>
>>>>

I agree.  So "Group  Owner" is outside the key management framework.  I too 
like Carl Ellison's ideas, such as there needs to be some personal contact 
for there to be trust of personal identity.  The other two bullets are 
within key management and in fact they are in IKE as well as GSAKMP and GDOI.

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

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.

>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 

And the KDC/GCKS must enforce the policy before it can trust the member.

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

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

>problem (then I wouldn't need to know the access rules).

Does this need a representation in group key management?

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

thanks, Mark

---

From: "David A. McGrew" <[email-masked]>
Date: Thu, 26 Jul 2001 08:40:38 -0400

Hugh,

I'm a bit concerned about the "policy" issue, and I'd like to ask for
clarification.  More below:

Hugh Harney wrote in [Re: [MSEC] msec architecture draft and email flow]:
> The Group Key Management Archtecture, policy section, states that MSEC will
> totally rely on an external policy infrastructure. I believe that this
> statement is too narrow. Some applications may rely on external policy
> infrastructures, but not all. This is an architecture document for all
> applications and solutions. I believe the Policy Building Blocks document
> from the SMUG and the new policy work being done for the MSEC working group
> is valid and important work. In fact, I believe policy is critical for MSEC
> to specify.  

It seems to me that, for a policy to be meaningful, it must be enforced.  This
means that there are state machines on the group member's devices which must
change state based on the receipt of authenticated policy statements.  In order
to have a well-defined and robust protocol, it is necessary to limit the scope
of these state changes, at the very least so that they don't interfere with the
base protocol or extant security associations.

One easy way to do this is to mandate that the state machine affected by the
policy is independent from the base protocol's state machine.  In this case, the
base protocol acts as a secure transport mechanism for the policy statements. 
This is easy to achieve in any security protocol with reasonably short messages
by adding a separate field dedicated to policy transport.  If this isn't
sufficient for policy dissemination, then a separate SA can set up a secure
channel for that purpose.  In either case, the policy protocol is separate from
the base protocol.  

This separation has strong advantages for specification and implementation.  One
of the most important benefits is that the development of the key management
protocol can proceed independently of the development of policy protocols/state
machines.  This is especially important given that the policy problem is pretty
much unbounded.  As Andrea points out, static policy statements for all groups
would probably be inadequate, which suggests that extensibility should be built
into the system.

The separation out of policy state machines is somewhat like the idea of
"profiles" of a protocol, as done in RTP (rfc1889).  Each profile essentially
describes a unidirectional protocol which can use the transport provided by the
base protocol.

I'd value your thoughts on this subject.  Do you know of any policies which
can't be implemented as described above?  If so, would it be possible to limit
the interaction between the policy and the base protocol state machine to a
small and well defined interface?  

thanks,

David
[email-masked]

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 27 Jul 2001 12:19:33 -0400

David,

>base protocol or extant security associations.

Yes, agree.

>channel for that purpose.  In either case, the policy protocol is separate 

My understanding is that even before the Cat-1 SA is established, members
should have *some amount* information obtained from the *complete*
group policy (ie. represented by the Group Security Policy Token).

The first question then becomes whether members need to have the *complete*
group policy before beginning to establish the Cat-1.

The second question is whether this (ie. the first question) is
application-dependent.

I do agree, though, that separating policy delivery from key delivery
is attractive and provides a cleaner protocol set (as you say below).

thomas
-------