Subject: [MSEC] Questions: Relation among GSAKMP, GDOI and other Documents

From: "Deuk-Whee Kwak" <[email-masked]>
Date: Tue, 1 Apr 2003 19:15:01 +0900

How are you?
I have been studying on the multicast key management protocols such as GSAKMP, GDOI, and MIKEY
In the document MIKEY, the authors say that MIKEY can be used as a registration protocol in the GKMArch.
But considered GSAKMP, I think I can also use GSAKMP for a registration protocol.
Is it possible? If so, what are the merits and demerits of MIKEY and GSAKMP. If not, why?

And what is the relation between GSAKMP and GDOI. If GSAKMP can be used as a registration protocol, what are the main purposes of GDOI? Is this used for re-key protocol?
It is also confusing me that there are too many key management-related documents such as GKMP architecture (RFC 2094), GKMP specification (RFC 2093), Scalable Multicast Key Distribution (RFC 1949) and so on
Are there any documents or papers that explain their relation among them?

Best regards,
D. W. Kwak

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 01 Apr 2003 10:02:40 -0500

Hi,

Yes, indeed it is confusing.  If you look for "Standards Track"
documents only, your field will narrow down a bit.  But you will still
have a few (GDOI, GSAKMP, and MIKEY) remaining to choose from.  So, I
invite the individual I-D authors to send their thoughts on how their
protocols differ from others.

In fact, I have requested some of the authors to send an email to
GKMarch authors along these lines, so we can document the applicability
of the three Group Key Management Protocols that are on Standards Track
in MSEC.  Please send your thoughts to the list.  Many thanks.

best regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 01 Apr 2003 10:24:09 -0500

Hi Kwak,

I will try to answer some of your questions:

> Are there any documents or papers that explain their relation among them?

GSAKMP and GDOI are both complete group key management protocols.  Both
have the Registration Protocol and the Rekey protocol, and are
independent of each other.

If you look at the old GSAKMP docs (pre-lite), you will notice that
GSAKMP was using a secure tunnel, which could be established using say
SSL, to protect group key establishment.  GDOI is similar to IKEv1, and
comes with all its advantages and of course, the ISAKMP baggage :-).
That was one of the main differences.

However, GSAKMP-lite or the new GSAKMP does not use a secure tunnel and
relies on a DH exchange with signatures.  It also relies on an
announcement protocol so the GCKS can announce the security mechanisms
used by the group beforehand; this reduces the number of round trips.
There is a Policy Token payload which differentiates it from the other
two protocols.

regards,
Lakshminath

---

From: Hugh Harney <[email-masked]>
Date: Tue, 1 Apr 2003 13:36:11 -0500

Hi,

Let me take a shot.

GDOI

GDOI offers key distribution from a single source to a group. It 
assumes that the joining members know the identity of the authorized 
GC/KS. It is a centralized key dissemination architecture. This works 
well when there is a single well know data source.

GDOI contains in it the policy information necessary to set up the 
IPSec SPD and SAD.

GSAKMP (there is only one draft going forward to standards track at 
this time)

GSAKMP provides policy distribution and enforcement. It allows the key 
dissemination process to be distributed to ensure scalability, via the 
secure establishment of subordinate GC/KSs. GSAKMP requires that the 
Group Owner create a policy token that describes the desired security 
policy for the group. This token is signed by the owner, and all 
security policy decisions are based on that verifiable token.

GSAKMP assumes the members "know" the default GSAKMP group join 
mechanisms. If any other security suites are defined, they will have to 
be announced to the group. This allows GSAKMP to support other 
algorithm types beyond the default. This optional announcement portion 
of GSAKMP is the only reliance on announcements. GSAKMP itself is self 
contained.

The process GSAKMP uses to bring someone into a group is as follows. 
GSAKMP assumes the members know nothing except the point of trust, the 
ID of the Group Owner. The joining member sends a request to join to 
the GC/KS. The GC/KS reviews the RTJ with respect to the access control 
security policy as defined in the policy token. If the potential member 
meets the access control criteria, the GC/KS creates a message that 
will download key. The joining member reviews the policy token (sent to 
the member as part of the download message) to determine if the GC/KS 
is authorized to distribute key for this group. If everything goes well 
the group member retrieves the key and ACKs the GC/KS

