Subject: [MSEC] GKM Architecture Comments

From: Andrea Colegrove <[email-masked]>
Date: Thu, 16 Jan 2003 17:19:37 -0500

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