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

From: [email-masked]
Date: Wed, 27 Jun 2001 07:03:10 -0400

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

---

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

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

[email-masked] wrote:

>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

---

From: Mark Baugher <[email-masked]>
Date: Wed, 27 Jun 2001 22:17:01 -0700

Andrea
    I'll work through the points and suggest possible compromises to 
address your concerns.

>The architecture document is not an appropriate place for blatant 

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

>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 

I'm looking forward to the I-D on security management protocols and prefer 
to stick to key management protocols in this I-D

>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?

>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.

>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?

>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.

Please refer to the following sections of draft-ietf-msec-gkmarch-00.txt: 
Section 3.2, Detailed Design, where we discuss delegation; Section 3.3, 
Properties of the Design; Section 3.4, first paragraph where the word 
"delegation" appears; 4.1, Predistributed Group Policy where we discuss 
delegation;  and Section 5.0, Scalability Considerations.  You are citing 
the Requirements discussion and not the Design features proposed in our draft.

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

This is discussed in the I-D under Section 5.0.

>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.
>>
>>
>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.

>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.

>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.

That sounds okay to me.

>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).

>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.

>     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.
>     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.

Mark

>><http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt>http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-00.txt 
>>
>>
>><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 
>>
>>

---

From: Mark Baugher <[email-masked]>
Date: Thu, 28 Jun 2001 14:03:13 -0700

At 04:14 PM 6/28/2001 -0400, Andrea Colegrove wrote:
>Mark,
>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.

I'd like to hear what others from msec have to say about this first because I
can think of a few reasons why a WG would standardize two or more
protocols that do the same thing.

1. We are muddleheads
2. We are in a political stalemate and making compromises
3. We have specific uses in mind for each

I like to think that we're in point 3 space and should state what the specific
uses are.  At the grossest level, GSAKMP runs over IPsec or other data
security protocol and GDOI is strictly an extension to IKE.  So if you
want to use a single key-management protocol implementation for
IPsec, then GDOI is probably the best solution.  If you want to run over
IPsec or SSL, then GSAKMP is the solution. This is why we are
working to standardize two things rather than one.  It might be that
neither GSAKMP or GDOI are suitable for certain group security
applications such as VoIP and we may end up doing a third.
The paragraph above says something about the msec group key
management protocols that we are developing.

Mark

>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
>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
>>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.)
>>>>
>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.
>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.
>>
>>
>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
>>>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-
>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.
>>>>
>>>>
>>>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.
>TEK = Traffic ENCRYPTION Key.  And yes, this term goes back way before 
>open literature even.
>>>11.
>>>>
>>>>
>>>>operation of the
>>>>KDC.
>>>This statement, while correct, seems to conflict with the statement 
>>>quoted in Comment #6.
>>
>>
>Okay.  The design is inconsistent with the requirement?
>Load sharing is certainly different than delegation -- I am not sure what 
>your point is.
>>
>>>12.
>>>>
>>>>
>>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.
>>
>>> 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.
>>> 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.
>>>
>>>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.
>>
>>
>>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

---

From: Mark Baugher <[email-masked]>
Date: Thu, 28 Jun 2001 14:41:35 -0700

Andrea
   Still working through your points...

>property.  (KM is probably necessary but not sufficient, etc, etc.)

Like I said, you are invoking something that is not defined in the msec 
context:  Please write an I-D on security management or security 
association management so we have something to discuss here.  Writing "etc, 
etc" isn't much help, either.

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

thanks.  I took this from the IKE, ISAKMP, Photuris, and STS papers as 
being the basic protections needed for key management and each are 
generalized types of attacks, like man-in-the-middle since there are a 
number of things that a man-in-the-middle might do.

> this protocol to protect their

That's right and the policy is carried in the SA payload.

>(SPDs) allow it, and you figure that they are authorized to negotiate on 

What's the point?

>potential audience resulted for the next one.

I don't understand.

>discuss the requirements and design constraints but not suggest solutions 

DirecTV is a good example. TV conditional access systems don't allow STBs 
to become group controllers.  The need to support large numbers of 
receivers, or to quickly remove members, or to have very short latency in 
joining or re-keying a group are the requirements and design 
constraints.  We have commercial systems that optimize for a subset of 
these constraints and some of the others listed in Section 2.

>way.  Whether it is more straightforward is a matter of opinion.

