Subject: Re: [MSEC] GDOI: Last call for proposed standard

From: Brian Weis <[email-masked]>
Date: Fri, 01 Feb 2002 11:37:45 -0800

Hi Lakshimath,

Lakshminath Dondeti wrote:
> 
> Brian,
> 
> Many thanks for the reply.  Please see inline.
> 
> Brian Weis wrote:
> >
> > Hi Lakshminath,
> >
> > As always, thanks for your comments. I'm going to deal with the issues
> > in reverse order:
> >
> > > 2) LKH definitions:  LKH interoperability issues need further
> > > discussion.  That stuff might be pulled out of the GDOI draft; instead
> > > the authors might propose generic payloads that accommodate any
> > > key management algorithm.
> >
> > We would prefer not to pull the LKH text out of the draft since we think
> > it provides a substantial benefit of allowing group membership changes
> > in the rekey message. However, we do indeed mean to accommodate other
> > key management algorithms, not just LKH.
> >
> > > Besides, Sun has a PATENT on LKH.  Of course, LKH is also published
> > > as an RFC by another group.  I am not a lawyer, so I don't understand
> > > how that can be resolved.
> >
> > I wasn't aware that anyone claimed IP on key hierarchies. LKH is
> > certainly defined in RFC2627 though, and I have seen companies claim
> > that they use the algorithm in their systems. So it seems safe to
> > declare how it would be used in GDOI since it isn't intended to be a
> > required feature.
> >
> > > Proposal:  Make GDOI LKH independent.
> >
> > There's (at least) two facets to independence.
> >
> > A. Making sure LKH isn't a required feature for an implementation. This
> > will be clarified in the draft.
> >
> > B. Making sure that other key management algorithms can be used. The
> > attribute list in section 5.5 lists possible key download types. There
> > are two KEK related types: KEK (which defines a single key for the
> > group), and LKH (which defines an LKH structure of keys). The list also
> > has RESERVED and PRIVATE USE namespaces which were intended to be used
> > for defining new key management types, as necessary. In particular,
> > whatever type of key management policy becomes defined the MSEC GKMARCH
> > document should be allocated from the RESERVED list at a later time via
> > the standard IANA namespace allocation process.
> 
> Thanks.  I noticed that -02- has references to OFT, but -03- did not.
> It may be because you did not want to have references to I-Ds.  But, in
> its current state, it appears from Section 5.3.2 that LKH is the only
> choice (especially to someone not familiar with research in this area)
> for a KEK_MANAGEMENT_ALGORITHM.

That's a good point. I've found that we can have non-normative
references, so I'll add some text mentioning possible alternatives and
site them.

> > > 1) The PUSH message:  For scalable and reliable transport of batch
> > > rekey messages, it may be appropriate to have two types of PUSH
> > > messages.
> > >
> > > Briefly, for group initialization and batch rekeying, the rekey/PUSH
> > > message can get too long (initialization of a logical hierarchy with
> > > n=2^16 members requires sending 2^16 KP payloads = ~2845 packets; note
> > > that each member needs only logn = 16 KP payloads = ~1 packet.  There
> > > are proposals in the literature for various groupings of keys for
> > > efficient transport).
> > >
> > > Proposal:  Allow splitting PUSH messages.
> >
> > Actually I thought splitting the messages could be achieved with what's
> > in the draft now, at least with respect to dealing with large LKH
> > updates. There is a single LKH attribute in the KD payload. That LKH
> > attribute is defined in section 5.5.3 as a list of attributes. Each
> > KEK_LKH attribute is specific to one leaf (i.e., user). If multiple
> > leafs need to be rekeyed by a group membership change, then multiple
> > KEK_LKH attributes should be included. But nothing says that all of the
> > leafs for a particular change need to be in a single rekey packet. It
> > should be feasible to split up the attributes into multiple messages.
> >
> > It would be necessary for each message to be a full rekey message
> > including the SA payload as well, since the SA payload defines the
> > policy for the KD payload.
> 
> Splitting the rekey message would have some overhead.  But including the
> SA payload with each message (within a rekeying instance, i.e., same
> SPI) would make it even worse.  Consider that we may end up sending
> hundreds of these messages per rekey instance.
> 
> In any event, I wanted to bring this discussion to the mailing list.
> Looks like no one else is interested in it anyway :-).  Furthermore,
> there are some advantages to including the SA payload with each message.
> 
> It would be good if you could add some text reflecting this discussion
> in the I-D (soon to be RFC).  Many thanks.

Will do!

Thanks,
Brian

> best regards,
> Lakshminath
> 
> >
> > Does that seem sufficient to you?
> >
> > Thanks,
> > Brian
> >
> > ---
> > Brian Weis
> > Strategic Cryptographic Development, ITD, Cisco Systems
> > Telephone: +1 408 526 4796
> > Email: [email-masked]
> >
> > _______________________________________________
> > msec mailing list
> > [email-masked]
> > http://www.pairlist.net/mailman/listinfo/msec

-- 
Brian Weis
Strategic Cryptographic Development, ITD, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

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

---

From: Mark Baugher <[email-masked]>
Date: Fri, 01 Feb 2002 13:28:56 -0800

I could not find a published description of OFT aside
from an expired I-D.  I believe we have a journal
reference to subset difference and can add that
to the draft.  And we need to make it clear that
the KEK can be used to encrypt a rekey message
without the use of a group key management algorithm
like RFC 2627 or subset difference.  That option
is in the current GDOI draft.  We should just make
this more clear in the text.

thanks, Mark