Subject: [MSEC] Re: I-D ACTION:draft-ietf-msec-gspt-00.txt

From: Mark Baugher <[email-masked]>
Date: Mon, 17 Sep 2001 10:41:36 -0700

You did a great job pulling this together well before the next IETF 
meeting.  We need to consider this document as we work on the next revision 
of the key management architecture.  I gave it a first read and made a lot 
of notes.  I'll mention some things here and the rest later.

My first question is:  What do we do with this?  Does it get coded in a 
structure and passed through announcement, key management, and other group 
protocols?  Do you think that this spec is intended to be implemented?  In 
its present form?  Figure 2 looks neat.  It appears that policy gets put in 
a policy repository, which only feeds key management.  That would suggest 
that this goes into (a) a policy repository schema and (b) a key management 
payload.  But the GO has a flow to ANNOUNCEMENT, and the draft does not 
define what this is - the draft explicitly states that it does not define 
what it is.  Maybe it should define what it could be?  Do we need policy 
profiles to help people through this complex process?

On p.5, (a), the GID is identified as a unique ID.  Is it unique to an 
owner, GCKS, or is it globally unique?  Does this always require a 
PKI?  X.509 naming?  In 4.1 you say that the group ID consists of an "IP 
Addresses and serial numbers, and a Timestamp."  I don't understand why it 
has to include such things.  We have avoided introducing timestamps in the 
architecture so far.  Do we really want to require synchronized clocks? Pg. 
5 (b) mentions entities and actions but does not state what these are.

On p6, (d), key change and key push should be included, shouldn't it?

I don't get the notion of a "bypass SA" on p.10, 4.4.

The bypass SA appears in the example section 6.  I don't get the example 
because there are two distinct cases that are not distinguished in section 
6.  The first case is using a key management protocol to install SAs for a 
security protocol such as ESP, AH.  Note that 6.1 identifies GSAKMP as a 
"group security protocol" and this is not the terminology we have adopted 
in gkmarch: There are key management protocols such as GSAKMP and GDOI that 
manage SAs for security protocols such ESP and AH.  So GSAKMP could be run 
over IPsec (ESP and AH security protocols) and there are policy choices for 
how this is to be done.  _And_ GSAKMP could be run to establish multicast 
SAs for IPsec (ESP and AH security protocols using IP multicast 
delivery).  What are we talking about in section 6?

Thanks, Mark

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

---

From: [email-masked]
Date: Mon, 17 Sep 2001 07:00:30 -0400

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		: Group Security Policy Token
	Author(s)	: T. Hardjono et al.
	Filename	: draft-ietf-msec-gspt-00.txt
	Pages		: 26
	Date		: 14-Sep-01
	
This document provides a definition for Group Security Policy, describes 
the set of elements that make-up an instance of group policy for a given 
group, and provides an explanation of the intended functions of each 
element of a group security policy as expressed in the form of the 
Policy Token or Policy Certificate.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msec-gspt-00.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-gspt-00.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-gspt-00.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.