Subject: [MSEC] I-D ACTION:draft-ietf-msec-gdoi-03.txt

From: [email-masked]
Date: Fri, 18 Jan 2002 09:42:06 -0500

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-msec-gdoi-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-msec-gdoi-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Lakshminath Dondeti <[email-masked]>
Date: Fri, 18 Jan 2002 14:06:37 -0500

GDOI authors,

Some comments and questions, mostly minor, on the latest version follow. 

++++++
Missing Section 6 (Application Scenarios)

Several keywords and phrases have ?? marks around them in page 3!

Page 4, para 1:  GDOI sender (or should it be GCKS?) encrypts the 
GROUPKEY-PUSH message using the KEK Re-key SA.  

Section 3.0, para1: 

"The GROUPKEY-PULL exchange downloads the group key encrypting key 
   (KEK) or KEK array under the protection of the Phase 1 SA." 

What about TEK(s) and the Data Security SA?

Section 3.2:
  *an* Phase 2  

4.6:  Could the delete payload go anywhere in the PUSH message?  
Does it mean delete all SAs?  Can we delete (expiring SAs based on 
criteria other than time, for example) some of the SAs and keep others 
around?

Use of the word Initiator is confusing (3.3 and 4.7).  It could be
Rekey initiator in Section 4.7, to distinguish from the earlier use 
in the context of the Registration message (PUSH).

5.3:  Is SAK an IPsec SA as well?

5.5.1.1.  Brian,  is the change -we agreed on during the interop
testing-
for sending TEK attributes regardless of whether we are using DES or
3DES
still valid? 

FIO, it was to send 64 bits in case of DES, 192 bits in case of 3DES and
so 
on.  In other words, keys are bunched together, so we only send one 
TEK_ALGORITHM_KEY attribute instead of 3 in case of 3DES for example.  

References:  No references to other MSEC drafts (existing and
forthcoming) :)

I will comment separately on the last call and the issues thereof :-)

best regards,
Lakshminath

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

---

From: Brian Weis <[email-masked]>
Date: Fri, 18 Jan 2002 16:02:28 -0800

Hi Lakshminath,

Many thanks for your comments.

> Missing Section 6 (Application Scenarios)

This section was mostly background information and while it was helpful
throughout the development of GDOI we didn't deem it appropriate for an
RFC. The content of the old section 6 was summarized in a new section
1.1.

> Several keywords and phrases have ?? marks around them in page 3!

Thanks for pointing that out. The double-quotes were mis-translated when
converting from Word.

> GROUPKEY-PUSH message using the KEK Re-key SA.

Yes, we should specifically say GCKS.

> What about TEK(s) and the Data Security SA?

Seems like they ought be added here too.

>   *an* Phase 2

Got it.

> criteria other than time, for example) some of the SAs and keep others

Where the Delete payload is placed in the push message is not well
enough defined. I propose that it should follow the SEQ payload. That
is,
              <---- HDR*, SEQ, [D,] SA, KD, [CERT,] SIG
I further propose that if the GCKS has no more SAs to send in the
GROUPKEY-PUSH message the the SA and KD payloads be omitted, so that the
full message is as follows:
              <---- HDR*, SEQ, D, [CERT,] SIG

Regarding the format of the payload, by 'ISAKMP Delete payload" we meant
those defined in section 3.15 of RFC 2408. That definition has an
explicit format, including a Protocol-Id and list of SPIs for that
Protocol-Id. So it can't mean "delete all SPIs"; you have to itemize
them. GDOI does have a TEK Protocol-Id field and we've defined SPIs for
TEKs so that fits nicely. I'll add text declaring that the Protocol-ID
namespace for Delete payloads is the same as the TEK namespace.

This section makes no judgment about why a peer chose to delete the SA
(e.g., by time, or by user intervention) so no such criteria is
mentioned.

> in the context of the Registration message (PUSH).

Good point. Initiator/Responder terminology make sense in the
registration message, but not completely in the rekey message. I'll
change Section 4.7 to be "GCKS Operations" and 4.8 to be "Group Member
Operations".

> 5.3:  Is SAK an IPsec SA as well?

The identity fields were added to convey to the group member how the
rekey message will be sent. E.g., in the multicast case what is the
valid sender (source in the IP header), and  multicast group (dest in
the IP header), as well as defining the protocol and port.

We specified he same format for identities as in the TEK SA (i.e., IPSEC
identities) for simplicity. These identities give us both IPv4 and IPv6
identity types.

> for sending TEK attributes regardless of whether we are using DES or

Yes, absolutely -- I'll add text clarifying this.

> References:  No references to other MSEC drafts (existing and

Right. Referencing I-Ds in a standards-track RFC is tricky so we removed
references to all I-Ds. It can be done in a limited way, but we thought
it would be safer to not refer to them at this time.

Thanks!
Brian

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