Subject: Re: [MSEC] Re-key as a separate, standards-track protocol specification

From: Ran Canetti <[email-masked]>
Date: Thu, 12 Jul 2001 00:57:01 -0400

Carl,

> In relooking at the gkmarch document, it is unclear that within the 
> document you are consistent. The requirements stated in "2.0 
> Requirements for a group key management protocol" indicate that a 
> group rekey is part (a function) of the group key management protocol.
> 
> Requirement 2. "Keys ... will be periodically refreshed."
> Requirement 3. "Key material must be delivered securely ... and 
> refreshed securely at the end of the key lifetime."
> Requirement 6. "It must be possible to provide re-key for the group ..."
> 
> Your description in 3.1 (2) of a "rekey protocol" as optional implies 
> that the requirements above (mandates) will not be met. Your note 
> that there may be other ways of causing members to arrive at a new 
> key, simply states that there are protocols which do not require data 
> transmission, that's ok, its still a protocol.

I tend to agree. So there is always a rekey protocol, just that sometimes 
it does not involve communication... this does look like a cleaner way to 
present things.

> 
> >My view is that the separate document should explore the issues such 
> >as implosion, member feedback, reliable delivery, and other concerns 
> >associated with Re-key, which can be sent either multicast or 
> >unicast.  It will also define a common encoding for key download and 
> >membership management that we will expect the msec key management 
> >protocols to adhere to.  I don't think we will achieve an identical 
> >message format so long as we expect to implement the Re-key message 
> >in diverse protocols such as IKE.  For this reason, I question 
> >whether this can be a standards-track protocol.
> 
> I think all of these issues are important, but I don't believe that 
> they'll be able to be handled by a "rekey-only" protocol. For 
> example, if we want to work on reliable delivery, what happens when 
> its not delivered, we pop back over to some other protocol. I think 
> it is safer to keep all elements of the group key management protocol 
> together to assure coverage of the features and functions.
> 

My understnding is that handling exceptions/errors in rekeying (e.g. 
expired-keys-with-no-replacement-in-sight) is part of the job of the
rekey protocol. (so this protocol may not be all one message.) 
But lets wait patiently to the rekey draft to come out...

Ran

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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 12 Jul 2001 08:28:12 -0700

Ran

>it does not involve communication... this does look like a cleaner way to

I think the name misleads people.  We arbitrarily called it "Re-key," which
might suggest that "this is how we do re-key."  In fact, this protocol is
used to push new keys to members, refresh keys, and change keys so some
former key holders lose access to the group KEK.

There is no requirement for our "Re-key Protocol," but there is always
a rekey protocol.

Mark

---

From: Thomas Hardjono <[email-masked]>
Date: Sat, 14 Jul 2001 15:19:45 -0400

Carl, Ran,

Carl,

I think the intent of the authors is to accomodate for protocol-
instantiations that do not employ multicast to help in rekeying.
Thus, any rekeying occurs one-to-one between the member and the
GCKS (which may bring us back into the scalability debate :).

> > together to assure coverage of the features and functions.

The decision taken sometime ago is for then group key management
protocol not to rely on reliable transport. Thus, the most basic
mechanisms is to do multiple transmissions.  Even that approach (assuming
Cat-3 SA is an IPsec SA) has problems w.r.t. sequence numbers and
the member knowing that multiple copies does not mean that
a replay-attack is underway.

So, I do agree that the work on the Rekey protocol should begin
with the assumption that it does not rely ony any specific
(reliable) transport.

>But lets wait patiently to the rekey draft to come out...

Actually, now is the right time to discuss the issues relating
to a Rekey protocol.  The discussions should help when thinking/writing
the draft.

The problem of "expired-keys-with-no-replacement-in-sight" is related
to the need of the GCKS to be aware of the life-times of key-trees
(or key-packs) which it sends-out.  The GCKS should maintain
its own timer and issue new TEKS (eg. under the current KEK)
sometime before the expiration of the current TEK.

Alternatively, some algorithm can be devised to allow a member
(who is time-aware) to initiate a change in the TEK (independently
of other members) in such a way that all members and the GCKS
arrive at the same new TEK.

Finally, an emergency-mode (backup) TEKs can be installed such
that if the GCKS fails to refresh the TEK, the sender switches
over of these backup TEK.

(OK, I know its crude, but these are just suggestions :).

thomas
------