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

From: Mark Baugher <[email-masked]>
Date: Wed, 27 Jun 2001 14:19:06 -0700

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>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:
>>         [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]>

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

---

From: Mark Baugher <[email-masked]>
Date: Wed, 27 Jun 2001 16:00:51 -0700

Andrea
    I comment on your second point in this note.

>The architecture document is not an appropriate place for blatant 

Answered in previous posting.

>really demands a _security management_ protocol that can manage keys and 

There is nothing that you have written that is inconsistent with what we 
wrote except that you really cannot implement the stuff about read or write 
access when a symmetric key is used.  A group member who receives encrypted 
data can send it.  There could  be some policy processing at a host-member 
to throw away messages based on authenticating sources and we address this 
in the key management architecture.  You write above that it "...could also 
be enforced by signature keys" when in fact that's the only way it can be 
enforced (though TESLA-like solutions can reduce the costs of asymmetric 
crypto on a packet-by-packet basis).

You assert that a "key distribution protocol alone does not define a secure 
group" but this is a straw man:  The draft does not say it does.

Mark

---

From: Andrea Colegrove <[email-masked]>
Date: Wed, 27 Jun 2001 19:31:42 -0400

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

---

From: Andrea Colegrove <[email-masked]>
Date: Wed, 27 Jun 2001 19:42:35 -0400

Mark,
    Clearly sending and writing are different.  To write info to a group, possession of a symmetric authentication key may be required.
Yes, anyone can read it (if it isn't encrypted) and send it on, but only group members can generate authentic data and have it be accepted
by other group members.
    I would have been clearer had I said "a key management protocol alone does not grow secure groups -- security management is needed
because the issues needing management are larger than just the keys."

--- Andrea

---

From: Mark Baugher <[email-masked]>
Date: Wed, 27 Jun 2001 18:04:18 -0700

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
>     Many feel that modifications to a standard to support multicast is 
> not a good solution.   IKE is designed with certain assumptions which
>     Also, because SPD and SAD values for a group cannot be completely 
> determined in advance and are more likely distributed as part of the
>     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
>     Wrt GSAKMP and separating out the "key management protocol":  key 
> management involves more than distribution.
>
>--- Andrea
>
>
>
>Mark Baugher wrote:
>
> > Andrea
> > >><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
> > >>
> > >>

---

From: Mark Baugher <[email-masked]>
Date: Wed, 27 Jun 2001 20:18:15 -0700

At 07:42 PM 6/27/2001 -0400, Andrea Colegrove wrote:
>Mark,
>     Clearly sending and writing are different.  To write info to a group, 
> possession of a symmetric authentication key may be required.
>Yes, anyone can read it (if it isn't encrypted) and send it on, but only 
>group members can generate authentic data and have it be accepted
>by other group members.
>     I would have been clearer had I said "a key management protocol alone 
> does not grow secure groups -- security management is needed

That's a very good point.  I don't know what to do with it, however, since 
it's a point about something called "security management."  We're 
discussing key management in the I-D, not security management.  If someone 
were to write
an I-D about "group security management," then I'd take the time to read it.

Mark

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 28 Jun 2001 14:12:56 -0400

Hi,

I'd like to respond particulalry to Andrea's valid point:

At 6/27/2001||07:31 PM, Andrea Colegrove wrote:
   > Join/Registration process, IKE will not likely be automatically fired 
off
   > anyway (analogous to PPKs).

I have brought-up this point several times, namely, that if a newcomer
wishes to join a group, how does he/she find out about the necessary
parameters to talk to the GCKS or Key Server.

GDOI assumes that this information is outside GDOI itself (say within
a Group Security Policy Token).  GSAKMP pushes the Token down to the
newcomer after the newcomer has been authenticated and a secure channel
has been estabslished between the two.

Now, if we are talikng about Cat-1 SA (unicast) between a newcomer
and a member, then Andrea's statement is true (ie. SPD and SAD values
for a group cannot be completely determined in advance).
This is in fact the whole point of the Cat-1, as we all agree that
there no practical way to boot-up a group other than for each member
to establish a pairwise secure channel with the GCKS.

However, if we are talking about the Cat-2 SA (Key Update) and
Cat-3 SA (Data Security) -- both being IPsec SAs -- then
Andera's statement is not quite correct.  The IPsec Arch document "hints"
(within a couple of paragrahps) that for multicast the parameters
must be pre-determined.

thomas
------

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 28 Jun 2001 14:47:45 -0400

At 6/28/2001||11:31 AM, Mark Baugher wrote:
>Thomas,
>
>At 02:12 PM 6/28/2001 -0400, Thomas Hardjono wrote:
>>Hi,
>>
>>   > Join/Registration process, IKE will not likely be automatically 
>> fired off
>Consider a group of four members who trust each other not to
>impersonate another member.  When an IPsec ESP message is
>sent multicast from one to all of the members, each one could
>perform a Registration exchange (protected by a Cat-1 SA)
>with the sender if they don't already have an AH SA.  This may
>initialize a Rekey (Cat-2) SA for Re-key messages (indeed,
>all of this could have been initiated by the receipt of a Re-key
>message).  Or it might not use Re-key.
>
>Now, if the group is much larger than four...

This is why some group-policy information is needed (and a draft
on this is being worked-on now).

Also, in order to boot-strap the group, I cannot think of any other
way than to use certificates for initial user-authentication
with the GCKS.  I think GSAKMP does this, and IKE and so GDOI) allows
for this.  For small groups, then an ACL might work, but once
the group gets into the thousands, then ACLs may be too cumbersome.