Please tell me why SPKI delegation will not do this.  I believe it can.  If 
we need to fix something in the trust infrastructure, I would not build the 
solution into the key management protocol but fix the trust 
infrastructure.  Otherwise the key management protocol will end up having 
all sorts of strange and inappropriate features that make it difficult to 
implement and impossible to test.

>Load sharing is certainly different than delegation -- I am not sure what 

Section 2, requirements, referred to a general taxonomy or framework and 
past work such as RFC2627 and OFT.  We gathered and summarized the 
requirements in section 2.  The design is to be measured against the very 
general requirement and we said, first and foremost, that we must support 
source-specific multicast.  Developing a "distributed design" where each 
member could be a controller is not necessary for the basic requirement of 
source-specific multicast.  But we must support large-scale 
operation.  There are ways such as load balancing, high-availability, and 
fault-tolerant methods to do that but we still do not have a distributed 
key server in my opinion but a load-balanced or highly-available or 
fault-tolerant centralized server.  On the other hand, there is delegation 
and this allows other device to source keys on behalf of the key server.  I 
particularly like the idea of allowing the media server to be delegated to 
send out keys (SAs) for data-security protocols on behalf of the key 
server.  But we still do not have a distributed key server in that not all 
members need to have the capability to be key servers.  Section 5 of the 
I-D also notes that the fly-in-the-ointment might be the need to develop an 
inter-KDC protocol to make this work.  I don't think it is necessary, but 
we need to look closely at this assumption.

>Oh are you the working group?

There you go again.  We hold meetings and post minutes.  Please refer to them.

>Common abstractions are good, common messages imply a common protocol.

Not if you want GSAKMP to use a non-standard header.  We can specify common 
messages for the Re-key protocol up to the header.  At that point GSAKMP 
and GDOI part ways.

Mark

---

From: Andrea Colegrove <[email-masked]>
Date: Thu, 28 Jun 2001 18:43:00 -0400

Mark,

>> >     to group keys) and can authenticate group
>> >
>> > data.
>> >
>> >
>>
>> >
>> >
>> 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.)
>
>
> Like I said, you are invoking something that is not defined in the
> msec context:  Please write an I-D on security management or security
> association management so we have something to discuss here.  Writing
> "etc, etc" isn't much help, either.

How about

"A group key management protocol helps to ensure that only members of a secure group

gain access to group data (by gaining access to group keys) and can authenticate

group data."

What you have currently is wrong.  Key management is a necessary but not sufficient

service.  Is this clearer?

>
>
>
>> >> > 4.
>> >> > The key-management protocol must be secure against man-in-the-
>> >> >    middle, connection-hijacking, and reflection/replay
>> >> > attacks;
>> >> > it must
>> >>  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.
>> >
>> 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.
>>

I understand -- there are others that cannot be generalized quite as
well, such as protocol-oracle which is not really a man-in-the-middle
and not really a replay since it is used in another protocol.  We just
don't want one to slip through the requirements cracks.  How about "The
key management protocols must be secure against protocol attacks against
the provided security services and must use best ..."

>
>
>> >>  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.
>
>

so?

>
>
>
>> 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.
>
>
> What's the point?
>
>
>

The point is "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.
>> >
>> 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.
>
>
> I don't understand.

I am trying to restate what I think you said and you don't understand.
Could you restate the example so that we can determine whether there is
a limitation or not?  Thanks.

>> Please support this with evidence.  Also, wouldn't it be best to
>> just discuss the requirements and design constraints but not suggest
>> solutions here?
>
>
> DirecTV is a good example. TV conditional access systems don't allow
> STBs to become group controllers.  The need to support large numbers
> of receivers, or to quickly remove members, or to have very short
> latency in joining or re-keying a group are the requirements and
> design constraints.  We have commercial systems that optimize for a
> subset of these constraints and some of the others listed in Section
> 2.
>

I don't think that this is a general example.  If this were for the
internet, what is wrong with saying address a.b.c.d or a.b.c.e or
a.b.c.f can serve you?  (Any key server that "sees" unencrypted keys is
by default a member.)

>> >>  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.
>
>
> Please tell me why SPKI delegation will not do this.  I believe it
> can.  If we need to fix something in the trust infrastructure, I would
> not build the solution into the key management protocol but fix the
> trust infrastructure.  Otherwise the key management protocol will end
> up having all sorts of strange and inappropriate features that make it
> difficult to implement and impossible to test.
>

