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

From: Ran Canetti <[email-masked]>
Date: Fri, 18 Jan 2002 12:26:38 -0500

Folks,

Following the discussion in the last meeting, I'd like to initiate a formal
last-call process for moving GDOI to proposed standard. (This is the
first level in the standards ladder.) Please take time within the next two
weeks (i.e., before 2/2/2) to make another pass over the draft and make
sure you agree with what's written there. If there will be no substantial
corrections to make, we will pass the draft to the IESG for approval.

The new version of the draft contains the fix discussed on the list to 
the security flaw discovered by Cathy's protocol analyzer last month.

Best,

Ran

> From: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Multicast Security Working Group of the IETF.
> 
> 	Title		: The Group Domain of Interpretation
> 	Author(s)	: M. Baugher et al.
> 	Filename	: draft-ietf-msec-gdoi-03.txt
> 	Pages		: 31
> 	Date		: 17-Jan-02
> 	
> This document presents an ISAMKP Domain of Interpretation (DOI) for 
> group key management to support secure group communications.  The 
> 'GDOI' incorporates the definition of a Phase 1 SA of the Internet 
> DOI, and proposes new payloads and exchanges according to the ISAKMP 
> standard.  The GDOI manages group security associations, which are 
> used by IPSEC and potentially other data security protocols running 
> at the IP or application layers.  These security associations protect 
> one or more key-encrypting keys, traffic-encrypting keys, or data 
> shared by group members.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-msec-gdoi-03.txt
> 

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Wed, 30 Jan 2002 12:13:00 -0500

I was at the last meeting and as I recall the only one to have some
reservations about the last call.

First, I would like to state that I am very much interested in seeing
GDOI (preferably a modified version :-), I can wish, can't I?) as a
standard.  That said, here are the two problems I see with the current
version.  For those at the SLC meeting, this may be a repetition.

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.

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.

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.

Proposal:  Make GDOI LKH independent.

Thanks much.

best regards,
Lakshminath

---

From: Brian Weis <[email-masked]>
Date: Wed, 30 Jan 2002 17:29:02 -0800

Hi Lakshminath,

As always, thanks for your comments. I'm going to deal with the issues

> 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.

> 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.

> 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.

Does that seem sufficient to you?

Thanks,
Brian

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Thu, 31 Jan 2002 18:30:27 -0500

Brian,

Many thanks for the reply.  Please see inline.

> 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.

> 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.

best regards,
Lakshminath