The difference between GDOI and GSAKMP lies in the enforcement of 
security policy and the establishment of subordinate GC/KSs.

MIKEY

MIKEY was developed for mmusic. I have not looked at it in sufficient 
detail to offer an opinion.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 01 Apr 2003 13:50:37 -0500

Thanks for the summary Hugh!  I have a few questions for further 
clarification.  What is the secure data transport protocol for GSAKMP? 
AFAIK, it is either IPsec or SRTP for GDOI, and SRTP for MIKEY.

Let us say for argument sake, we incorporate a) Policy Token into GDOI 
and b) whatever comes out of the new MSEC charter for distributed 
operation into GDOI, would we still need GDOI and GSAKMP?  Or, is there 
a reason that functionality cannot be added to GDOI (post RFC)?  At that 
point the only disadvantage of GDOI (IMO) is that is has too many 
messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ).

regards,
Lakshminath

Hugh Harney wrote:
> Hi,
> 
> 
> Let me take a shot.
> 
> 
> GDOI
> 
> 
> GDOI offers key distribution from a single source to a group. It assumes 
> that the joining members know the identity of the authorized GC/KS. It 
> is a centralized key dissemination architecture. This works well when 
> there is a single well know data source.
> 
> 
> GDOI contains in it the policy information necessary to set up the IPSec 
> SPD and SAD.
> 
> 
> GSAKMP (there is only one draft going forward to standards track at this 
> time)
> 
> 
> be announced to the group. This allows GSAKMP to support other algorithm 
> types beyond the default. This optional announcement portion of GSAKMP 
> is the only reliance on announcements. GSAKMP itself is self contained.
> 
> 
> ID of the Group Owner. The joining member sends a request to join to the 
> GC/KS. The GC/KS reviews the RTJ with respect to the access control 
> meets the access control criteria, the GC/KS creates a message that will 
> download key. The joining member reviews the policy token (sent to the 
> member as part of the download message) to determine if the GC/KS is 
> authorized to distribute key for this group. If everything goes well the 
> group member retrieves the key and ACKs the GC/KS
> 
>

---

From: Mark Baugher <[email-masked]>
Date: Tue, 01 Apr 2003 11:32:15 -0800

Hi Lakshminath
   Thanks for the good summary of GSAKMP and GDOI.

Mark
At 10:24 AM 4/1/2003 -0500, Lakshminath Dondeti wrote:
> > And what is the relation between GSAKMP and GDOI. If GSAKMP can be used 
> as a registration protocol, what are the main purposes of GDOI? Is this 
> used for re-key protocol?
> > It is also confusing me that there are too many key management-related 
> documents such as GKMP architecture (RFC 2094), GKMP specification (RFC 
> 2093), Scalable Multicast Key Distribution (RFC 1949) and so on

---

From: George Gross <[email-masked]>
Date: Tue, 1 Apr 2003 13:36:52 -0500 (EST)

Hi,
	while rev'ing the arch doc's text that contrasts GDOI vs. GSAKMP,
I would suggest that mention be made of how GDOI leverages the phase 1
ISAKMP/IKE-v2 security association to secure the GDOI exchanges. The
advantage is that the use of ISAKMP/IKE can fit within an Enterprise's
existing VPN authentication policies. For example, the ISAKMP/IKE-v2
exchanges may include the EAP authentication of the operator (e.g. an
Enterprise remote access scenario).

	That said, I did have a question about the GDOI GROUPKEY-PULL
exchange. See below...

br,
	George

> messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ).

The GDOI GROUPKEY-PUSH exchange goes through the expense of proving the
liveness of the initiator and responder to protect against replay attacks.
This incurs an extra message roundtrip exchange and perhaps a D-H
computation.  I could see the logic of doing this if the ISAKMP phase 1 SA
was "stale", i.e. it had not been just created, but it seems as if this
GDOI phase 2 exchange could be optimized (skipped?) if you had just
finished proving the initiator and respondor's liveness during the phase 1
SA setup. or would that open a vulnerability?

