Subject: [MSEC] The new GKM architecture draft

From: Ran Canetti <[email-masked]>
Date: Thu, 28 Jun 2001 15:54:14 -0400

*my apology for the potential double posting - my previous posting of this note 
seems to have gotten lost somewhere... *

Folks,

[For the purpose of this discussion I am taking my "co-chair hat" off, and
writing as a document editor.]

I had planned this mail to precede the publication of the GKM architecture
draft, but did not make it in time. My apologies.

The goal of this draft is to provide a common framework for various
key management protocols (including GDOI, GSAKMP with its many options, and
potentially others). The main thesis of this architecture is to separate
between the the following two components of group key management:

o The "registration protocol" (ie, the unicast protocol between a
  joining member and the KDC).
 
o The "rekey protocol" (ie, the protocol in which the KDC sends update 
  messages to current group members). 

The draft states that the two protocols can be separate and need not be
"bundles up". This allows for greater flexibility: Once can decide whether
to do IKE/IPSEC/TLS-based registration without changing the rekey protocol.
Similarly, one can decide on different rekey protocols (OFE/LKH/Others, 
or to not rekey at all, as [MARKS] does), again without affecting the
registration protocol. 

The obvious issue here is how will the necessary information will be 
communicated from the registration protocol to the rekey protocol to the
data-security protocol. This will be done via the following security
associations (which are regarded as databases sitting inside each member):

o The "rekey SA". This SA is potentially initialized by the registration 
protocol and is used and updated  by the rekey protocol.

o The "data SA". This SA is potentially initialized by the registration
protocol, is updated by the rekey protocol, and is used by the data security
protocol.

This is the main framework of the suggested architecture. There are many
more details; please see the draft. When reading, please keep in mind that
this is a preliminary draft, and post any remarks you have to the list.
We will update it accordingly.

Best,

Ran

Some remarks:

1.  Note that the rekey SA is not mandatory - if the policy does not use
rekeys then this SA is redundant.

2. Note that the data SA need not necessarily be initialized by the
registration protocol. One can think of a scenario where a member registers
in advance to actually joining the group, and the actual initialization of
the dat SA is done at a later time by the rekey protocol.

3. Note that the "cat 1 SA" (or, registration SA) does not appear in the
above description at all. Indeed, this SA is internal to the registration
protocol and therefore does not need to be specified/dicussed in this
architectural document. It is up to the registration protocol.

4. A word on the issue of distributed versus centralized KDC. 
It seems to me that the distinction between the two cases is to a large
extent "transparent" for the GKM architecture draft. Indeed, the draft 
specifies two protocols (registration and rekey). These protocols would
remain unchanged regarless of whether all members run the protocol with the
same KDC or alternatively different members talk to different KDC's.
Same goes for the rekey protocol. So, in other words, the decision of
whether to have a distribued or centralized KDC architecture is up to the
group manager and is "transparent" to the KGM architecture and to the group
members.
  
5. Neither of the current proposals for key management - GDOI and GSAKMP -
are compatible with this architecture, since they bundle the rekey
protocol within the registration protocol. Both will need to be modified
accordingly if this architecture is to be accepted by msec. The big benefit
is that both protocols will be able to co-exist within one framework.

6. A separate draft on the rekey protocol is currently being written 
by Lakshminath Dondeti and David Mcgrew. Hopefully it will be available
soon.

7. There is another issue which I wanted to bring up - a possible 
"de-registration" protocol. We discussed this issue among the authors 
of this draft and decided to bring it up to the list. But I'll defer
this issue to a differnt message.

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