Subject: Re: Group Key Determination Algorithms --- Re: [MSEC] Session ID and Group ID

From: Thomas Hardjono <[email-masked]>
Date: Sun, 01 Apr 2001 10:51:15 -0400

Ran,

I was not referring to the general GKMBB draft here, but rather to the
specific key-tree type algorithms, three of which are LKH, OFT, OFC.
If these are similar enough, then we need to have a draft describing
them in detail to help implementors. If they are not similar, then we will
need individual drafts for each.

Obviously there will be other group rekey algorithms not based on key-trees.
They will have to be introduced as separate drafts.

However, we must deal with what we have in front of us now (namely the
key-tree algorithms).

cheers,

thomas
------

At 3/31/01||01:20 PM, Ran Canetti wrote:
> > I think we did agree somewhere along the line that a draft(s) is needed
> > to cover the "Group Key Determination Algorithms",
> > which is my formal way of saying LKH, OFT, OFC, etc. (ie. Key Trees
> > in general).
>
>
>alternative names are "group re-keying algorithm"  or "group key update
>algorithm".
>
> > Are we limited to simply providing a variable-length payload
> > for a flattened Key-Tree, or is there sufficient similarity
> > among the Algorithms that we can provide a finer granularity
> > standard payload?
>
> > Also, is there a "standard" that describes how (say) the LKH algorithm
> > works (in the same way that there is, say, a DES standard document)?
> > I know LKH isn't an algorithms in the sense of DES, but really
> > a standard is this sense is just a step-by-step description of
> > how to manipulate the bits (be they keys or data).
>
>
>There are many ways of going about the re-keying
>process, even if we are restricting ourselves to LKH/OFT (e.g., doing
>"heartbeat rekeying", different ways of generating the keys in the tree
>pseudorandomly from each other, changing keys at specific times (as
>suggested by Bob Briscoe a couple years back) and more). Furthremore,
>there are key update algorithms that are not based on trees at all.
>So, to allow for extra flexibility in the choice of the key update
>algorithm it may be good to specify, in the general GKMBB framework,
>only a generic payload for the key update information. Then, specific
>drafts will describe how this generic payloads are interpreted by
>specific key update algorithms.
>
>
>Ran

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

---

From: Ran Canetti <[email-masked]>
Date: Sun, 1 Apr 2001 14:26:27 -0400

I agree that it's a good idea to see if we can manage to have a single
coherent draft that puts the various tree-based rekeying schemes in one
framework  and in particular uses a single template encoding mechanism
for the "key update payload" when one of these schemes is used. 
This would both enhance our understanding of these schemes and would 
simplify coding. (This will not harm the overall 
flexibility since the GKMBB draft will refer to this payload as 
a generic one, and will allow other rekeying mechanisms.)

Any volunteers?

Ran