As it stands now, to setup a group member join using GDOI, I count:

a. 4 ISAKMP/IKE-v2 messages (2 round trips)

b. assume 4 messages for the EAP exchange

c. 4 messages for the GDOI GROUPKEY-PULL

d. N messages for the GDOI GROUPKEY-PUSH, where "N" depends on how many
datagram it takes to express the rekey (which I infer may be more than one
if using LKH)

so the total is 12 + N, right?

---

From: Hugh Harney <[email-masked]>
Date: Tue, 1 Apr 2003 15:36:56 -0500

Lakshminath,

GSAKMP provides secure cryptographic groups. It can hand this group key 
off to any secure data delivery protocol. The MSEC charter states 
IPSec, so the GSAKMP policy token provides all the policy for IPSec. I 
would note that GSAKMP could support any group secure data protocol. 
The policy token is written to be generic enough to provide the policy 
for any data deliver protocol, also.

I also wrote the GSAKMP protocol to allow other protocols to use it - 
GDOI or MIKEY or any other. So if GDOI wanted to use the policy token 
it's pretty much ready to roll.

The only other difference between GSAKMP and GDOI is the concept GSAKMP 
has of subordinate GC/KSs.

Hugh

On Tuesday, Apr 1, 2003, at 13:50 US/Eastern, Lakshminath Dondeti wrote:

> operation into GDOI, would we still need GDOI and GSAKMP?  Or, is 
> there a reason that functionality cannot be added to GDOI (post RFC)?  
> At that point the only disadvantage of GDOI (IMO) is that is has too 
> many messages (3 or 5 in GSAKMP vs. Many in GDOI :-) ).
>
> regards,
> Lakshminath
>
> Hugh Harney wrote:
>> Hi,
>> Let me take a shot.
>> GDOI
>> GSAKMP provides policy distribution and enforcement. It allows the 
>> key dissemination process to be distributed to ensure scalability, 
>> via the secure establishment of subordinate GC/KSs. GSAKMP requires 
>> that the Group Owner create a policy token that describes the desired 
>> security policy for the group. This token is signed by the owner, and 
>> all security policy decisions are based on that verifiable token.
>> mechanisms. If any other security suites are defined, they will have 
>> to be announced to the group. This allows GSAKMP to support other 
>> algorithm types beyond the default. This optional announcement 
>> portion of GSAKMP is the only reliance on announcements. GSAKMP 
>> itself is self contained.
>> GSAKMP assumes the members know nothing except the point of trust, 
>> the ID of the Group Owner. The joining member sends a request to join 
>> to the GC/KS. The GC/KS reviews the RTJ with respect to the access 
>> control security policy as defined in the policy token. If the 
>> potential member meets the access control criteria, the GC/KS creates 
>> a message that will download key. The joining member reviews the 
>> policy token (sent to the member as part of the download message) to 
>> determine if the GC/KS is authorized to distribute key for this 
>> group. If everything goes well the group member retrieves the key and 
>> ACKs the GC/KS
Hugh Harney							Sparta, Inc.
[email-masked]						7075 Samuel Morse Drive
(410) 872-1515 x203					Columbia, MD, 21046

---

From: Mark Baugher <[email-masked]>
Date: Tue, 01 Apr 2003 12:52:34 -0800

George,
   You're right:  GDOI has a lot of messages in in it's GROUPKEY-PULL, but 
no more than IKE v1.  The GROUPKEY-PUSH messages are optional an unneeded 
for the initial establishment of the group key, which is done by the pull.

   I noticed that you estimate the message cost based on IKE v2.  If we 
defined an GDOI child SA exchange, then I expect we could reduce the 
message overhead of GDOI considerably.

Mark

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 01 Apr 2003 16:18:02 -0500

George,

I am not sure about the interaction between GDOI and IKEv2.