My typo again.  SPKI delegation is not widely used but can support
this.  The X.509 is available.  It is a mechanism that provides some
proof of authorization.  For example in GSAKMP, it can be one of the
certificates passed with the INVITATION message with the token
containing the rule for key server of "attribute certificate signed by
root x".  Or alternatively, not using attribute certificates, it can
just be a key server rule that says it must have an "identity cert
signed by root y where the identity conforms to the rule name =
a.b.c.?".  I don't think that this is a strange and inappropriate
feature.

>> >>  This statement, while correct, seems to conflict with the
>> >>  statement quoted in Comment #6.
>> >
>> > 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).
>> >
>>
>> Load sharing is certainly different than delegation -- I am not sure
>> what your point is.
>
>
> Section 2, requirements, referred to a general taxonomy or framework
> and past work such as RFC2627 and OFT.  We gathered and summarized the
> requirements in section 2.  The design is to be measured against the
> very general requirement and we said, first and foremost, that we must
> support source-specific multicast.  Developing a "distributed design"
> where each member could be a controller is not necessary for the basic
> requirement of source-specific multicast.  But we must support
> large-scale operation.  There are ways such as load balancing,
> high-availability, and fault-tolerant methods to do that but we still
> do not have a distributed key server in my opinion but a load-balanced
> or highly-available or fault-tolerant centralized server.  On the
> other hand, there is delegation and this allows other device to source
> keys on behalf of the key server.  I particularly like the idea of
> allowing the media server to be delegated to send out keys (SAs) for
> data-security protocols on behalf of the key server.  But we still do
> not have a distributed key server in that not all members need to have
> the capability to be key servers.  Section 5 of the I-D also notes
> that the fly-in-the-ointment might be the need to develop an inter-KDC
> protocol to make this work.  I don't think it is necessary, but we
> need to look closely at this assumption.
>

I don't think distributed means all members need to have the capability
to be key servers.

"Developing a "distributed design" where each member could be a
controller is not necessary for the basic requirement of source-specific
multicast. " is not the same as "it is generally undesirable to
distribute key management functions among group members".

Don't make distributed key management functions a requirement, but
certainly do not preclude it or discourage it.

>> > 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

Believe me I do.

Separating policy specifics into a separate draft is very different from
saying that the list of policy elements above is assumed to be managed
externally from the key management protocol.  Distribution is a part of
management.  Policy elements MAY be managed externally.  Please stop
twisting the issues.

>> > 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.
> Not if you want GSAKMP to use a non-standard header.  We can specify
> common messages for the Re-key protocol up to the header.  At that
> point GSAKMP and GDOI part ways.

You missed my point.  Different protocols use different messages.

I think Ran's message was pretty clear about the requirements and
abstractions.  Why would the messages be the same?

--- Andrea

---

From: Mark Baugher <[email-masked]>
Date: Thu, 28 Jun 2001 17:41:27 -0700

>gain access to group data (by gaining access to group keys) and can 

Fine.  I'm okay making this change to the next version of the draft.

>service.  Is this clearer?

I've developed product for this market and I disagree that what we said is 
wrong, but it's not worth debating.

I'll address the rest of this note later tonight or tomorrow.

Mark

