[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt]

-- BEGIN included message

Mark, etal,
Initial comments on the architecture --

1.  Section 1. -- 

Extensions to IKE, however, are probably the best solution for IPsec 
protocols over IP multicast services [GDOI].
The architecture document is not an appropriate place for blatant editorialisms.

2. 

A "secure group" is a collection of principals, 
called "members," who may be senders, receivers or both receivers and 
senders to other members of the group. (Note that group membership may 
vary over time.) A "group key management protocol" ensures that only 
members of a secure group gain access to group data (by gaining access 
to group keys) and can authenticate group data.
A secure group is a group in which access to data is restricted to particular entities.  This access can be of read and/or write access.  In other words, a group may only have write restrictions and no read restrictions.  While this access may be enforced with group keys, it is mandated by a policy that claims data will only be accepted from particular entities, which could also be enforced with signature keys.  A key distribution protocol alone does not define a secure group.  This really demands a _security management_ protocol that can manage keys and policy.

3. 

4. The key-management protocol must be secure against man-in-the-
   middle, connection-hijacking, and reflection/replay attacks; it must
   use best-known practices to thwart denial-of-service attacks.


And type attacks.  And attacks resulting from lack of explicitness (mis-routed, mis-interpreted).  And interleaved with other protocols (protocol-oracle), etc.  Perhaps it would be better to generalize this statement.

4.  In general all the requirements for a group key management protocol refer to a group security management protocol.  For example:  Changes in algorithms, access, etc are changes to POLICY.  Policy is _so_ much more than "meta-data describing the keys."

5.  Re:  video on demand example.   The example shows a pre-existing group of all possible members subject to pre-broadcast rekey.  One broadcast would destroy this property.

6. 

A centralized
group controller (or KDC) that is used in this architecture may not be 
the best design for small, interactive groups.  But for large, single-
source multicast groups, it is generally undesirable to distribute key 
management functions among group members: Unlike small, interactive 
groups, large single-source multicast groups generally need a 
specialized KDC to support large numbers of group members.  Large 
distributed simulations, moreover, may combine the need for large-grou 
operation with many senders.
Large groups require distributed initial key distribution!  Large dynamic groups cannot rely upon a centralized KDC.  This does not scale.  This is highly inflexible.  The VoD example demonstrates this.

While the interactions with distributed rekey entities is more complicated, this functionality may be needed in composite multicast groups of limited scope.

7. 

It may be that no 
single key management protocol can satisfy the scalability requirements
of all group-security applications.  This is for further study.
It may be that the security protocols protecting group communications data cannot satisfy each of the possible sender/receiver profiles.  This is less of a security management problem.

8. 

This design is based upon a "group controller" model 
[RFC2093, RFC2094, RFC2627, OFT, GSAKMP, GDOI] with a single group 
owner as the root-of-trust.  The group owner designates a key 
distribution center for member registration and re-key.
As was originally envisioned, the group owner CAN (and for large or sparse groups SHOULD) designate multiple key servers.

9.  Section 3.2 -- The term TEK is inappropriately specific.  The group may not have encryption requirements, but only authentication.

10. 

Only one SA is optional and that is the Re-key 
SA.


Actually, one policy for the Re-Key SA is that there is none.  It is null.  Explicitly stating this prevents confusion between missing SA info and optional SA info.  Likewise, the registration protocol may involve manual methods.

11. 

The KDC, moreover, can be delegated when the 
trust infrastructure supports delegation to permit distributed 
operation of the KDC.
This statement, while correct, seems to conflict with the statement quoted in Comment #6.

12. 

MSEC assumes that at least the following group-policy information is
externally managed.
  o Group owner, authentication method, and delegation method for 
    identifying a KDC for the group
  o Group KDC, authentication method, and any method used for
    delegating other KDCs for the group
  o Group membership rules or list and authentication method


These assumptions are unnecessary as was shown by GSAKMP.
    I.  While the group owner may be published externally, the group owner can also be disclosed during the registration protocol.  It can be decided during this time whether the owner is acceptable prior to completion of registration.  Once this occurs, authenticated group policy can be conveyed to the new member using traditional mechanisms such as digital signatures tied to a PKI.
    II.  The delegation can be stated (authorized) through the authenticated policy statement as was done with GSAKMP.
    III.  Ditto for membership rules and lists
    IV.  The security association characteristics of the registration protocol can be determined early in the registration exchange or in almost all protocols (TLS, IPSec, GSAKMP, etc.) can be restricted by what properties the Key Server will accept using cipher suite restrictions, SPD constraints, etc.

    External management of these can be done, but should not be assumed in the architecture document.

13.  In general, this document contains very little new information.  The framework for the architecture was already provided by the building block documents with the category 1,2, and 3 SAs.  The architecture document should work toward providing interoperable solutions.

--- Andrea Colegrove
 
 

Internet-Drafts@ietf.org wrote:

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 Key Management Architecture
        Author(s)       : M. Baugher, R. Canetti, L. Dondeti
        Filename        : draft-ietf-msec-gkmarch-00.txt
        Pages           : 22
        Date            : 26-Jun-01

This document presents a group key-management architecture for MSEC.
The purpose of this document is to define the common architecture for
MSEC group key-management protocols that support a variety of
application, transport, and internetwork security protocols.  To
address these diverse uses, MSEC may need to standardize two or more
group key management protocols that have common requirements,
abstractions, overall design, and messages. The framework and
guidelines in this document allow for a modular and flexible design of
group key management protocols for a variety different settings that
are specialized to application needs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt

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-gkmarch-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:
        mailserv@ietf.org.
In the body type:
        "FILE /internet-drafts/draft-ietf-msec-gkmarch-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.

  ------------------------------------------------------------------------
Content-Type: text/plain
Content-ID:     <20010626132202.I-D@ietf.org>

-- END included message

Follow-Ups: