Subject: [MSEC] Re: GKM Architecture Comments

From: Lakshminath Dondeti <[email-masked]>
Date: Sun, 02 Mar 2003 23:10:28 -0500

Andrea,

We discussed your suggestions and made changes along these lines in the 
revised version of the I-D.  We will be making changes to Sec 6.1 and 
will include a section comparing GSAKMP, GDOI and MIKEY in a later revision.

We can discuss any other outstanding ones in the mailing list or at the 
meeting.  Thanks for your patience.

best regards,
Lakshminath

Andrea Colegrove wrote:
> Lakshminath,
>     Here are the changes to the msec architecture document that I
> promised we would send for inclusion in the next draft.  Comments and
> discussion are welcome.
> 
> Section 2, #3:  Key material are delivered securely to members of the
> group so that they are secret, authenticated to group members, and
> verified as coming from an authorized source.
> 
> Section 2, #4:  delete,  redundant with #3
> 
> Section 2, #5:  This is not a general requirement, but rather could come
> from local group policy.  For example, some systems may wish to grant
> archival access.  Suggest deletion of requirement.
> 
> Section 2, #7:  Suggest breaking up this requirement into key management
> performance and key management interoperability with applications.
> 
> Section 2,  Requirements list addition.  "Groups must be capable of
> securely recovering from compromise of keys."
> 
> Paragraph after Section 2, #8:  The example given is rather tangential.
> Suggest removing text after initial statement that group key management
> protocols are useful for non-multicast groups.
> 
> Second paragraph after Section 2, #8:  "... But for large, single-source
> ..."  This statement is incorrect.  Scalability studies show otherwise.
> Please delete from this sentence on to the end of the paragraph.
> 
> Section 3.1, first paragraph:  "The main goal of a group key management
> protocol is to SECURELY provide the group members with an up-to-date and
> TRUSTWORTHY security association (SA), which contains ..."  Suggested
> additions are in caps -- I am not yelling ;-)
> 
> Section 3.1, (2), last sentence:  Change "the GCKS" to "a GCKS"
> 
> Section 3.1, (2), paragraph after second bullet:  "The Re-key protocol
> ensures that all members receive the re-key information is a timely
> manner."  Since timely is relative, and since failure to receive is
> recoverable with a re-join, suggest removing this statement as it is
> vague and inaccurate.
> 
> Section 3.2, first paragraph:  TEK, this term implies encryption.  How
> about DPK = Data Protection Key?
> 
> Section 3.3, Distributed operation sentences dangling at end  Suggest
> adding "and (4) allowing distributed operation of the GCKS, when ..."
> 
> Section 3.4, Figure 2:  SAD and SPD are too IPsec-specific.  Control
> function isn't really discussed elsewhere and is largely integral to the
> GKM, telephony is outside the scope of the WG, etc.  Suggest removing
> Section 3.4.
> 
> Section 4.0, second paragraph -- GSAKMP is no longer using a
> secure-channel protocol.  Suggest removing remainder of paragraph after
> the first sentence.  Add table showing differences in features of GDOI,
> GSAKMP, and MIKEY.  Not tradeoff analysis, but just introduction to
> features.
> 
> General comment -- more telephony discussion.  Suggest removing all
> references to telephony throughout document.
> 
> Section 4.1, Registration Protocol Message Exchange:  Mikey uses
> tunnelling, but GDOI reuses design.  This is not the same approach.
> GSAKMP also reuses design.  This section needs reworking to truly
> differentiate all approaches.
> 
> Section 5.4:  Define implosion -- denial of service against self?
> 
> Section 6.1:  First paragraph, Second sentence.  "It CAN be distributed
> through announcement, other external means, or in-band with the
> registration and rekey protocols."
> 
> Section 6.1:  First paragraph, Last sentence.  Not sure that this makes
> sense.
> 
> Section 6.1:  Second paragraph:  These only true for GDOI and MIKEY, but
> are not true as general architectural constructs.  GSAKMP provides both
> through announcement and through in-band means.  Does this discussion
> belong in this document?
> 
> Section 6.1,  Third Paragraph:  "This memo assumes ..."  Huh?  These are
> features of MIKEY and GDOI, but not of the generic architecture. GSAKMP
> provides these.
> 
> Section 7:  Other areas of the document consider topologies other than
> one to many large scale.  Shouldn't this section as well?
> 
> Section 8, fifth paragraph, last sentence:  A great deal has been
> published on group security.
> 
> 
> --- Andrea and Hugh
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

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

---

From: Andrea Colegrove <[email-masked]>
Date: Mon, 03 Mar 2003 14:07:14 -0500

Thank you much.  I look forward to reading the update.

--- Andrea