>>>Protocol Flaws."  Ross Anderson also has a good paper that applies to 
>>>public key protocols and Schneier (and Wagner?) have one on 
>>>multiprotocol attacks.
>>>
>I understand -- there are others that cannot be generalized quite as well, 
>such as protocol-oracle which is not really a man-in-the-middle and not 
>really a replay since it is used in another protocol.  We just don't want 
>one to slip through the requirements cracks.  How about "The key 
>management protocols must be secure against protocol attacks against the 
>provided security services and must use best ..."
>
>>
>>>>>POLICY.  Policy is _so_ much more than "meta-data describing the keys."
>>>>
>security association is certainly not just meta-data describing the keys. "
>>>
>>>supported the access control to video broadcasts.  If this is what you 
>>>meant, then each time some of the members were excluded from a 
>I am trying to restate what I think you said and you don't 
>understand.  Could you restate the example so that we can determine 
>whether there is a limitation or not?  Thanks.
>>
>>>>
>>>>>6.
>>>>>>
>>>>>>
>>>>>>A centralized
>>>discuss the requirements and design constraints but not suggest solutions here?
>>
>>
>internet, what is wrong with saying address a.b.c.d or a.b.c.e or a.b.c.f 
>can serve you?  (Any key server that "sees" unencrypted keys is by default 
>a member.)
>>
>>>>>8.
>>>>>>
>>>>>>
>>>>owner.  The most straightforward way to do this is to use SPKI or X.509 
>>>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.
>>
>>
>>not build the solution into the key management protocol but fix the trust 
>this.  The X.509 is available.  It is a mechanism that provides some proof 
>of authorization.  For example in GSAKMP, it can be one of the 
>certificates passed with the INVITATION message with the token containing 
>the rule for key server of "attribute certificate signed by root x".  Or 
>alternatively, not using attribute certificates, it can just be a key 
>server rule that says it must have an "identity cert signed by root y 
>where the identity conforms to the rule name = a.b.c.?".  I don't think 
>that this is a strange and inappropriate feature.
>>>>>>
>>member could be a controller is not necessary for the basic requirement 
>>of source-specific multicast.  But we must support large-scale 
>>fault-tolerant centralized server.  On the other hand, there is 
>>delegation and this allows other device to source keys on behalf of the 
>>key server.  I particularly like the idea of allowing the media server to 
>>be delegated to send out keys (SAs) for data-security protocols on behalf 
>>of the key server.  But we still do not have a distributed key server in 
>>that not all members need to have the capability to be key 
>>servers.  Section 5 of the I-D also notes that the fly-in-the-ointment 
>>might be the need to develop an inter-KDC protocol to make this work.  I 
>>don't think it is necessary, but we need to look closely at this assumption.
>>
>I don't think distributed means all members need to have the capability to 
>be key servers.
>
>"Developing a "distributed design" where each member could be a controller 
>is not necessary for the basic requirement of source-specific multicast. " 
>is not the same as "it is generally undesirable to distribute key 
>management functions among group members".
>
>>>>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.
>>>>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 
>>>>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.
>>common messages for the Re-key protocol up to the header.  At that point 
>>GSAKMP and GDOI part ways.

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 29 Jun 2001 10:10:45 -0400

Hi,

I'm going to respond to one issue at a time.

>complicated, this functionality may be needed in composite multicast 

The paragraph about the scalability of key management in the arch-document is
rather unclear.

We definitely need more than one GCKS in order for key management to scale.
This is what my earlier draft (draft-ietf-ipsec-gkmframework-03.txt) was
about, namely having a two-layer set of GCKSs.

The issue is whether a Remote GCKS is :

(a) a "permanent" GCKS (ie. a full-time configured key server) that is
      functionally identical to the "root" GCKS and is *NOT* a group member,

or

(b) a member that is loaded with a GCKS-functionality, and that can be
     called-up for duty when scalability/reliability needs arise.

Now, (a) is a natural usage of multiple GCKS.  The two-tiered architecture
of Key Servers (as described in draft-ietf-ipsec-gkmframework-03.txt)
follows other 2-tiered services in the Internet.

Option (b) is a more dynamic approach, which requires a member to be trusted
and have a high-degree of security against attacks.

This issue has to be clarified as clearly 1 GCKS is not going to scale,
and a member-convertible-to-GCKS is not a attainable today
in the vendor market.

thomas
------

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

---

From: Mark Baugher <[email-masked]>
Date: Fri, 29 Jun 2001 07:44:11 -0700

>security association is certainly not just meta-data describing the keys. "

No, I'd say most of the policy in IKE is crypto policy.  Now, one of us is 
going to have to list all the policy in IKE and debate the topic.  Or we 
could just drop it.

>whether there is a limitation or not?  Thanks.

There is a group that can receive video on demand (VOD) content where each 
member contacts the VOD server to get a file or stream.  It is not a 
broadcast; it is on demand.  The VOD server is authorized to source Re-key 
messages on behalf of the GCKS.  So when the member gets the file or stream 
data, it can get the key to decipher the file or stream from the VOD server.

>can serve you?  (Any key server that "sees" unencrypted keys is by default 

I'm sorry you don't like my example.

>that this is a strange and inappropriate feature.

Why put the feature in key management when it is done somewhere else?

>certainly do not preclude it or discourage it.

I agree.  I think we should re-work the parts on centralized and 
distributed key management in the I-D.

>abstractions.  Why would the messages be the same?

I did not say they were the same.

Mark

---

From: Mark Baugher <[email-masked]>
Date: Fri, 29 Jun 2001 07:53:41 -0700

Thomas,

>and a member-convertible-to-GCKS is not a attainable today

I didn't say that a centralized configuration has only one GCKS.
There could be many servers sharing a single address behind a load
balancer.  The discussion on large-scale operation in the I-D
did not equate "centralized" with "one."

Mark

---

From: Andrea Colegrove <[email-masked]>
Date: Fri, 29 Jun 2001 11:19:40 -0400

Mark,
    We are not going to agree whether or not crypto policy is meta-data
or not.  Fine.  My reason for pointing out that most of the requirements
listed involved more than just key management was to show that you are
well on your way to providing a security management internet draft.

>> >>  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.
>> >
>> > I don't understand.
>>
> There is a group that can receive video on demand (VOD) content where
> each member contacts the VOD server to get a file or stream.  It is
> not a broadcast; it is on demand.  The VOD server is authorized to
> source Re-key messages on behalf of the GCKS.  So when the member gets
> the file or stream data, it can get the key to decipher the file or
> stream from the VOD server.
>

Okay.  So far I understand.  Could you please fill in the details
because I don't see the rekey aspect?
The member, before requesting the video is initialized with what?
Are all members initialized to the same values?
Is the stream encrypted per-member or per-group?

>> >> >>  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-
>> >>  just discuss the requirements and design constraints but not
>> >>  suggest solutions here?
>> >
>> > DirecTV is a good example. TV conditional access systems don't
>> > allow STBs to become group controllers.  The need to support large
>> > numbers of receivers, or to quickly remove members, or to have very
>> > short latency in joining or re-keying a group are the requirements
>> > and design constraints.  We have commercial systems that optimize
>> > for a subset of these constraints and some of the others listed in
>> > Section 2.
>>
>> a.b.c.f can serve you?  (Any key server that "sees" unencrypted keys
>> is by default a member.)
>
>

Once again this isn't the point.  There are examples in which it may be
specifically inadvisable to distribute key management functions down,
but why is it GENERALLY inadvisable to distribute key management
functions down?

>> >> >>  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.
>> >>
>> >>  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.
>> >
>> > can.  If we need to fix something in the trust infrastructure, I
>> > would not build the solution into the key management protocol but
>> > fix the trust infrastructure.  Otherwise the key management
>> > protocol will end up having all sorts of strange and inappropriate
>> > features that make it difficult to implement and impossible to
>> > test.
>>
>> containing the rule for key server of "attribute certificate signed
>> by root x".  Or alternatively, not using attribute certificates, it
>> can just be a key server rule that says it must have an "identity
>> cert signed by root y where the identity conforms to the rule name =

Just as the details of certificates are not specified in key management
protocols, the details of of policy do not need to by specified here.
However, certificates are needed to make many of the protocols secure.
So, too, with policy.  It may be (it is) necessary to deal with policy
in order to make the km protocol secure.  Thus, it does need to be dealt
with to some extent.

The actual form that the policy takes -- policy tokens, attribute certs,
whatever -- is not critical here.  It is a choice of the individual
protocols.  Saying that the architecture ASSUMES everything is obtained
externally is inappropriate. It does not have to be.  Imposing
unnecessary requirements and assumptions unduly restricts protocol
design.

What is important though, is that each of the protocols is given the
info that it needs to operate securely.  Somehow, from somewhere.

--- Andrea

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Fri, 29 Jun 2001 11:39:36 -0400

During our discussions the following also came up:

1.  We could have several registration "servers" and a prospective
member could go to any one of them for registration.  (I believe this 
has been mentioned in the literature)

2.  Rekey servers could be different from registration servers and
may be replicated.

Of course, there are issues in synchronizing SA information between
these servers.  But, I believe this models the real world in some
sense (people go to box offices across the country to buy tickets 
for sporting events etc.).

cheers,
Lakshminath

---

From: Mark Baugher <[email-masked]>
Date: Fri, 29 Jun 2001 09:21:23 -0700

Andrea,

> well on your way to providing a security management internet draft.

We don't have anything called a "security management draft" on the 
roadmap.   If I felt as strongly about this as you do, I would commence 
working on the draft.  The first thing you need to do is define what it 
is.  But holding up a key management I-D and criticizing it for not being a 
security management draft, which is right now only a buzz-phrase and 
nothing else, is not helpful.

Here is my understanding of what consensus the WG has reached.  The WG is 
to do a multicast security architecture draft, a group key management 
architecture draft, probably two key management protocols (one for IKE and 
one for IPsec), a data transforms draft, and a policy draft.  The latter 
will then cause us to consider changes or additions that need to be made in 
other drafts to accommodate policy, which is the least well defined thing 
we are doing.

>>each member contacts the VOD server to get a file or stream.  It is not a 
>>broadcast; it is on demand.  The VOD server is authorized to source 
>>Re-key messages on behalf of the GCKS.  So when the member gets the file 
>>or stream data, it can get the key to decipher the file or stream from 
>>the VOD server.
>>
>Okay.  So far I understand.  Could you please fill in the details because 
>I don't see the rekey aspect?

Each member of the particular VOD service has gotten the group KEK as a 
Re-key SA.  This answers your first two questions.  The stream is encrypted 
with a TEK for a data security SA in this particular example; the TEK with 
data security SA is sent in RE-key messages to the member.  It is not 
per-member.  The point here is that group keys are used for unicast streams 
or file download.

>>>>STBs to become group controllers.  The need to support large numbers of 
>>>>receivers, or to quickly remove members, or to have very short latency 
>>>>in joining or re-keying a group are the requirements and design 
>specifically inadvisable to distribute key management functions down, but 
>why is it GENERALLY inadvisable to distribute key management functions down?

I don't know what "distribute key management functions down" means.

>>>>>>X.509 delegation.  That's what we are recommending rather than coding 
>>>>>>this up in the key management protocol.
>>>a.b.c.?".  I don't think that this is a strange and inappropriate feature.
>>
>>
>protocols, the details of of policy do not need to by specified 
>here.  However, certificates are needed to make many of the protocols 
>secure.  So, too, with policy.  It may be (it is) necessary to deal with 
>policy in order to make the km protocol secure.  Thus, it does need to be 
>dealt with to some extent.
>
>externally is inappropriate. It does not have to be.  Imposing unnecessary 
>requirements and assumptions unduly restricts protocol design.
>
>What is important though, is that each of the protocols is given the info 
>that it needs to operate securely.  Somehow, from somewhere.

I think I agree with this.

Mark

---

From: Andrea Colegrove <[email-masked]>
Date: Fri, 29 Jun 2001 13:12:14 -0400

Mark,
    People who have been working in security for a while do not consider
"security management" to be just a buzz word.

--- Andrea

Mark Baugher wrote:

>>     We are not going to agree whether or not crypto policy is
>> meta-data or not.  Fine.  My reason for pointing out that most of
>> the requirements listed involved more than just key management was
>> to show that you are well on your way to providing a security
>> management internet draft.
>
>
> roadmap.   If I felt as strongly about this as you do, I would
> commence working on the draft.  The first thing you need to do is
> define what it is.  But holding up a key management I-D and
> criticizing it for not being a security management draft, which is
> right now only a buzz-phrase and nothing else, is not helpful.
>
> Here is my understanding of what consensus the WG has reached.  The WG
> is to do a multicast security architecture draft, a group key
> management architecture draft, probably two key management protocols
> (one for IKE and one for IPsec), a data transforms draft, and a policy
> draft.  The latter will then cause us to consider changes or additions
> that need to be made in other drafts to accommodate policy, which is
> the least well defined thing we are doing.
>
>
>> >> >>  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
>> >>  understand.  Could you restate the example so that we can
>> >>  determine whether there is a limitation or not?  Thanks.
>> >
>> > There is a group that can receive video on demand (VOD) content
>> > where each member contacts the VOD server to get a file or stream.
>> > It is not a broadcast; it is on demand.  The VOD server is
>> > authorized to source Re-key messages on behalf of the GCKS.  So
>> > when the member gets the file or stream data, it can get the key to
>> > decipher the file or stream from the VOD server.
>>
> Each member of the particular VOD service has gotten the group KEK as
> a Re-key SA.  This answers your first two questions.  The stream is
> encrypted with a TEK for a data security SA in this particular
> example; the TEK with data security SA is sent in RE-key messages to
> the member.  It is not per-member.  The point here is that group keys
> are used for unicast streams or file download.
>
>
>> >
>> >
>> >> >
>> >> >
>> >> >> >
>> >> >> >
>> >> >> > > 6.
>> >> >> > >
>> >> >> > >>
>> >> >> > >>
>> >> >> > >>
>> >> >> > >>  A centralized
>> >> >> > > 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-
>> >> >>  Please support this with evidence.  Also, wouldn't it be best
>> >> >>  to just discuss the requirements and design constraints but
>> >> >>  not suggest solutions here?
>> >> >
>> >> >
>> >> > allow STBs to become group controllers.  The need to support
>> >> > large numbers of receivers, or to quickly remove members, or to
>> >> > have very short latency in joining or re-keying a group are the
>> >> > requirements and design constraints.  We have commercial
>> >> > systems that optimize for a subset of these constraints and
>> >> > some of the others listed in Section 2.
>> >>
>> >>  I don't think that this is a general example.  If this were for
>> >>  the internet, what is wrong with saying address a.b.c.d or
>> >>  a.b.c.e or a.b.c.f can serve you?  (Any key server that "sees"
>> >>  unencrypted keys is by default a member.)
>> >
>> Once again this isn't the point.  There are examples in which it may
>> be specifically inadvisable to distribute key management functions
>> down, but why is it GENERALLY inadvisable to distribute key
>> management functions down?
>
>
>> >> >> > 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.
>> >> >>
>> >> >>  used, but cannot support this.  X. 509 attributes is a fair
>> >> >>  way of doing this, but is only one way.  Whether it is more
>> >> > Please tell me why SPKI delegation will not do this.  I believe
>> >> > it can.  If we need to fix something in the trust
>> >> > infrastructure, I would not build the solution into the key
>> >> > management protocol but fix the trust infrastructure.
>> >> > Otherwise the key management protocol will end up having all
>> >> > sorts of strange and inappropriate features that make it
>> >>  My typo again.  SPKI delegation is not widely used but can
>> >>  support this.  The X.509 is available.  It is a mechanism that
>> >>  provides some proof of authorization.  For example in GSAKMP, it
>> >>  can be one of the certificates passed with the INVITATION message
>> >>  with the token containing the rule for key server of "attribute
>> >>  certificate signed by root x".  Or alternatively, not using
>> >>  attribute certificates, it can just be a key server rule that
>> >>  says it must have an "identity cert signed by root y where the
>> >>  identity conforms to the rule name = a.b.c.?".  I don't think
>> Just as the details of certificates are not specified in key
>> management protocols, the details of of policy do not need to by
>> specified here.  However, certificates are needed to make many of
>> the protocols secure.  So, too, with policy.  It may be (it is)
>> necessary to deal with policy in order to make the km protocol
>> secure.  Thus, it does need to be dealt with to some extent.
>>
>> The actual form that the policy takes -- policy tokens, attribute
>> certs, whatever -- is not critical here.  It is a choice of the
>> individual protocols.  Saying that the architecture ASSUMES
>> everything is obtained externally is inappropriate. It does not have
>> to be.  Imposing unnecessary requirements and assumptions unduly
>> restricts protocol design.
>>

---

From: Mark Baugher <[email-masked]>
Date: Fri, 29 Jun 2001 10:39:41 -0700

Andrea
    I don't know how Thomas and Ran feel about this, but I hope you give 
msec the benefit of your experience by writing a security management 
architecture I-D for msec - if you feel it's ready for the IETF standards 
process.

thanks, Mark
At 01:12 PM 6/29/2001 -0400, Andrea Colegrove wrote:
>>> or not.  Fine.  My reason for pointing out that most of the 
>>> requirements listed involved more than just key management was to show 
>>> that you are well on your way to providing a security management 
>>> internet draft.
>>
>>
>>is.  But holding up a key management I-D and criticizing it for not being 
>>a security management draft, which is right now only a buzz-phrase and 
>>architecture draft, probably two key management protocols (one for IKE 
>>and one for IPsec), a data transforms draft, and a policy draft.  The 
>>latter will then cause us to consider changes or additions that need to 
>>be made in other drafts to accommodate policy, which is the least well 
>>defined thing we are doing.
>>
>>>>each member contacts the VOD server to get a file or stream.  It is not 
>>>>a broadcast; it is on demand.  The VOD server is authorized to source 
>>>>Re-key messages on behalf of the GCKS.  So when the member gets the 
>>>>file or stream data, it can get the key to decipher the file or stream 
>>>>from the VOD server.
>>Re-key SA.  This answers your first two questions.  The stream is 
>>encrypted with a TEK for a data security SA in this particular example; 
>>the TEK with data security SA is sent in RE-key messages to the 
>>member.  It is not per-member.  The point here is that group keys are 
>>used for unicast streams or file download.
>>
>>>>
>>>>>>
>>>>>>>>
>>>>>>>>>6.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>A centralized
>>>>>>subset of these constraints and some of the others listed in Section 2.
>>>>>>would not build the solution into the key management protocol but fix 
>>>>>>the trust infrastructure.  Otherwise the key management protocol will 
>>>>>>end up having all sorts of strange and inappropriate features that 
>>>>>>make it difficult to implement and impossible to test.
>>>policy in order to make the km protocol secure.  Thus, it does need to 
>>>be dealt with to some extent.
>>>
>>>unnecessary requirements and assumptions unduly restricts protocol design.
>>>

---

From: "Sandro Rafaeli" <[email-masked]>
Date: Fri, 29 Jun 2001 21:43:13 +0100

I'd like to make some comments on the gkmarch I-D:

-- requirement 6 states:
   "It must be possible to provide re-key for the group without
   requiring unicast exchange between a key distribution center (KDC)
   and individual members, which would overwhelm a KDC when the group
   is large."

It sounds to me as if unicast messages during rekey must be avoided at all
costs!! Several HBT protocols employ a unicast message to update single
members during join operations. This is later noted in section 3.1 ((2)
Re-key protocol): "The Re-key messages can be sent multicast to group
members or unicast from the KDC to a particular group member.".

-- page 7 second paragraph "The Re-key protocol SHOULD ensure that all
members receive the re-key information in a timely manner....":

I undestand that the key management protocol does not have to provide
reliability itself, so I think that this phrase is erroneous. Wouldn't it be
more correct to say: "The Re-key protocol SHOULD be run over a reliable
transport protocol to ensure that all members receive the re-key..."?

-- page 7 "o If the KDC uses Re-key messages, then the admitted member
receives the Group KEK; if it uses a membership management algorithm, then
the member receives a set of KEKs according to the particular algorithm."

I am not familiar with MSEC's terminology, but I understand that membership
management algorithms also use "Rekey messages" to rekey members. In this
paragraph, the term "re-key messages" gave me the impression that those
messages only convey a single Group KEK.

In addition, the acronym GCKS was never defined in that document! I founf
the definition in the GDOI draft :)

Regards,
Sandro.

---

From: "Lakshminath Dondeti" <[email-masked]>
Date: Fri, 29 Jun 2001 17:16:23 -0400

Hi,

Thanks for your comments.  Please see inline:

> transport protocol to ensure that all members receive the re-key..."?

In fact, it should be possible to do both, i.e., sending rekey
messages over a reliable channel or use FEC or other techniques
for built in reliability.

> messages only convey a single Group KEK.

We will rewrite this!

> the definition in the GDOI draft :)

We tried hard to avoid the word GCKS and instead use KDC.  You
found the only occurrence :)

Thanks again.

regards,
Lakshminath

---

From: Thomas Hardjono <[email-masked]>
Date: Fri, 29 Jun 2001 17:15:19 -0400

Sandro,

>the definition in the GDOI draft :)

There is some history to the term GCKS.  The initial SMuG Reference Framework
distinguished between a Group-Owner/Controller and the Key-Server,
since it was thought that the Content Distributor or Content Provider
would "legally own" the Class D address.

Due to some comments from a "prominent" person in the IETF, we merged
the two boxes into one and called it GCKS.   Unfortunately, that prominent
person never showed-up again at SMuG :)

thomas
------

---

From: Mark Baugher <[email-masked]>
Date: Fri, 29 Jun 2001 15:11:45 -0700