>It doesn't matter whether the Cat-2 SA (Re-key not Key Update) is
>IPsec or not - it could be ISAKMP - we would not want to initiate
>a pairwise SA on receipt of a multicast message sent to a large
>group because that could cause implosion.  A better course
>might be to listen to the Re-key multicast address for the
>particular group and pick up the SA for the multicast message
>received.  No change is required to IPsec it is all done in
>IKE GDOI.

OK, I'm confused :)  Why would we want a newcomer to contact a GCKS
upon receiving a multicast message?  How does the newcomer pick-up
the SA when that SA is either not in the multicast message or is encrypted 
within the multicast message?

thomas
------

>How to do this is something I expect will be answered in the
>Policy draft.
>
>Best Regards, Mark
>
>
>>thomas
>>------
>>
>>
>>>     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
>>>off anyway (analogous to PPKs).
>>> > >><http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt> 
>>> h t tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt
>>> > >>
>>> > >>
>>> > >><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1 
>>> s h adow-sites.txt
>>> > >>
>>> > >>

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Thu, 28 Jun 2001 15:20:47 -0400

Some of the SAD or SPD information is pre-distributed and the
rest is sent via the registration protocol (some of it may be 
sent or updated via the rekey protocol).  The group owner 
decides (depending on the application) on which parts to 
pre-distribute. 

We went further and gave examples of pre-distributed information.
It goes without saying that if there is a problem about a
specific item in that list of pre-distributed information, please
let us know.  Thanks.

best regards,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Thu, 28 Jun 2001 12:24:22 -0700

>At 6/28/2001||11:31 AM, Mark Baugher wrote:

<text deleted>

>within the multicast message?

I wrote that the member would listen for Re-key messages.  I didn't
say anything about contacting the GCKS.  Here is a scenario:
A Quicktime media server multicasts a stream of packets to group A,
which shares KEK K.  That stream of packets is protected by TEK k.
While the Quicktime server sends the packets to one multicast transport
address, it periodically sends to another address the Re-key messages that
are protected by K and which contain k.  So the Quicktime server in this
example can periodically send K{k} with additional parameters such as
a cert that is signed by the GCKS authorizing it to send on behalf of
the GCKS (i.e., the GCKS issues a delegate cert to the Quicktime
server and the GCKS is authorized to do such delegation by the
Group Owner).

Mark

>>>> > >><http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt 
>>>> > >><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/ 
>>>> 1 s h adow-sites.txt
>>>> > >>
>>>> > >>

---

From: Andrea Colegrove <[email-masked]>
Date: Thu, 28 Jun 2001 16:50:44 -0400

Hi, Thomas,

> parameters to talk to the GCKS or Key Server.

The info can be in the announcement, it can be held generically in the IPSec SPD
(SAD values would need to be determined within the join/registration protocol, it
can be held by a future "policy server" or it can be strictly enforced by the GCKS
values in the SPD.

> (within a couple of paragrahps) that for multicast the parameters

Right.  These values can be passed down in the join process.  They must be
determined before the group is grown, however, (SPI values, keys, etc.)

Or am I misunderstanding you?  Sorry.

--- Andrea

---

From: Mark Baugher <[email-masked]>
Date: Thu, 28 Jun 2001 11:31:45 -0700

Thomas,

Best Regards, Mark

>> > >><http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt>h 
>> t tp://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt
>> > >>
>> > >>
>> > >><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1s 
>> h adow-sites.txt
>> > >>
>> > >>

---

From: Thomas Hardjono <[email-masked]>
Date: Thu, 28 Jun 2001 15:48:04 -0400

Mark,

Apologies.  I was referring to the bootstrap stage, in which case
the newcomer has no KEK, nor TEK.

Yes, once a member knows the KEK, it can listen to the Re-Key messages
and obtain new keying material (which is the purpose of Cat-2).

thomas
------

At 6/28/2001||12:24 PM, Mark Baugher wrote:
>>the SA when that SA is either not in the multicast message or is 
>>encrypted within the multicast message?
>
>>>>>     Many feel that modifications to a standard to support multicast 
>>>>> is not a good solution.   IKE is designed with certain assumptions which
>>>>>  >>>> > h t 
>>>>> > >><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf 
>>>>> / 1 s h adow-sites.txt
>>>>> > >>
>>>>> > >>