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

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

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

Mark,

> How about if we change the offending paragraph as follows:
> security services.  For these reasons, application, transport, and
> internetwork-layer security protocols such as SRTP, IPsec, and AMESP
> may benefit from using different group key management systems [GSAKMP,
> GDOI]. Extensions to IKE, however, are probably the best solution for
> IPsec protocols over IP multicast services [GDOI].  The purpose of
> this
>

Yes there is definitely the "one size fits all" vs. the per-security
application approach.  It is appropriate to state this in the intro.
Please just remove the opinion of what you feel is the best solution for
IPSec.

Group and multicast applications have diverse requirements in IP
networks [CP00].  Their key-management requirements, which are briefly
reviewed below (see "Requirements"), include support for internetwork,
transport, and application-layer protocols.  In particular, while
Internet-standard ISAKMP and IKE protocols purport to manage keys for
any and all services in a host, some applications may achieve simpler
operation by running key-management messaging over TLS or IPsec
security services.  For these reasons, application, transport, and
internetwork-layer security protocols such as SRTP, IPsec, and AMESP
may benefit from using different group key management systems. The
purpose of this document is to define a common architecture and design
for these different group key-management protocols.

>  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.
>
> I'm looking forward to the I-D on security management protocols and prefer to stick to key management protocols in this I-D
>
The statement above is incorrect however.  It is only though key
management in conjuction with security association management, access
control, and authorization (i.e., security management) that ensures this
property.  (KM is probably necessary but not sufficient, etc, etc.)

>> > 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.
>
>
> Would you please provide references for these attacks?
>

Sure.  For starters check Clark and Jacob's "Security Protocols:  An
Annotated Bibliography", Abadi and Needham's"Prudent Engineering
Practice for Cryptographic Protocol", Ulf Carlsen's "Cryptographic
Protocol Flaws."  Ross Anderson also has a good paper that applies to
public key protocols and Schneier (and Wagner?) have one on
multiprotocol attacks.

My point was only that it might be better to generalize than to list.

>> 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."
>
>
> Not in IKE it isn't.  Again, I await the I-D on the security
> management protocol.
>

IKE says:
A security association (SA) is a set of policy and key(s) used to
protect information. The ISAKMP
    SA is the shared policy and key(s) used by the negotiating peers in
this protocol to protect their
    communication.

Access control and delegation are two of the assumptions that pairwise
communication does not need to consider:  You know who you are going to
talk to (your peer), you will only communicate if both your policies
(SPDs) allow it, and you figure that they are authorized to negotiate on
behalf of themselves.

There is a lot of policy involved in IKE.  The rest of the security
association is certainly not just 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.
>
>
> What is the property that would be destroyed?  What exactly is the
> problem?
>
>

The example wasn't clear to me but it appeared that you were stating
that the potential audience was a group and requirement 6 (rekey)
supported the access control to video broadcasts.  If this is what you
meant, then each time some of the members were excluded from a
broadcast, a smaller potential audience resulted for the next one.

>
>
>> 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.
>
"But for large,
single-
source multicast groups, it is generally undesirable to distribute key
management functions among group members"

Please support this with evidence.  Also, wouldn't it be best to just
discuss the requirements and design constraints but not suggest
solutions here?

>> 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.
>
>
> The architecture recommends that this be done by allowing any key
> server to serve keys that is authorized to do so by the group owner.
> The most straightforward way to do this is to use SPKI or X.509
> delegation.  That's what we are recommending rather than coding this
> up in the key management protocol.
>

It is fair to say that the key server must provide proof of delegation.
I _believe_ SPKI (SDSI) delegation is not widely used, but cannot
support this.  X. 509 attributes is a fair way of doing this, but is
only one way.  Whether it is more straightforward is a matter of
opinion.

>> 9.  Section 3.2 -- The term TEK is inappropriately specific.  The
>> group may not have encryption requirements, but only authentication.
>
>
> TEK has a long history in the group key management literature.  But
> you have a point, it may not be needed for authentication.  We need to
> review this.
>

TEK = Traffic ENCRYPTION Key.  And yes, this term goes back way before
open literature even.

>> 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.
>
>
> Comment #6 was citing a requirements discussion.  now we are into
> design.  There are ways to load balance, get high-availability, and
> get fault tolerance for a server without inventing distributed key
> server protocols (such as a leader election algorithm, inter-KDC
> protocols).
>
>

Okay.  The design is inconsistent with the requirement?
Load sharing is certainly different than delegation -- I am not sure
what your point is.

>
>
>> 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.
>
>
> These assumptions were put into the GDOI draft at Hugh's behest and it
> helped clarify our thinking on how to minimize group policy functions
> in key management.   I recommended to Ran and Lakshminath that we
> consider including these assumptions in the GKM architecture I-D.
> They agreed and Lakshminath did that.  If we don't do that, then we
> will encumber the key management specification with a lot of policy
> issues that the working group has agreed belonged in a policy draft.
> You may not agree with everything the WG decides to do.  WGs are like
> that.
>

Oh are you the working group?
Just because it is an appropriate assumption for GDOI does make it
appropriate for all.

>
>
>>     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.
>
>
> We're not shooting for novelty here.  Quite the contrary.  The I-D is
> to progress as a product of the msec WG in order to bring two or more
> key management protocols to address common requirements, use common
> abstractions, and messages.  These two or more protocols cannot
> interoperate unless they at least use a common header.  GDOI uses an
> ISAKMP header for obvious reasons.  GSAKMP does not use an ISAKMP
> header. If they could interoperate, then we would not go to the
> trouble of specifying two or more key management protocols.
>

The requirements need to drive the protocol selection not the other way
around.
Common abstractions are good, common messages imply a common protocol.

--- Andrea