Hi

>members or unicast from the KDC to a particular group member.".

The requirement is for "unicast exchange" not "unicast message," as
you implied in the first sentence of the paragraph above.  A unicast message
can be sent with or without public-key or Diffie-Hellman
operations on the KDC (GCKS in IRTF SMuG terminology - maybe we
should stick to GCKS but it does sound odd to me).  A unicast exchange
in the context of the I-D is a Registration protocol
exchange, which establishes an IKE Phase 1, IPsec, or SSL connection.

>transport protocol to ensure that all members receive the re-key..."?

Good point.  We've been discussing this for years in IRTF SMuG.  The
I-D recommends "packet-level FEC," which is our way of saying "send the
message periodically over some interval of time."

>management algorithms also use "Rekey messages" to rekey members. In this

Membership management algorithms leave rekey messages as an exercise
to the reader.  GSAKMP did an encoding.  GDOI did an encoding not much
different from GSAKMP's.  If this working group decides to proceed with
a separate specification for re-key, then we will get the canonical encoding
for msec.

>messages only convey a single Group KEK.

No, Section 4 defines it otherwise: See 4.0 "Case 2."

>the definition in the GDOI draft :)

I discussed this problem with the I-D in the first paragraph of my note.
There is one place where "GCKS" is used in the I-D and this is a
type.  I don't care what we call it though I notice that many people
often don't readily recognize it for what it is.

Mark