[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt]
Mark,
Since you are the primary author (editor?) of GDOI I am sure that you feel GDOI is best. The architecture document, however, is not the
place to promote your solution.
Many feel that modifications to a standard to support multicast is not a good solution. IKE is designed with certain assumptions which
hold for pairwise paradigms but not necessarily groups.
Also, because SPD and SAD values for a group cannot be completely determined in advance and are more likely distributed as part of the
Join/Registration process, IKE will not likely be automatically fired off anyway (analogous to PPKs).
Regardless of how you feel on this issue, it is inappropriate to state that GDOI is probably the best solution at this point in general
and certainly not in the architecture document.
Wrt GSAKMP and separating out the "key management protocol": key management involves more than distribution.
--- Andrea
Mark Baugher wrote:
> Andrea
> I respond to your first point in this note.
>
> At 01:40 PM 6/27/2001 -0400, Andrea Colegrove wrote:
>
> >X-Mozilla-Status2: 00000000
> >Message-ID: <3B3A1837.D95360C0@columbia.sparta.com>
> >Date: Wed, 27 Jun 2001 13:30:31 -0400
> >From: Andrea Colegrove <acc@columbia.sparta.com>
> >X-Mailer: Mozilla 4.75 [en] (Win98; U)
> >X-Accept-Language: en
> >MIME-Version: 1.0
> >To: msec@securemulticast.org
> >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt
> >References: <200106271103.HAA26170@ietf.org>
> >Content-Type: multipart/alternative;
> > boundary="------------E7B7F4EE607BF84BF270BC1C"
> >
> >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.
>
> It is not as you say it is. I'll ignore the rudeness of this sentence and
> focus
> on the issue: It makes no sense to force AH and ESP to select a key management
> application based on whether it has a unicast or a multicast destination
> address in
> the packet it is processing. One may want to do that, but extensions to
> IKE are probably
> the best solution for IPsec protocols over IP multicast services. This is
> an architectural
> issue for it involves multiple functional blocks (data security protocols
> and key
> management protocol) , and it is why msec will likely standardize an IKE-based
> specification in addition to a something like GSAKMP (at least the key
> management
> protocol of it once that's separated out).
>
> I'll spare ipsec my comments on the rest of your points and post only to msec.
>
> Mark
>
> >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>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>http://www.ietf.org/shadow.html
> >>or
> >><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>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>
Follow-Ups:
References: