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

From: Andrea Colegrove <[email-masked]>
Date: Thu, 28 Jun 2001 13:06:06 -0400

Subject: Re: [Fwd: I-D ACTION:draft-ietf-msec-gkmarch-00.txt]
From: Andrea Colegrove <[email-masked]>
To: Mark Baugher <[email-masked]>
Date: Thu, 28 Jun 2001 12:59:59 -0400

Mark,
    The architecture document is for specification and discussion of technical
issues -- not opinion -- that is the issue at hand.  The document has been written
as a summary of the BBs with additional constraints and assumptions that are not
necessary except that GDOI seems to make these assumptions.  This is a fairness
issue.
     The "title" of editor sometimes seems more appropriate as the specifications
that are on standards track should reflect the combined interests of the working
group -- it is not intended to be honorary or to detract, but merely a reflection
of the responsibilities of the writers of the documents.
    I, too, gave technical arguments as to why GDOI may not be the perfect fit.  It
is not a bad solution, but let us also leave room for the ACME Group Security
Management Protocol which Joe Schmo has yet to specify.

--- Andrea

Mark Baugher wrote:

> Andrea
>    I am a co-author of the GDOI spec and have written part of the spec.  My
> co-authors have not given me any additional titles.
>
>    I gave you a technical argument and you give me back an ad hominem when
> you state that my concerns are merely to promote another specification
> through the architecture document.  I'm telling you that is not the case
> and we'll do well to keep focused on the technical issues and not pretend
> to be omniscient with respect to others' intentions.  You should ask for
> your refund from the Mind Reading Institute.
>
>    When an IETF working group is promoting two specifications that do the
> same function, then an explanation is in order.  When the function is key
> management, then the key management architecture document is an appropriate
> place to do the explaining.  The sentence that upsets you so much is the
> rationale for doing GDOI.  We are doing GDOI because a majority of the
> working group want a solution that is consistent with IKE, or else find out
> why we cannot have that.  We are doing GSAKMP because the working group
> also wants a solution that will work over security transports such as IPsec
> or SSL.  So far, our experience with GDOI (third-party analysis and
> implementation experience) leads us to believe that modifications to the
> IKE standard to support group key management is a good solution.
>
> Mark
>
> At 07:31 PM 6/27/2001 -0400, Andrea Colegrove wrote:
> >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: <[email-masked]>
> > > >Date: Wed, 27 Jun 2001 13:30:31 -0400
> > > >From: Andrea Colegrove <[email-masked]>
> > > >X-Mailer: Mozilla 4.75 [en] (Win98; U)
> > > >X-Accept-Language: en
> > > >MIME-Version: 1.0
> > > >To: [email-masked]
> > > >Subject: Re: I-D ACTION:draft-ietf-msec-gkmarch-00.txt
> > > >References: <[email-masked]>
> > > >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
> > > >
> > > >
> > > >
> > > >[email-masked] 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>ht
> > tp://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/1sh
> > adow-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-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:     <[email-masked]>

---

From: Mark Baugher <[email-masked]>
Date: Thu, 28 Jun 2001 10:57:57 -0700

At 01:06 PM 6/28/2001 -0400, Andrea Colegrove wrote:
<snip>
> > >hold for pairwise paradigms but not necessarily groups.

Please tell me the assumptions we violate by adding a DOI as specified in 
the Internet Standard?

> > >anyway (analogous to PPKs).

Why not?  Remember, this is a new DOI running here.  IPsec might kick off IKE
according to the three conditions in RFC 2401: Throw the packet away, let
it pass, apply security processing.  The Internet DOI would bring up a
Phase 1 with the sender in response to the "apply security processing"
case.  The Group DOI might do something different, e.g.
   "Join <addr, port> and receive Re-key messages associated with this
    multicast address"

Mark

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