I agree with the other stuff about EAP etc.  Indeed that was the 
intention behind using ISAKMP/IKEv1 for GDOI design, i.e., we don't have 
to reinvent NAT traversal, EAP etc.

> a. 4 ISAKMP/IKE-v2 messages (2 round trips)

I would say 6/3, depending on main/aggressive modes of IKEv1.

> datagram it takes to express the rekey (which I infer may be more than one

If it is immediate rekeying using LKH, the rekey message might not be 
very large (see my presentation at the SLC meeting, available at 
www.securemulticast.org, I think).  Thus N may not necessarily be large.

> so the total is 12 + N, right?

As Mark suggested in his message, and going even further, a redesign of 
GDOI along the lines of IKEv2 would reduce the number of messages 
considerably.

regards,
Lakshminath

---

From: Lakshminath Dondeti <[email-masked]>
Date: Tue, 01 Apr 2003 16:33:54 -0500

Hugh Harney wrote:
> off to any secure data delivery protocol. The MSEC charter states IPSec, 
> so the GSAKMP policy token provides all the policy for IPSec. I would 
> note that GSAKMP could support any group secure data protocol. The 
> policy token is written to be generic enough to provide the policy for 
> any data deliver protocol, also.

Hugh,

Thanks for the explanation.  Yes, I recall having this discussion at the 
meeting now.  My understanding at the time was that we would need a shim 
to translate the Policy Token into an SAD entry.  Do you agree?

regards,
Lakshminath

---

From: George Gross <[email-masked]>
Date: Tue, 1 Apr 2003 17:01:37 -0500 (EST)

Hi Mark,

	comments inline below...

br,
	George

> message overhead of GDOI considerably.

I think that defining a GDOI child SA exchange would be good thing. It
would reduce latency for the most frequent case (join to an existing
group) from 8 + N to 6 + N messages, assuming there wasn't an EAP
exchange, and that you could skip the GDOI liveness test exchange.

so would GDOI signal one of two exchange sequences to allow this
optimization?

---

From: Mark Baugher <[email-masked]>
Date: Tue, 01 Apr 2003 16:53:59 -0800

George,

>exchange, and that you could skip the GDOI liveness test exchange.

Why do you add N?  We don't require any pushes.

>so would GDOI signal one of two exchange sequences to allow this

I don't know how IKE does it.  I'd look at that first.

Mark

> assumes
> algorithm

---

From: George Gross <[email-masked]>
Date: Tue, 1 Apr 2003 19:04:33 -0500 (EST)

Hi Mark,

	maybe I misunderstood the conditions that can trigger
GROUPKEY-PUSH, see my question below...

br,
	george

<snip>

> Why do you add N?  We don't require any pushes.

hmmm... when you add a new member to the group, don't you have to re-key
to assure backward and forward secrecy? I was assuming you do not unicast
the new group key to every registration SA, instead you GROUPKEY-PUSH
multicast the new group key. at least that's how I interpreted the
draft...

<snip>

---

From: Mark Baugher <[email-masked]>
Date: Tue, 01 Apr 2003 18:50:59 -0800

George,

>multicast the new group key. at least that's how I interpreted the

This is true when forward and/or backward secrecy is required.  I agree.

Mark

---

From: Hugh Harney <[email-masked]>
Date: Thu, 3 Apr 2003 12:24:38 -0500

Lakshminath,

> Hugh Harney wrote:
>> Lakshminath,
>> GSAKMP provides secure cryptographic groups. It can hand this group 
>> key off to any secure data delivery protocol. The MSEC charter states 
>> IPSec, so the GSAKMP policy token provides all the policy for IPSec. 
>> I would note that GSAKMP could support any group secure data 
>> protocol. The policy token is written to be generic enough to provide 
>> the policy for any data deliver protocol, also.
>
> Hugh,
>
> Thanks for the explanation.  Yes, I recall having this discussion at 
> the meeting now.  My understanding at the time was that we would need 
> a shim to translate the Policy Token into an SAD entry.  Do you agree?

Well, most the the shim exists in the form on PF_Key