Subject: Re: [MSEC] GSAKMP Light Cookies

From: Hugh Harney <[email-masked]>
Date: Fri, 15 Nov 2002 15:02:47 -0500

Mark,

I'm really sorry it took me so long to respond to you. I've been too busy.

I took some time and tried to answer your question below.

At 12:34 PM 10/29/02 -0800, Mark Baugher wrote:
>hi Peter
>   when I read that you all are incorporating additional ISAKMP features, 
> I have to ask the question:  What are the significant differentiators 
> between GSAKMP Light and GDOI?

GDOI vs GSAKMP

Mark Baugher asked about the difference between GDOI and GSAKMP recently. 
The two protocols are similar and have some overlapping functions. I think 
it would be useful to describe the similarities and differences between the 
two protocols.

Similarities

GDOI and GSAKMP are designed to be key management protocols. The 
similarities are as follows.

Secure download of key

Both GDOI and GSAKMP download a key from a Group Controller to a Group 
Member. GDOI can either download the group key under an IKE phase 1 key, or 
it can employ a key exchange to create a key encryption key to further 
protect the group key during download. GSAKMP always uses a key 
determination protocols to create a key encryption key for protection of 
the group key.

Support IPSec ESP and group membership management

Both GDOI and GSAKMP supply key and policy information necessary to set up 
IPSec ESP. Both provide group membership rekey mechanisms.

Differences

The main difference between GDOI and GSAKMP stems from the authors handling 
of security policy. GDOI specifically provides IPSec SPD policy 
information. GSAKMP provides a "policy token" as a flexible policy 
dissemination mechanism within the protocol.

The other difference stem from the requirements each protocol was designed 
to meet. GDOI was aimed at a single source broadcast requirement. GSAKMP 
was aimed at multi-application, distributed operations requirements.
Single vs. multiple data sources in a group

In peer to peer IKE both parties verify that they want to talk to each 
other. Everyone in fully knowledgeable of the security policy for that peer 
to peer SA. In a Group SA, the key is distributed from a single site. The 
members do not necessarily understand the access control policies that is 
enforced for that group. This is a problem for members that may want to 
contribute data to that group. The member has no information about who will 
get access to the data they encrypt with that group key.

GDOI assumes that the group controller (enforcer of the access control 
policy) is the only contributor of data to the group. If multiple members 
want to distribute key to the group, those members will have to get the 
access control policy from another protocol.

GSAKMP assumes that all members will need the access control parameters in 
order to trust the group key. The policy token contains an explicit 
definition of the access control policy and is distributed as part of the 
GSAKMP exchange.

Scalability

The MSEC architecture framework document, shows that distributed key 
dissemination, and access control enforcement, is desirable in a multicast 
key management protocol to support large groups.

The distribution of security functionality to facilitate scalability must 
be done in a manner that allows all group members the ability to verify the 
authority of the action. Failure to allow verification will result in the 
overall group to be vulnerable to various DoS and masquerade attacks.

GDOI uses a shadow certificate approach where distributed key dissemination 
points will all present the same authorization information to joining 
members in a group. This allow all joining members to verify that they are 
joining the correct group from an authorized keying agent. The distribution 
of these shadow certificates is undefined in the GDOI protocol. It is 
important to note that the secure distribution of these shadow certificates 
directly impact the security and trust of the group key.

GSAKMP explicitly defines the authorized distribution agents (subordinate 
group controllers) as part of the policy token. The policy token itself is 
signed by a trusted policy creation authority allowing the joining members 
a direct verification mechanism for accepting keys.

Expandability

Group security spans several cryptographic applications - multicast IPSec 
(to be sure), distributed computing applications, video audio conferencing, 
s-mime, and collaborative workspaces. Each of these applications could 
benefit from a single group key management protocol that is flexible enough 
to supply key and configuration information.

Even in the realm of IPSec there are several security protocols that may 
need key to provide a secure GSA system. Some of these other security 
protocols that are relevant to the GSA system are group source 
authentication protocols (ref: tesla, lam/wong, etc), various group 
management protocols (ref: LKH, OFC, OFT, Subset Diff), multi-layer 
encryption protocols (ref: session layer encrypt for video, app msec 
protocol). A single key and security management protocols that is flexible 
enough to support all these protocols would be a boon to security.

GDOI is tightly coupled with IPSec ESP. It provides the keys and policy 
information necessary to set up this SA for a group. Any expansion of the 
policy distribution requirements,  (for example: to support for example the 
Tesla time information), would require a modification to GDOI (addition of 
a policy payload for Tesla).

GSAKMP provides a generic policy distribution mechanism in the policy 
token. The policy token could be modified to support any number of 
different group applications without modification of the GSAKMP protocol 
itself.

Relationship to "other" protocols

Creation of a trusted group security association requires trust in all the 
security relevant events that set up that GSA. For example, you could have 
the strongest key download protocol in the world, but if the system that 
distributed the security policy is faulty the key would be "at risk". The 
point here is that trust is created when the entire system is secure, not 
just a subset of the system is secure.

GDOI is secure as specified to set up a IPSec ESP group, if the key 
dissemination point is also the sole source of data in that group. GDOI 
could use other protocols to distribute security policy to facilitate 
multiple data sources in a group. GDOI could use a certificate delegation 
protocol to delegate authority for multiple key dissemination sites in a 
group. Any support protocols used to expand the functionality of GDOI must 
be trusted the same level that GDOI is trusted. Group security is 
unfortunately, a system.

GSAKMP is largely self contained. It contains a flexible policy 
dissemination data structure that facilitates distributed architectures and 
full policy enforcement at the Group Controllers and the Group Members.

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

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