http://stupid.domain.name/ietf/

One document matched: draft-harney-sparta-lkhp-sec-00.txt-102979.txt

SPARTA, Inc. Hugh Harney, Eric Harder
INTERNET-DRAFT SPARTA, Inc., National Security Agency
draft-harney-sparta-lkhp-sec-00.txt March, 1999

Logical Key Hierarchy Protocol

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

This document is an Internet-Draft. Internet-Drafts are working documents
of the Internet Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working documents as
Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time. It
is inappropriate to use Internet-Drafts as reference material or to cite
them other than as ``work in progress''.

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Document expiration: August 30, 1999

Abstract

This document presents a Logical Key Hierarchy (LKH) Compromise
Recovery (CR) implementation for the key management protocol
suggested in the paper "Key Management for Multicast: Issues and
Architectures"[10]. The goals of this paper include: defining the
CR method, identifying the requirements, defining the operational
protocol, and recommending an implementation for an LKH CR
implementation.

INTERNET-DRAFT LKH Protocol March, 1999

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 2]

INTERNET-DRAFT LKH Protocol March, 1999

Contents

1 Background 4
1.1 Security for Multicast . . . . . . . . . . . . . . . . . . . . . . 5

2 Compromise Recovery 5
2.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Compromise Recovery Policy . . . . . . . . . . . . . . . . . . . . 6
2.2.1Restoration of Secure Network Operations . . . . . . . . . . . . 6
2.2.2Restrict Comprise Recovery Actions to Authorized Individuals . . 6
2.2.3Multiple Co-Located Compromises . . . . . . . . . . . . . . . . 6
2.2.4Secure Compromise Recovery Life-Cycle . . . . . . . . . . . . . 7
2.2.5System Stability After a Compromise . . . . . . . . . . . . . . 7
2.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.1Generation of LKH Arrays . . . . . . . . . . . . . . . . . . . . 7
2.3.2Generation of Support Materials . . . . . . . . . . . . . . . . 7
2.3.3Secure Compromise Recovery . . . . . . . . . . . . . . . . . . . 7
2.3.4Normal Operation Requirements . . . . . . . . . . . . . . . . . 8
3 LKH CR Protocol Specification 10
3.1 Group Establishment . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.1LKH Establishment Protocol . . . . . . . . . . . . . . . . . . . 11
3.2 CR Policy and Enforcement . . . . . . . . . . . . . . . . . . . . . 14
3.2.1Compromise Event . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.2Single Message to Exclude Compromised Member . . . . . . . . . . 18
3.2.3New Group Key . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 RECOMMENDATIONS 19
4.1 Develop Multicast Framework . . . . . . . . . . . . . . . . . . . . 19
4.2 Computer Trust Requirements . . . . . . . . . . . . . . . . . . . . 20
5 Addresses of Authors 22

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 3]

INTERNET-DRAFT LKH Protocol March, 1999

1 Background

Multicasting technology has been a promise for many years now, a blend
between unicast (point-to-point) and broadcast (on sender, many,
unidentifiable receivers), multicasting allows a group of participants to
communicate efficiently between themselves using public networks. Security
has been a key area holding back widespread adoption of multicast.

Group communications can be obtained using unicast methods (e.g., send
an e-mail to each participant), but this has an impact on the network
infrastructure, requiring sufficient resources to send each message from
the sender to each recipient uniquely (an e-mail to 100 addresses requires
the sender to actually send 100 messages). Using multicast, information is
sent once into the multicast infrastructure and the infrastructure creates
new messages/packets only when needed. Depending upon the networking
technologies in use, multicast can be performed with a single message.

Group communications can also be obtained using broadcast methods, though
these methods tend to be simplex (one-way) in nature. In this case, the
sender simply broadcasts his information and each receiver must determine
if the message is of interest to them. This approach is inefficient due
to the processing required at each broadcast recipient to filter out the
wanted from unwanted messaging. Broadcasting is also not practical with
some networking technologies (e.g., packet switched).

Multicasting, in general, provides the capability for information to
be disseminated to an identified group of participants efficiently.
Multicasting is typically performed by creating a group where participants
place information destined for all other participants. This group can be in
the form of a newsgroup, IP address, or ATM address.

The security challenge for multicasting is in providing an effective
method of controlling access to the group (and it's information) that is as
efficient as the underlying multicast. A primary method of limiting access
to information is through encryption and selective distribution of the keys
used to encrypt group information. Control of the key distribution process
provides effective control of the group. The controlling policy for key
distribution may differ among groups. For instance, military organizations
may wish to distribute keys to particular individuals or units based on
location or permissions; banks may wish to limit key distribution to
particular trusted individuals; individuals may wish to limit distribution
to particular family members. The range of options is limitless.

Establishing this cryptographic group on an internet is not a trivial task.
The entire group must converge on a single suite of security mechanisms
for data protection. The single cryptographic key must be created and
distributed to all members of the group in a secure manner. Some type
of access control policy must be enforced as part of the key distribution
mechanism. These policies must be created and disseminated to the groups in
a manner that that can be trusted.

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 4]

INTERNET-DRAFT LKH Protocol March, 1999

The decision to create a cryptographic group on the internet is a decision
based on the data that is going to be passed across the network and the
needs of the communicating group. If the data being passed across the
network is extremely important and not time sensitive, the security
policy for creation, dissemination, and access control may be stringent.
Alternately, if the data is not very sensitive, the security policies of the
group may be more relaxed. This is an important distinction because there
is a trade-off between security (assurance that the policy is in effect) and
performance (time and resources necessary to implement the policy). The job
of coordinating that trade-off falls to a management protocol.

1.1 Security for Multicast

The issue of secure multicast communications for multicast groups has two
parts. The first part consists of the mechanisms used to secure the data
while it is in transit between the multicast group members. The second
part, is the management of the security groups. Management in this case,
refers to:

1. Creation and distribution of keys,

2. Enforcement of access control policies, and

3. Operational control (e.g., compromise recovery, rekey, identity
infrastructure issues).

This document presents a Logical Key Hierarchy (LKH) Compromise Recovery
(CR) implementation for the key management protocol suggested in the
paper ``Key Management for Multicast: Issues and Architectures''[10].
The goals of this paper include: defining the CR method, identifying
the requirements, defining the operational protocol, and recommending an
implementation for an LKH CR implementation.

2 Compromise Recovery

2.1 Definitions

For the purpose of this document, a group is a gathering of communicating
members with a single key. If the group key is compromised, then secure
communication must be restored through a recovery action. A compromise
occurs when a member of the group can no longer be trusted (e.g. group
member loses their key or a group member's key is stolen). When this
happens, the group needs to change the compromised keys, without giving

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 5]

INTERNET-DRAFT LKH Protocol March, 1999

the new keys to the compromised member. This document proposes as LKH CR
protocol for this purpose.

2.2 Compromise Recovery Policy

A compromise is an event that makes a trusted member of a group untrusted
and untrustable. All keys in that member's possession are considered
``lost``. Many different events may trigger a compromise including:
equipment loss, discovery of inappropriate data transfer and theft.
Compromising events are defined by the CR Policy. The CR Policy must be
defined and understood prior to the compromise. The policy should define
what type of compromise requires recovery, the speed with which recovery
must be completed, and the level of acceptable risk to the system.

The following sections identify the minimum CR Policy assumptions that would
be necessary to support the LKH CR protocol presented in this document.

2.2.1 Restoration of Secure Network Operations

Network operations should be restored with a minimal number of messages
and with minimal delay. The goal of recovery is to resume operations in
a secure mode quickly and efficiently. The size of the LKH array and the
extent of the compromise will determine the number of messages required to
recover the LKH.

2.2.2 Restrict Comprise Recovery Actions to Authorized Individuals

The CR process changes the group membership and common group keys. An
unauthorized CR action could subvert the group into communicating with
unauthorized individuals or be used to deny service to the network. In
order to prevent unauthorized CR actions and reduce system vulnerability,
only authorized individuals should be allowed to identify that a compromise
has occurred, assess the risk, and implement the necessary CR action.

2.2.3 Multiple Co-Located Compromises

The CR process shall provide mechanisms to allow recovery from single- and
multiple-entity compromises. Historically, compromises have occurred due
to the breach of physical security measures at a particular location. In
a group environment, it is possible that several group members will be
physically co-located. The CR process should be capable of dealing with
multiple co-located compromises.

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 6]

INTERNET-DRAFT LKH Protocol March, 1999

2.2.4 Secure Compromise Recovery Life-Cycle

The entire life-cycle of the CR process must be secure. This includes the
generation of CR materials, establishment of the CR group, execution of
recovery from an event, and termination of CR for a group.

2.2.5 System Stability After a Compromise

The outcome of any compromise event and the resulting CR action must leave
the group capable of recovering from another compromise.

2.3 Requirements

The following sections present the requirements necessary to support the LKH
CR protocol.

2.3.1 Generation of LKH Arrays

The LKH array generation mechanisms, as well as the LKH arrays, must
be protected from unauthorized access. The CR Manager will have the
only access to these mechanisms. Further, the computers on which these
mechanisms reside must also be sufficiently protected from unauthorized
access.

2.3.2 Generation of Support Materials

The LKH CR process will be supported by certificates. The certificate
registration process must provide mechanisms to ensure that there is
unambiguous identification of individuals and authorities. The mechanisms
and processes within the certificate registration process must also be
verifiable and protected from unauthorized access and disclosure.

2.3.3 Secure Compromise Recovery

The CR process includes the exchange of sensitive materials (LKH key array).
To ensure that the compromise recovery process is secure, it must include
mechanisms for:

1. Identifying all group members;

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 7]

INTERNET-DRAFT LKH Protocol March, 1999

2. Identifying all CR agents;

3. Verifying the authority for all sensitive acts;

4. Verifying the integrity of all data exchanges;

5. Protecting all information that could be used to attack the CR system;
and

6. Verifying the assurance level of all CR computer components.

2.3.4 Normal Operation Requirements

The requirements identified in this section support the distribution,
management and storage of the LKH arrays prior to a compromise event. These
requirements must also be fully satisfied upon completion of a CR action.

2.3.4.1 Minimal Exposure of LKH Arrays

The LKH arrays are sensitive information and, if left unprotected, can be
used to attack or compromise the secure group. The use of routers and
other network components to distribute the LKH arrays should take place
with the understanding that the compromise of the component could lead to
group attacks. In order to help minimize the risk of exposure, the LKH
arrays should be held by as few computers as possible. Each CR Manager
that maintains an LKH array must provide adequate physical, procedural, and
computer trust protection mechanisms to protect the array.

2.3.4.2 Authentication of Identities

For all key management actions, the identities of the receiving and sending
parties need to be mutually understood. This requirement could be met by
verifying the public key of a party during key generation.

2.3.4.3 Verification of Authorization

The management actions supporting CR are critical to group security. The
identification and participation authorization of each group member involved
in a critical action must be verified. This requires a clear security
policy understood across the group. This policy can be static or dynamic
based on a policy dissemination mechanism.

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 8]

INTERNET-DRAFT LKH Protocol March, 1999

2.3.4.4 Computer Security Trust Requirements

The LKH key arrays are critical. If these arrays reside unencrypted on
a computer at any time, then that computer must be trusted to protect the
group's data. This requirement would be supported by maintaining only the
LKH arrays on group member's computers. Each group member's computer must
be trusted to protect the group's data.

2.3.4.5 Cryptographic Structure of Groups

It is anticipated that very large groups may choose to implement this LKH
CR technique to support their CR process. In order to provide the best
management and oversight, the large group should be constructed as the union
of multiple smaller groups. Each of the smaller groups will have its own
LKH array structures. These smaller LKH array structures will provide the
capability to:

1. Localize the CR processes;

2. Generate and maintain smaller LKH arrays;

3. Localize the CR reporting procedures;

4. Localize CR management; and

5. Implement cryptographic gateways to minimize any single group traffic
key exposure.

2.3.4.6 CR Message Requirements

There are security requirements placed on CR messages to ensure that the
messages are sent and received by the individuals with the appropriate
authority levels. CR messages should provide the following information:

1. Source verification;

2. Authority verification;

3. Confidentiality of data from unauthorized access;

4. Verifiable integrity of all data exchanges;

5. Protection of all information that could be used to attack the CR
system; and

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 9]

INTERNET-DRAFT LKH Protocol March, 1999

6. Verifiable assurance levels of all CR computer components.

The CR messages do not have a secure association (SA) with the group and,
therefore, confidentiality must be provided within the recovery key schema.

2.3.4.7 Compromise Event Discovery and Reporting

A deliberate compromise event may be difficult to discover because it is
in the interest of the attacker to keep the compromise a secret. As long
as the compromise remains undiscovered, the attacker will continue to have
access to the group's data. An accidental or unintentional compromise will
likely be reported as soon as the action is identified. However, regardless
of the source of the compromise, the CR Manager must have sufficient
mechanisms established to identify a compromise. The CR Manager must then
assess the extent of the compromise to identify the necessary CR actions for
recovery.

All CR actions will result in a temporary disruption of the group while
the group member's identities are verified and the keys are changed and
disseminated. A complete discussion of compromise discovery and reporting
is outside the scope of this document. Formal compromise discovery and
reporting policies should be developed to support this process. The LKH
CR technique presented in this document relies on input from a compromise
discovery action to identify the compromised group member.

3 LKH CR Protocol Specification

The logical definition of a secure group is multiple members communicating
via a common key scheme. The focus of the LKH CR protocol is the CR
protocol of this group. The methods used to create, distribute, verify, and
authenticate the common group key are outside the scope of this document.

3.1 Group Establishment

A large group can be serviced by several independent CR Agents each
controlling a subset of the CR domain. This architecture distributes the
processing and communication requirements of CR actions across the group
thus avoiding communication and processing bottle-necks.

For example, in an hierarchical tree CR protocol, a 2-layered LKH structure
with the CR Manager, ``Member 1``, at the top. The second layer members
(1.1 to 1.5) are all subject to CR actions initiated by ``Member 1``. Each
of the second tier members themselves have sub-nodes and hence, have LKH

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 10]

INTERNET-DRAFT LKH Protocol March, 1999

databases.

The top node in the LKH is identified as ``Member 1`` for the discussion in
the following sections. ``Member 1`` (Node 1 in the LKH schematic) will act
as the CR Manager. The second level nodes act as CR Agents.

3.1.1 LKH Establishment Protocol

The CR Manager and each of the CR Agents, will either create or obtain
the LKH databases and distribute the appropriate keys to the members in
their domain. These keys are extremely important to the continued secure
operation of the group. As such, the distribution of these keys needs to be
a secure process. The keys must be kept confidential. All the members need
to have an unambiguous identification of any party downloading keys to them.
The CR Manager and CR Agents need to have unambiguous identification of the
members to which they will distribute keys. The members need to verify that
the CR Manager and CR Agents are authorized to act in those roles. Each
of these requirements is similar if not exactly equal to the requirements
needed to distribute the original group key. To avoid redundancy of action,
wherever possible, the CR data will be distributed with the symmetric key.

3.1.1.1 Generation of LKH Array

The CR Manager generates the keys needed to construct a LKH array. There
are two methods for generating an LKH array for very large groups. First,
the CR Manager could generate a very deep array capable of encompassing all
the potential members of the group. Second, the CR Manager can generate a
smaller array capable of recovering the first tier of a group. These first
tier members can act as delegated CR Agents, each generating LKH arrays for
group members in branches below them.

Of the two methods for generating an LKH array for large groups, the
delegated CR mechanism provides greater scalability. The issue with this
delegated approach is the CR Manager and CR Agents must be identified to
the group members prior to the establishment of a group. One mechanism for
accomplishing this is the use of a group policy token. The CR Manger and
CR Agents could be identified and a single group authority could authorize
them.

This method of establishing LKH arrays will be illustrated in the following
specification. The CR Manager generates and stores the list of keys.

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 11]

INTERNET-DRAFT LKH Protocol March, 1999

3.1.1.2 Distribution of LKH Array to Group Members

The distribution of LKH array material should involve a peer-to-peer session
association. The security of the group is built from a collection of
peer-to-peer access control decisions.

It is important to note that all access control decisions do not need to be
made by the CR Manager or any central point. A multicast group can easily
be constructed by a number of peer-to-peer access control decisions. The
critical issue is to ensure that the access control decisions are made by
members authorized to make such a decision for the group.

The identity of group access control points is a matter for group policy.
The simplest policy is that one site makes all group access decisions. A
more scaleable solution identifies multiple points authorized to make these
decisions for the group. An even more scaleable solution allows any group
member (with proof that they have been accepted into the group) to make an
access control decision for the group. Essentially, known group members
could be allowed to vouch for new group members.

In the case of distribution of CR material, the generator of the LKH array
could distribute pieces of the array to authorized distribution points
within the group for subsequent distribution.

3.1.1.2.1 Establishment of a Secure Association Modern SA protocols like the
Internet Secure Association Key Management Protocol (ISAKMP) are suited to
this task. The security characteristics of the establishment protocol for
the SA should include:

1. Verification of all identities;

2. Validation of public certificates (if used);

3. Creation of a pairwise traffic confidentiality key; and

4. Transfer of identity and certificate information to multicast security
management protocol.

Once the SA is established, the multicast security management protocol can
use that SA for secure confidential communications.

3.1.1.2.2 Data Structure of LKH Array Download Message When the identities
of each side of the SA are known to the multicast security protocol,
the multicast security protocol can use these identities along with the
verified information on the public certificates to enforce group security
policy. The group security policy includes information about authorized

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 12]

INTERNET-DRAFT LKH Protocol March, 1999

CR mechanisms and distribution authorities. The management protocol needs
to verify that the CR Manager is authorized to download the LKH CR arrays.
The management protocol will take the identity and authority information
verified in the establishment of the SA and make sure that it meets the
policy criteria.

In order to verify authority, there has to be something that identifies
authorized CR Agents. This could be an internal configuration file or
it could be a data structure that dynamically conveys a policy from an
authorized source. In the case of a data structure, this policy data
structure (token) could be sent with the LKH array.

The data structure of the LKH array and (optional) Policy Token is:

2 bytes Data ID
16 bytes Grp ID
8 bytes Date/Time
1 byte Sig Alg ID
2 bytes Cert Infra ID
1 byte LKH Version
4 bytes LKH array length
Variable LKH array
1 byte (policy token)
4 bytes (# packets)
Variable (Packets 1-n)
1 byte (Pub Cert)
2 byte (# Packets)
1 byte (Packets 1-n)
Variable Sig

where:

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 13]

INTERNET-DRAFT LKH Protocol March, 1999

Data ID: Identifies the packet as a CR data item.
1=LKH array, 2=LKH array with policy
token, 3=LKH array with policy token and
public certificate of signer
Grp ID: Specifies the group the LKH array will
address
Date/Time: Self-explanatory
Sig Alg ID: Specifies the signature algorithm used
in this data item
Cert Infra ID: Specifies the certificate infrastructure
needed for verifying signature
LKH ver: Version of the LKH CR protocol
LKH Array Length: Total number of bytes in the LKH array
LKH Array: Data

( ) signifies optional fields

(Policy Token): Identifies the Policy Token
(# Packets): Self-explanatory
(Policy Token Packets 1-n): Self-explanatory
(Pub Cert): Identifies public certificate data being
sent
(# Packets): Self-explanatory
(Packets 1-n): Self-explanatory
Sig: Signature field as identified earlier

3.2 CR Policy and Enforcement

3.2.1 Compromise Event

The CR Manager, designated as Member 1, manages compromises occurring in the
second tier of the hierarchy. In the second tier member designations (eg.,
1.1), the number to the left of the decimal refers to the CR Manager. The
number to the right of the decimal is the unique identifier of the CR Agent.
The third tier is comprised of group members who do not act as CR Agents.
In the third tier designations (eg., 1.1.5), the first number refers to the
CR Manager. The second number designates the second tier CR Agent that owns
the domain on which this particular member resides. The third number, in
this example 5, is a unique identifier. This numbering scheme is useful for
reporting compromises and allows the member designation of the bottom tier
member to uniquely identify that member, the CR Manager, and the delegated
CR Agent in the hierarchy above.

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 14]

INTERNET-DRAFT LKH Protocol March, 1999

3.2.1.1 Compromised Discovery

After a compromise is discovered, a compromised report is received by Member
1, the CR Manager. The contents of this message include, at a minimum,
the identity of the compromised member and, in the case of a multi-tiered
architecture, a path to that member.

The active member in this example is the CR Manager (Member 1). The CR
Manager will verify that the CR report was received and is authentic. It
will then initiate CR actions.

3.2.1.2 Recovery Protocol

The CR Manager creates the CR message based on the information that was
passed within the CR report. The CR Manager sends this message to all
members of its domain utilizing the multicast communication address of the
group.

The CR message is sent on the group address and to the common key management
port routing to the key management application resident at each member.
Each member verifies that the CR message is authentic and that the signature
on that message comes from a party that is authorized to send a CR message.
This authorization decision is based on some known policy that has been
previously configured for the group. One mechanism that is useful for
configuring group policy is a policy token.

Each CR message will contain a Date/Time stamp. A CR action may only be
processed if its Date/Time stamp is later than the Date/Time stamp of
the last CR action processed for the group. In the event of multiple CR
actions, the CR messages should be processed in ascending order according
to their date/time stamp.

After the CR message has been verified, each member will decrypt their
portion of the CR message. That single CR message will recover some portion
of the compromised group and provide the first tier members the means to the
reset group traffic keys to a new secure key. Any member in the path of a
compromised member and will be unable to decrypt the new group traffic key.

The LKH shown in Figure 1 represents virtual nodes as letters and members
nodes as numerals. Assuming Member 1 is compromised, the symbolic form of
the recovery message is:

CompHdr{[Sec HdrB(MGK')B], [Sec HdrD(MGK',A')D], [Sec Hdr2
(MGK',C',A')2]}Siglkhc

Notation:

CompHdr{} = CR message header for message between {}

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 15]

INTERNET-DRAFT LKH Protocol March, 1999

LKHController
|
|
A------------B
| |
| |
C------D E------F
| | | |
1---2 3---4 5---6 7---8

Figure 1: Sample Compromise

[SecHdr*(MGK').] = Data packet containing a security header that allows
the decryption of the data package encrypted in key * (in this case, the
data packet contains MGK: Multicast Group Key Prime)

{}SigXo = Public key signature of data contained within {}, public key to
verify is Xo.

The data structure of the CR message follows:

1 byte CR Msg ID
16 bytes Grp ID
8 bytes Date/Time
1 byte Encr Alg ID
1 byte Sig Alg ID
1 byte Hash ID
2 bytes Cert Infra ID
1 byte CR Msg Type
1 byte Tree type
1 byte LKH Ver
4 bytes # Packets
Variable Packets 1-n
Variable Sig

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 16]

INTERNET-DRAFT LKH Protocol March, 1999

CR Msg ID: CR Message ID distinguishes this message
from other key management messages. Suggest
an integer value with: 66=CR.
Grp ID: Group identification value is a 16 byte
string that identifies the specific group
the CR message is to recover. Suggest this
field be the group common name.
Date/ Time: This field specifies the date/time this
message was sent.
Encr Alg ID: Encryption Algorithm Identification. This
field specifies the exact cryptographic
algorithm to be used by this message. An
integer value suffices. 1=DES CBC, 2=triple
DES.
Sig Alg ID: Signature Algorithm Identification. This
field identifies the algorithm used to sign
this message. Suggestion 1=DSS.
Hash ID: Hash Identification specifies the hash
algorithm used. Suggestion 1=SHA.
Cert Infra ID: Certificate Infrastructure Identification
specifies type and location of certificate
infrastructures.
CR Msg Type: CR Message Type specifies type of CR
message. Suggest: 1=Group Recovery,
2=Individual Recovery, 3=Maintenance,
4=Delete Group Key.
Tree Type: This specifies the mechanism used by the CR
process.
LKH Ver: LKH Protocol Version. Suggestion 1=first.
# Packets: Number of Packets specifies the number of
information data items in the payload of the
CR message.
Packets 1-n: Each individual packet will take the
following form:
1 byte Packet type
4 bytes Length of packet
Variable Data
Packet type: Specifies the data within the packet.
Suggest: 1=encrypted key(s),
2=cryptographic changeover time,
3=unencrypted data.
Packet Length: An integer specifying the number of bytes in
the data packet.
Sig: The signature block contains the actual
signature in the algorithm specified in the
Sig Alg ID data field. It should take the
following form:
1 byte Signature format
4 bytes Length of data
Variable Data
Signature format: This field defines the exact data contained
in the data field. Suggest: 1=DSS, 2=DSS
Harney/Harder draft-hwithapublicrcertificatenofesigningyparty.-sparta-lkhp-sec-00.txt [Page 17]

INTERNET-DRAFT LKH Protocol March, 1999

3.2.2 Single Message to Exclude Compromised Member

The CR Manager has been notified of the compromised status of a tertiary
member (eg., 1.1.1). The CR Agent in the compromise path generates a
message using keys stored in its database that will exclude the compromised
member from receiving the new group key.

CompHdr{[SecHdrB(MGK0)B];[SecHdrD(MGK0;A0)D];[SecHdr1:1:2(MGK0; C0; A0)1:1:2]}SigX1:1

The CR message is sent out over the multicast communication address. All
nodes in the group and in the subgroup receive that message and each
authorized member decrypts the new traffic key. It is possible that
the CR Agent could act as a cryptographic gateway for its sub-nodes. A
cryptographic gateway changes the cryptographic traffic key for a branch of
a group. A message encrypted with the group key of the second tier would
come to the CR Agent who would then take all the data and re-encrypt that
data in the group key common for its branch.

The CR Agent's CR message will be restricted only to group members in its
domain. There are two possible scenarios to support this restriction.
In the first, the CR Agent could be a cryptographic gateway and therefore
would have a group address for it's branch. The group address could offer
a limited distribution option to preclude external transmission. In the
second scenario, the CR Agent could establish a special local group address
for the branch.

3.2.3 New Group Key

When suborninate CR Agents are used all members in the path of a compromise
must be brought back into the secure group. To accomplish this, the CR
Manager (Member 1) creates a SA with the delegated CR Agent using a SA
protocol like ISAKMP.

Once a SA is established, the CR Manager sends a combination message to
the delegated CR Agent (Member 1.1). This combination message tells the
CR Agent that one of a its sub-nodes has been compromised and also passes
the new secure group key. The CR Agent verifies that the CR Manager is the
originator of this message and then updates it's group key. The CR Agent
then begins CR actions for his domain.

The symbolic form of the message is:

CompHdr[(SecHdr1 (MGK')1, CompRpt)Sig1]1

Notation:

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 18]

INTERNET-DRAFT LKH Protocol March, 1999

CompHdr{} = CR message header for message between {}

SecHdr*(MGK') = Data packet containing a security header that allows the
decryption of the data package encrypted in key * (in this case, the data
packet contains MGK: Multicast Group Key Prime)

{}SigXo = Public key signature of data contained within {}, public key to
verify is Xo.

The message structure for this combination message is exactly the same as
the group recovery message defined in Section 3.2.2. This message utilized
a new data packet type, Packet Type 3, to transmit the CR report to the CR
Manager.

4 RECOMMENDATIONS

4.1 Develop Multicast Framework

In the interest of standardization and efficiency, it is reasonable to
propose a standard multicast security framework that could organize the
establishment of security for multicast groups. In such a framework, CR
would be a component of the overall security profile for a group. The
LKH CR protocol could be an option for supporting CR within a standardized
framework architecture.

The LKH CR protocol is part of a complete multicast security management
protocol. It provides CR services for a group without respect to the
distribution methodologies or underlying communication protocols. The
LKH CR protocol does make some assumptions about services provided by the
more general multicast security management protocol. This protocol should
include mechanisms to support the following requirements:

- Verifiable and understandable security policy;

- Unambiguous identification of members;

- Verification of authority to perform relevant actions; and

- Confidential delivery of information to group members.

These basic services are fundamental to securing groups with keys. A
well-orchestrated protocol should incur the overhead of these services once
and pass all necessary information to the group members. The LKH CR does
not implement these mechanisms due to the assumption that these services
are available during secure key establishment. Implementing these services

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 19]

INTERNET-DRAFT LKH Protocol March, 1999

within the LKH CR protocol is redundant.

4.2 Computer Trust Requirements

Multicast security protocols do not allow each member of a group to verify
the identity and authority of every other member of the group. This means
that each member of the group must \trust"some other party (group member
or not) to verify another group member. This cooperative enforcement of
security policy across the group requires a base-level of trust in those
verifying authorities.

It is important that every group member, CR Agent, or CR Manager with
access to either the group key or the LKH key array (in unencrypted form),
is capable of protecting that information from unauthorized disclosure.
This requires that all proper rules must be enforced as part of the group
security protocol. These computers must also be trusted not to divulge
the keys via an unofficial route (e.g., a hacker exploiting a weakness in
another application).

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 20]

INTERNET-DRAFT LKH Protocol March, 1999

The following documents were used in the preparation of this document:

References

[1] [RFC 2093] Harney H., Muckenhirn C., and Rivers T., Group Key,
Management Protocol Specification, RFC 2093, Experimental, July 1997.

[2] [RFC 2094] Harney H., Muckenhirn C., and Rivers T., Group Key
Management Protocol Architecture, RFC 2094, Experimental, July 1997.

[3] [RFC 2408] Maughan D., Schertler M., Schneider M., and Turner J.,
Internet Security Association and Key Management Protocol (ISAKMP),
RFC 2408, Proposed Standard, November 1998.

[4] [RFC 2412] Orman H. K., The OAKLEY Key Determination Protocol, RFC
2412, Informational, November 1998.

[5] [RFC 2409] Harkins D., and Carrel D., The Internet Key Exchange (IKE),
RFC 2409, Proposed Standard, November 1998.

[6] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure
Data Network System, Security Protocol 3 (SP3) Addendum 1, Cooperating
Families, SDN.301.1, Rev. 1.2, 1988-07-12.

[7] SDNS Protocol and Signaling Working Group, SP3 Sub-Group, SDNS Secure
Data Network System, Security Protocol 3 (SP3), SDN.301, Rev. 1.5,
1989-05-15.

[8] [RFC 1949] Ballardie, A., Scalable Multicast Key Distribution, RFC
1949, Experimental, May 1996.

[9] [RFC 2459] Housley R., Ford W., Polk T., and Solo D., Internet X.509
Public Key Infrastructure Certificate and CRL Profile, RFC 2450,
Proposed Standard, January 1999.

[10] Wallner, D., Harder E., and Agee R., Key Management for Multicast:
Issues and Architectures, Internet Draft, Informational, September
1998.

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 21]

INTERNET-DRAFT LKH Protocol March, 1999

5 Addresses of Authors

Hugh Harney (point-of-contact)
SPARTA, Inc.
Secure Systems Engineering Division
9861 Broken Land Parkway, Suite 300
Columbia, MD 21046-1170
United States
telephone: +1 410 381 9400 (ext. 203)
electronic mail: hh@columbia.sparta.com

Eric J. Harder
R231 National Security Agency
9800 Savage Road
Suite 6534
Fort Meade, MD 20755
United States
telephone: +1 301 688 0847
electronic mail: ejh@tycho.ncsc.mil

Document expiration: August 30, 1999

Harney/Harder draft-harney-sparta-lkhp-sec-00.txt [Page 22]

- --------------F49BFCF24022E6D94642B018
Content-Type: text/plain; charset=us-ascii; name="draft-harney-sparta-msmp-sec-00.txt"
Content-Disposition: inline; filename="draft-harney-sparta-msmp-sec-00.txt"
Content-Transfer-Encoding: 7bit

SPARTA, Inc. Hugh Harney, Eric Harder
INTERNET-DRAFT SPARTA, Inc., National Security Agency
draft-harney-sparta-msmp-sec-00.txt March, 1999

Multicast Security Management Protocol (MSMP) Requirements and Policy

Status of this memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.

To view the entire list of current Internet-Drafts, please check the
``lid-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US
East Coast), or ftp.isi.edu (US West Coast).

Document expiration: August 30, 1999

Abstract

This Internet-Draft describes issues relating to the management of
cryptographic keys in support of multicast communications. It
describes the functional and security requirements of an electronic
key management system for multicast.

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

Contents

1 INTRODUCTION 3
1.1 Desirable Features . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Candidate Applications . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1Teleconferencing . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2Broadcast (NNTP, NASA broadcast) . . . . . . . . . . . . . . . . 5
1.3 Security for Multicast . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1Securing Multicast Packets . . . . . . . . . . . . . . . . . . . 6
1.3.2Managing Secure Groups . . . . . . . . . . . . . . . . . . . . . 7

2 REQUIREMENTS 7
2.1 Real World Requirements . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1Performance . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2Flexibility/Modularity . . . . . . . . . . . . . . . . . . . . . 9
2.1.3Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Security Requirements . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1Algorithm Definition . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2Key Generation Definition . . . . . . . . . . . . . . . . . . . 11
2.3 Authorization Definition . . . . . . . . . . . . . . . . . . . . . 12
2.3.1Access Control . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2Key Dissemination Architectures . . . . . . . . . . . . . . . . 13
2.3.3Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.4Authorization . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.5Rekey Approach . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.6Compromise . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Protocol Requirements . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1Self Defined . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2Communications Protocol Independent . . . . . . . . . . . . . . 18
2.4.3Architecture Independent . . . . . . . . . . . . . . . . . . . . 19
3 POLICY COMPONENTS 19
3.1 Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.1Operational Policy . . . . . . . . . . . . . . . . . . . . . . . 20
3.2.2Key Dissemination Policy . . . . . . . . . . . . . . . . . . . . 20
3.2.3Access Control Policy . . . . . . . . . . . . . . . . . . . . . 21
3.2.4Rekey Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2.5Compromise Policy . . . . . . . . . . . . . . . . . . . . . . . 21

4 DESIGN RECOMMENDATIONS 22
4.1 Global Policy Mechanism . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Limited Group of Security Mechanisms . . . . . . . . . . . . . . . 22
4.3 Policy Decomposition Of Multicast Protocols . . . . . . . . . . . . 23
5 Addresses of Authors 26

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 2]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

1 INTRODUCTION

Multicasting technology has been a promise for many years now. A
blend between unicast (point to point) and broadcast (on sender, many,
unidentifiable receivers), multicasting allows a group of participants to
communicate efficiently between themselves using public networks. Security
has been a key area holding back widespread adoption of multicast.

Group communications can be obtained using unicast methods (e.g., send
an e-mail to each participant), but this has an impact on the network
infrastructure, requiring sufficient resources to send each message from
the sender to each recipient uniquely (an e-mail to 100 addresses requires
the sender to actually send 100 messages). Using multicast, information is
sent only once into the multicast infrastructure and the infrastructure only
creates new messages/packets when needed. Depending upon the networking
technologies in use, multicast can be performed with a single message.

The security challenge for multicasting is in providing an effective
method of controlling access to the group (and it's information) that is as
efficient as the underlying multicast. A primary method of limiting access
to information is through encryption and selective distribution of the keys
used to encrypt group information. Control of the key distribution process
provides effective control of the group. The controlling policy for key
distribution may differ among groups. For instance, organizations may wish
to distribute keys to particular individuals or units based on location or
permissions; banks may wish to limit key distribution to particular trusted
individuals; or individuals may wish to limit distribution to particular
family members. The range of options is limitless.

The decision to create a cryptographic group on the internet is a based
on the data that is going to be passed across the network and the needs
of the communicating group. If the data passed across the network is
extremely important and not time sensitive, the security policy for
creation, dissemination, and access control may be stringent. Alternately,
if the data is not very sensitive, the security policies of the group
may be more relaxed. This is an important distinction because there is

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 3]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

a trade-off between security (assurance that the policy is in effect) and
performance (time and resources necessary to implement the policy). The job
of coordinating that trade-off falls to a management protocol.

This paper identifies and discusses the security and key management
requirements for cryptographic groups. This includes group creation, group
key creation, key distribution, policy creation, policy distribution, access
control and group behaviors (management, rekey and compromise recovery).
The goal is to craft the specific requirements for a Multicast Security
Management Protocol (MSMP).

1.1 Desirable Features

The desirable features for a MSMP include:

- The security management protocol shall operate in a heterogeneous
communications protocol environment

- The security management protocol shall provide and utilize all
reasonable security mechanisms to provide high assurance to
security-relevant management events.

- The security management protocol shall protect the group from all known
security attacks pertaining to security management.

1.2 Candidate Applications

In looking to the internet, the Inter-Domain Routing Protocol (IDRP) and
the Distance Vector Multicast Routing Protocol (DVMRP) use multicast as
a mechanism for parties to relay common information to their peers. Each
party both sends and receives information in the multicast channel. As
appropriate, a party may choose to leave or join the communication without
the express permission of any of the other parties. More interestingly, the
multicast internet protocol (IP) model has the receiver telling the network
to add it to the distribution for a particular multicast address, whether it
exists yet or not, and the sender is not consulted as to the addition of the
receiver.

Other applications of multicast communications in the internet (e.g., NASA
select broadcasts) can be viewed as implementing the sender model because
the sender selects the broadcast time, channel, and content, though not the
destinations.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 4]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

1.2.1 Teleconferencing

Video or audio teleconferencing is one model of multicast communications.
Widespread use of the video or audio teleconferencing applications will
result in many small groups existing at one time. These groups will
be highly dynamic. Individual users may have several applications, or
instances of applications, running simultaneously with different keys.
Individuals will gain access to groups based on their network address and
on personal characteristics (e.g., name, organization, physical location,
authorizations) that may be contained in cryptographic certificates. There
may even be a secondary mechanism for finer grained access management
controlled locally.

1.2.2 Broadcast (NNTP, NASA broadcast)

Another scenario for group keys is a large single keyed group. There
are some interesting environmental constraints on key management imposed
by the characteristics of extremely large groups (e.g., network news and
broadcast). Network news transmissions represent the case of extremely
large groups where each recipient receives the same data package. The
keying of a secure network news group is complicated by the unidirectional
characteristic of the communications. The sheer size of network newsgroups
precludes any sort of standard reply from each recipient, as these
acknowledgments would easily consume all available network bandwidth for
popular groups.

cooperative enforcement of the group security policies would require that
all entities enforcing the access control policy were trusted to do so.
This requirement may seem difficult to manage. Yet, the group with access
to the data decryption key are trusted to protect that data. It seems
logical that those same members should be trusted, by default, to protect
the key that is protecting the data. Essentially, the group members trusted
to protect the data being encrypted are available, and trusted, to enforce
the groups' access control policy. The problem devolves to how do we use
those members to speed group establishment.

The security of the key is inversely proportional to the number of holders
of that key. This observation leads to some potential alternatives
for controlling the keys protecting information in such a group. One
alternative for large groups is to compose it of smaller groups connected by
``cryptographic gateways''. (1) In principle, if any single endpoint goes

- ------------------------------
1. Cryptographic gateway refers to a device that is trusted to decrypt and
re-encrypt
traffic from one ``enclave'' to another. Such a device may be a specialized
multicasting gateway, providing security translation service between a local
network and the multicast backbone. Also, such a device may be

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 5]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

bad, the compromise is confined to that communication group. In effect, the
compromised cryptographic key would have limited utility. The geographical
location of that communication net bounds the utility of the key. Systems
that require actual broadcast of secure packets (e.g. satellite downfeeds
and some cable architectures) could not use the meshed large cryptographic
group.

1.3 Security for Multicast

The issue of secure multicast communications for multicast groups has two
parts. The first part consists of the mechanisms used to secure the data
while it is in transit between the multicast group members. The second part
is the management of the security groups. Management in this case, refers
to:

- Creation and distribution of keys,

- Enforcement of access control policies, and

- Operational control (e.g., compromise recovery, rekey, identity
infrastructure issues).

1.3.1 Securing Multicast Packets

When a group of entities share a cryptographic key, for encryption of data
traffic over a multicast address, they all share use of that key. Multicast
communications allow any member of the group to encrypt a message and
have it decrypted by multiple destinations. The sender ID is included
in an IP packet but any member of the group can create a packet with any
sender ID making it impossible to unambiguously distinguish the source
of the transmission based on the key used to decrypt the transmission.
This implies that a separate mechanism must authenticate the source for
transmission in a cryptographic group.

Several mechanisms exist that can authenticate individual sources of
transmission in a cryptographic group. The most obvious and widely used
mechanism is the digital signature. Digital signatures have the advantage
of being received by a wide audience and being created by a very narrow
audience. They have the disadvantage of taking a long time (as compared
to encryption) either to sign or to verify. Depending on the type of
communication going on, the time required to use a digital signature may

- ------------------------------
employed where there are issues of cryptographic releasability, allowing for
groups to be created, that use several cryptographic algorithms.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 6]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

make it impractical.(2) For communications that are not time sensitive,
it may be reasonable to apply a digital signature. Network news maybe
appropriate for digital signatures.

1.3.2 Managing Secure Groups

The MSMP encompasses all the issues of a cryptographic group. The
management of multicast secure groups is most likely an application layer
protocol. Each group of members needs an instance of the management
application layer protocol. Those protocol instances need to cooperate
to successfully enforce the group's policies and provide keys and group
management information.

There are many management issues associated with the securing of a multicast
group, including:

- Key generation procedures,

- Key distribution to all group members,

- Commonly understood group mechanisms, and

- Orchestrated group actions.

The next section outlines the details of the target requirements for such a
group management protocol.

2 REQUIREMENTS

A clear collection and definition of the multicast security and key
managment requirements will help in the definition of the MSMP. Many people
have an idea of how to solve multicast key management problems for specific
systems. The requirements presented in this paper were collected from the
requirements for multicast key and security management from different types
of systems. Several multicast security proposals were also reviewed to
include their stated requirements.[1, 2, 3, 4, 5, 8]

- ------------------------------
2. The use of digital signatures for streaming applications may
be impractical on a ``packet-by-packet'' basis, though it may be possible to
perform a digital signature verification on a periodic basis over ``chunks''
of the previously transmitted stream. Also, the use
of a running cryptographic checksum, initialized by an authenticated message
(signed precursor), may also serve this purpose.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 7]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

2.1 Real World Requirements

There are two broad requirements of the real world: efficiency and utility.
MSMP must present a useful functionality set for most applications. It must
contain enough options to allow it to operate across heterogeneous systems
and configurations. Unfortunately, the desire to provide a functional tool
set for the widest range of applications conflicts with other concerns,
namely efficient use of resources and performance.

2.1.1 Performance

- MSMP shall establish small groups in a few seconds.

- MSMP shall support large groups that never converge.

- MSMP shall support confirmation of group convergence (merge) in large
groups, where required by group policy.

- The MSMP should be able to accommodate a variety of convergence states.

2.1.1.0.1 Resource Utilization

It is desirable to perform managment operations when they have the least
operational impact. It may be useful to describe a performance curve
for multicast security management over the life span of a secure group.
The set-up phase of the group is where a majority of the management
functions should occur. Interactions that would interrupt the group (rekey,
compromise recovery, leave, join) should be localized to members of the
group requiring the service. These interactions should also be streamlined
to minimize the impact on the legitimate group members.

In the group communications of a multicast group, the security management
set-up takes place coincident with the group set-up. During normal group
communication, the security managment of the group is merely a watchdog
effort ensuring the group is operating correctly. During a re-key, leave,
or join, security management occurs, but it is minimal and localized, if
possible. The group communications processing increases if there is a
compromise of a group member. If compromise recovery is possible for a
group, the security management protocol will become active in keying the
compromised individual out of the group. In most instances, a new group
is created that excludes the compromised entity. The security managment
protocol would also support documentation of information for a forensic
review of the compromise.

In summary, the MSMP must:

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 8]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

- Front load processing requirements (set-up) and

- Provide audit mechanisms.

2.1.2 Flexibility/Modularity

MSMP must be flexible enough to apply to many different environments.
It must be modular to easily allow users to adapt the protocol to their
environment. One mechanism to create an efficient and highly flexible
protocol is to provide a single architecture that supports multiple
specialized sub-protocols. To some degree, it may make sense to make
protocol "objects" optimized for a particular need.

In summary, the MSMP must:

- Support multiple environments and

- Provide mechanisms for the expansion and optimization for special
environments.

2.1.3 Scalability

Scalability refers to the protocols' ability to do two things -- support
groups with large numbers of users and support large numbers of individual
groups. Unfortunately, these two architectures can be at odds with each
other.

2.1.3.1 Many Group Members

Some multicast groups have an extremely high number of sites. Usually, most
group members are receive-only and very few are transmit. There are some
interesting requirements associated with this type of group. The security
protocol may need to operate "out of band" and each individual site will
need to correlate keys to the appropriate group address.

There are architectural issues with whether a group like this should even
share a single key. Today's architecture relays a single message around
the globe. This may not be desirable in the case of a secure group. A key
shared by many people really will not protect much information. Of course,
it is also true that if a key holder cannot be trusted to protect the key,
nor can they be trusted with the information protected by the key.

An alternative architecture to the single key per group is the large
group built up of smaller groups connected by cryptographic gateways.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 9]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

<Internet>
|
___________________|___________________
| | |
<CryptoGateway> <CryptoGateway> <CryptoGateway>
Key=1 Key=1/2 Key=2/3
_____|_____ _____|_____ _____|_____
| | | | | |
<Member> <Member> <Member> <Member> <Member> <Member>
Key=1 Key=1 Key=2 Key=2 Key=3 Key=3

Figure 1: Use of Cryptographic Gateways to Reduce Key Exposure

Figure 1 presents this type of large group. These composite groups have
the advantage of limiting the utility of any single cryptographic key
and tighter control can be placed on access control by specifying local
trusted controllers. The MSMP need do very little to support this type
of group. Each local group is feasibly a normal cryptographic group. The
cryptographic gateway can either be a local decision or it could be stated
in the policy. See Figure 1

In summary, the MSMP must:

- Enforce communications policy defined by group and

- Link single key(s) to individual groups.

2.1.3.2 Large Numbers of Small Groups

Another scalability issue is that the protocol must support a large number
of groups each with a fairly small number of members. It seems reasonable
to predict that the internet will probably have many IP video or audio
teleconferences occurring at any one time.

The scalabilty issues with this scenario deal with availability of
resources. An approach that relies on a central server in establishing
groups would likely experience problems as the number of groups increases
and, given the dynamic nature of groups, the group's lifespan decreases.
That central server would become very busy and a potential single point of
failure.

In summary, the MSMP must Support small group proliferation without creating
communication or processing overloads.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 10]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

2.2 Security Requirements

There are security requirements inherently tied to a protocol that
manages keys [3,4,5]. The following sections attempt to identify all of
these possible requirements. Protocols designed to service a particular
environment will have a tailored subset of requirements. However, a generic
MSMP must be flexible enough to satisfy these broad requirements.

The use of cryptography to protect data shifts the burden of security to
the management of the cryptographic key. In essence, control of the key is
equivalent to control of the data, and key management becomes the pivotal
point for cryptographic-based security.

2.2.1 Algorithm Definition

Due to the nature of groups, negotiation of cryptographic algorithms is
difficult, if not impossible. MSMP must define a common algorithm policy.
This could be optimized to the environment.

Alternatively, the Internet Secure Association Key Management Protocol
(ISAKMP now IKE) could negotiate the algorithm suite. If ISAKMP was able
to completely cover the domain of the potential user base of the MSMP, then
ISAKMP would be an adequate solution. The problem arises when a user tries
to utilize MSMP without having benefit of a pre-negotiation by ISAKMP. MSMP
would have to either negotiate the algorithm suite itself or cause ISAKMP to
do so.

In summary, the MSMP should:

- Select cryptographic algorithms based on negotiated group policy, and

- Provide an interface for ISAKMP to establish the cryptographic
environment.

2.2.2 Key Generation Definition

Two general mechanisms exist for the generation of cryptographic keys. A
cooperative peer exchange [8] of key information can create a cryptographic
key. Alternatively, a single entity can use a key generation technology to
generate a key by itself.

The choice of which mechanism to use is determined by the security
requirements of the group and the communication resources available to the
MSMP. For each environment, a policy decision will have to be made. The
MSMP must support both mechanisms as directed by a policy decision.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 11]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

In summary, the MSMP must enforce key generation policy.

2.3 Authorization Definition

The definition of authorization mechanisms, and infrastructure, must be
consistent across a MSMP domain. Due to the potential use of authorization
tokens and certificates [ 9,10] for identity within the MSMP, the only
way to make correct access control decisions would be to have a common
authorization definition. It may be possible to define a mapping
between authorization mechanisms to allow heterogeneous authorization
infrastructures to interact. However, this mapping mechanism currently
falls outside the scope of this security protocol.

In summary, the MSMP must:

- Enforce authorization policy, and

- Support a common authorization definition, and/or

- Support a common mapping of definition between authorization
infrastructures.

2.3.1 Access Control

Access control, as it relates to security and key management, denies the key
from entities without permission to hold the key. Historically, asymmetric
key management protocols have implemented a policy of peer review. Peers
cooperate to create the key. They "know" each others' identity based upon
information passed. This identity information was previously certified by
a trusted third party. Each peer "knew" that it wanted (or was allowed) to
create a secure session with the other entity.

In the case of a multicast group, the peer-to-peer relationship for access
control is impossible to implement. The number of messages required for
every member in a group to identify, verify and perform access control
for every other member group is prohibitive in terms of processing and
bandwidth. Hence, the access control mechanisms must be different for
multicast groups. In a multicast group, it is reasonable for the group
owner to define the access control policy.

To summarize, the MSMP must:

- Support configuration of the access control policy,

- Distribute the access control policy to group, and

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 12]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

- Verify access control.

Since the MSMP has to control access to the key, it performs the access
control decisions. These access control decisions lay the very foundation
for group security. There are two different philosophies: rules-based and
identity-based access control.

2.3.1.1 Identity-Based

Identity-based access control decisions lend themselves to groups where all
participants of the group are known in advance. These decisions are very
clean and provide a high degree of assurance that only those group members
listed have access to the data. This assumes, of course, that the mechanism
for identifying group members is a strong one. Identity in this case can
mean individual identities as defined by individual's certificates or it can
refer to an IP address of a host machine.

Any identity-based access control policy requires that all access control
decision makers have of the list of approved identities. The MSMP must
provide a mechanism to disseminate not only the policy, but also the actual
list of approved group members to all access control decision points.

2.3.1.2 Rule-Based

Rule-based access control [9,10] relies on some set of preestablished
parameters known about each potential member of the group. A certificate
architecture infrastructure provides a framework to make rule-based access
control decisions. The asymmetrical signed certificates, signed by a
trusted entity, provide information about each individual.

An issue with rule-based access control is that the rule enforcement must be
consistent across the entire group. This is easily accomplished if a single
point is making all the access control decisions. However, with multiple
access control decisions being made by multiple members of the group, the
MSMP must provide a mechanism to disseminate the access control rules and
access control policy.

2.3.2 Key Dissemination Architectures

Just as there are different levels of data, there are different levels of
security (trust in the access control) that apply to a group. There is
a natural trade-off between how fast the group can be established and the
degree of assurance of the group. These two factors tend to oppose each
other in secure group management.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 13]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

In a small highly secure group, it may be desirable to have a single trusted
authority or a small subset of trusted authorities to control access to
the group key. This architecture leads to a very tightly controlled group.
Such groups have a very difficult time scaling for a large group.

Access control requirements and control of the group, may be relaxed to
allow some or all group members to disseminate the key based on the passing
of some rudimentary access control rules. This would result in an increase
in the speed of establishing an extremely large group.

In either instance, the host making access control decisions to the
cryptographic key needs to be trusted to make those decisions. The
definition of trust is up to the owners of the data. It could take the form
of formal computer security trust levels or it could be defined locally.

In summary, the MSMP must:

- Support configurable key dissemination architectures and protocols, and

- Conform to computer security trust requirements imposed by the
architecture.

2.3.3 Trust

The mechanisms used to support and implement a MSMP must be ``trusted''
which means that the mechanisms are responsible for enforcing security and
the level of security enforced by the system is dependent on the flawless
execution of these resources. If the MSMP must enforce trust policies,
it needs to be cognizant of the trust topology of its resources. If a
sub-group of routers has the necessary trust mechanisms to protect keys, it
is a candidate for a key dissemination protocol. However, this would impose
a trust topology on the multicast internet. Use of these trusted routers
would need management. The trust levels need monitoring (to verify the
trusted state is exists), and the list of trusted routers must be available
to all entities that desire to create groups.

To summarize, the MSMP must:

- Enforce policy concerning data protection and computer security trust
level;

- Maintain verification of the trusted state of "trusted" entities, in
accordance with data protection accreditation; and

- Maintain state information for its domain in order to know ``who'' to
trust.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 14]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

2.3.4 Authorization

Multicast groups require authorization of all important security actions.
The multicast protocols must provide a mechanism where each group member can
verify the identity of the entity asking it to perform important actions and
check this identity against a pre-stored list of permissions.

In peer security protocols, the authorization mechanism is relatively
simple. Each peer [6, 7] will make the decision to create a secure
session with another peer based upon the IP address or user ID of the
peer. Since there is direct communication between peers during secure
association establishment, there is perfect knowledge of the identity of the
communication partner.

In the case of MSMP, there is a requirement for a different authorization
mechanism. Group members, in many instances, accept a key as valid without
participating in the key's creation. There is a degree of trust on the
part of the group member that the key is valid and does indeed belong to the
group claimed.

A MSMP could fail if it does not have a full set of authorization
mechanisms. The SMKD protocol [8] is designed for core base trees
(CBT). The security protocol utilizes CBT routers to disseminate group
keys. The CBT routers all undergo a mutual suspicious exchange verifying
identities and authorization to receive the key. The group members strongly
authenticate themselves to the CBT routers when they request a group key.
However, the CBT routers do not strongly identify themselves to the group
members. Nor do the new members have information from a trusted source
authorizing the router to distribute the group key. In this protocol it
is conceivable that a CBT router could become a rogue router. When the
group member makes a request to join a group, the rouge router could give
it a bogus key for that group and create an entire sub-group with this bogus
key. It could trick members of the false group into communicating sensitive
information on the bad key. In short, not having a robust authorization
mechanism and utilizing the mechanism, could lead to masquerade attacks.

In summary, the MSMP must enforce authorization policy concerning group
establishment, key dissemination, rekey and compromise recovery.

2.3.5 Rekey Approach

Traditionally, a cryptographic key was treated as if it had a shelf life.
More accurately, a cryptographic key is changed when too much data was
protected by that single key. The most straightforward mechanism to achieve
this changeover is to cancel the old group and create new group in its place
containing all the old members. However, the creation of a cryptographic
group, especially a large one, is an arduous task requiring a great deal of
access control decisions, messages, processing and processing resources.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 15]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

This is a time consuming process. In many cases, it is preferable to
minimize the disruption of the communication group by sending out a single
message that will change the group's key. This process is called rekeying a
group.

When the rekey occurs, the single secure message containing the new group
key is created. That message is transmitted to the group. Included in
that message is some sort of cryptographic changeover time. This time
is far enough into the future that most, if not all, of the group members
are sure to receive the rekey message prior to changeover time. At that
cryptographic changeover time, all group members will switch to the new
cryptographic key for the group.

To allow for graceful transition between old and new group keys, there is
usually a short period of time when either key decrypts messages. This
allows messages that were in transmission, encrypted under the old group
key, to be received at their destinations and decoded immediately after
the cryptographic changeover time. However, all messages being sent after
crypto-changeover time use the new key for encryption.

Usually, only large groups securing critical communications use rekey. The
MSMP should support the concept of rekey particularly for critical groups
that cannot withstand an interruption in service.

2.3.6 Compromise

For the purpose of this discussion:

- A compromise is the loss of trust in an entity with access to keys.
This loss of trust (implies an assumption that the key has been
exposed) invalidates the key.

- A compromise is not an administrative decision to remove or replace an
entity with access to key. A loss of trust in that entity is not
assumed. Administrative decisions do not necessarily imply that the
key held by an entity is invalid.

The compromise of a secure group member is a more serious problem than the
discovery of a compromised member for pairwise secure communication. In
the case of pairwise communication, the secure association is deleted and
no further action need take place.

If a group member is compromised, the compromised member needs deletion
from the group, but at the same time the other group members need to be
able to continue their communications without a disruption of service.
The seriousness associated with disruption of service and the urgency of
removing a compromised member is a trade-off.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 16]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

There are several issues dealing with the handling of a compromised group
member that could lead to many requirements on the MSMP. The general goal
of dealing with a compromised group member is to return the group to a
secure state. This compromised entity is denied access to future group
information. Normally, one creates a separate group that includes all
members of the original group minus the compromised member.

This imposes several management requirements on the security management
protocol. The security management protocol must be able to either recognize
the compromise of a group member or accept a report that a group member is
compromised.

There are at least two separate means for dealing with compromises. One
mechanism recently put forth [10] replaces the compromise recovery keys
within the group. These keys split the group in such a manner that it
would be easy to send a single message to multiple group members to get
them on a new secure group transmission key. This mechanism would reduce
the amount of time needed to reconstitute the secure group, after discovery
of a compromise. However, this mechanism also requires management of these
compromised recovery keys and the storage of compromise recovery by all the
group members. Such a compromise recovery mechanism would be extremely
valuable in the case of long-term static groups. This is especially true
if the communications are critically important.

Another compromise recovery mechanism is simply to cancel the compromised
group and create a new group that is exactly equal to the old, minus
the compromised member. This mechanism has simplicity on its side, but
certainly is slower and causes more disruption to the group communications.

In short, the MSMP must enforce compromise recovery policy as defined at
group establishment.

2.4 Protocol Requirements

The multicast security protocol has requirements levied upon it based more
in the good design of a protocol rather than focused on the security aspects
of the protocol. The following sections attempt to catalog these design
goals.

2.4.1 Self Defined

The MSMP should provide a complete tool set for the management of keys and
security for cryptographic groups. It should generate and contain all the
information the protocol needs to function. The one possible exception
could be the certificate's infrastructure, if one is needed. In the case of
the certificate infrastructure, a very good case exists for the utilization
of existing infrastructures rather than trying to reinvent it. The MSMP

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 17]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

must:

- Provide mechanisms to allow group-wide enforcement of group policy, and

- Support existing certificate infrastructures.

2.4.2 Communications Protocol Independent

The MSMP should be independent of the communication system it is being
transmitted over and any protocol that it might be servicing. A majority of
the work done in this area has been under the auspices of the IPSEC Working
Group. However, the MSMP not only services IP layer security, but will also
serve session and application layer security. The MSMP will also reside on
hosts serviced by heterogeneous communication protocols. As an application
protocol itself, MSMP should be completely divorced from the nature of the
communication.

The MSMP should not target a specific communication protocol. However,
that does not mean that an option under the MSMP cannot target a specific
communication environment. For example, the general protocol could offer
an option for those systems that operate solely over ATM or CBT networks.
These homogeneous networks offer distinct advantages for a security
management protocol. A security management protocol could utilize a trusted
backbone of routers [8] to either set groups up more quickly or to ease the
recovery from a compromise. The MSMP should offer mechanisms that allow
customized protocols.

It is also important to realize that different cryptographic groups,
depending on their utilization, have different requirements and natures.
For instance, a large IP network may have the luxury to limit the number of
endpoints with identical keys, thereby limiting the scope of a compromise.
In other systems (e.g. cable system or especially those utilizing satellite
downfeeds), there is no capability to limit the scope of compromised keys by
limiting the size of key groups. The MSMP must:

- Remain independent of any specific communication protocol or
infrastructure;

- Support operation as a source to destination protocol; and

- Support homogeneous systems with optimized solutions.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 18]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

2.4.3 Architecture Independent

The MSMP should provide multicast security management regardless of the
environment it is serving. This protocol should satisfy at least 95 percent
of the security architectures that require secure keys.

For example, the MSMP should be able to support networks that push a group
key onto the end points and where the end points pull the group. A large
group could be built up of multiple cooperatives or it could simply be a
large commonly held group of symmetrical keys. Again, the MSMP should be
able to satisfy both cases. The MSMP should be configurable to support
extremely high security groups, even though they incur a degradation in
terms of speed. Conversely, it should be configurable to support groups
that trade high security for speed and ease of group establishment.

Obviously, a single scheme for creating secure groups and distributing
keys to those end points will not be adequate to satisfy all the different
architectures and environments the MSMP will be supporting. A single,
universally accepted, protocol construct is required that allows access to
sub-protocols optimized for different environments.

3 POLICY COMPONENTS

Security mechanisms and security protocols all enforce some policy or
policies within their domain. A clear definition of the enforced policies
is critical to the successful design and implementation of a security
protocol. The following section attempts to define policies that are being
enforced by the MSMP.

3.1 Security Policy

Security policy is a statement of the rules enforced by security mechanisms.
There are multiple rules the MSMP will be able to enforce. In a dynamic
system, groups define these policies based on the data that particular group
will protect.

The security policy can be static, and therefore assumed, or it can be
dynamic and tailored to the requirements of the group. A dynamic security
policy would allow the group owner to identify one or several key locations
as well as authorizing new group members as needed. If MSMP has a dynamic
security policy, a mechanism must define and disseminate this policy across
the group. The MSMP must understand the policy and verify the authorization
of that policy.

A group security policy will make statements about the key the group will

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 19]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

share. For example, it is reasonable to see a policy that identifies a key
for financial data. The MSMP must implement this policy across the group
uniformly.

3.2 Architecture

The more interesting policies MSMP will enforce involve the structure of
the group itself. The MSMP will enforce policy roles, key distribution
behaviors, access control, rekey, and compromise recovery.

3.2.1 Operational Policy

All of the proposed multicast security protocols [1, 2, 8] assumed a
structure of the key management protocol itself. A single entity creates
the key and makes it available for dissemination to group members. The
various proposals disagree about key dissemination, if routers are used to
make access control decisions, and how access control decisions are decided.

There is no reason that the MSMP need operate the exact same way as it
creates keys for different groups in different environments. A mechanism
that conveys to the MSMP the operational policies will facilitate a more
dynamic protocol.

3.2.2 Key Dissemination Policy

Another group policy is key dissemination. A single entity may create
the keys, but the key can be disseminated to the group members in several
manners. One key dissemination policy could be that a single trusted entity
performs all key dissemination and associated access control decisions.
This single point to dissemination policy is not performance oriented and
may not be acceptable for larger groups. Another policy is to delegate
responsibility for key dissemination to a subset of routers. This policy
assumes trusted routers. The trusted routers must protect the key and make
access control decisions in accordance with the sensitivity of the data
been protected. Yet another policy, is that any group member disseminates
the group key to any potential group member that meets a certain set of
criteria.

The particular policy for key dissemination is highly dependent on
the sensitivity of the data to be protected. Depending on the data
being protected, the same application could have a very different trust
requirement placed on the dissemination of key. The MSMP could change its
dissemination mechanisms or indeed its utilization of sub-protocols based on
a policy statement about key dissemination and trust requirements.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 20]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

3.2.3 Access Control Policy

Perhaps the most critical policy definition of the group is that of access
control. The access control policy defines the user or host that have
access to the cryptographic key. This policy can be identity- or rule-based
or a mixture of both. In any case, the access control policy must be
unambiguously stated so that only authorized group members receive the key.

There are several ways to define access control policy. It can be based
on a human identity, IP address, permission parameters, job title, or
company name. The requirement is that the parameter be unambiguous and
verifiable. The most common mechanism is a certificate. The information
in a certificate supports an access control decision because a trusted third
party verifies the accuracy of that information.

The MSMP could operate between multiple certificate infrastructures
providing there is a policy that clearly stated the acceptable certificate
parameters in each infrastructure. In short, the access control policy
states who should have access to the keys and the mechanisms used to prove
that.

3.2.4 Rekey Policy

As described in earlier sections, a rekey is a useful action when a
cryptographic key is of long duration or is protecting a great amount of
data. The decision to rekey is appropriate for any particular group and the
mechanism that rekey will utilize is the rekey policy.

Rekey involves the creation of the new group key and the creation of a
globally acceptable message to disseminate that key to all the current group
members. A single group entity needs to coordinate this process. After all
there can only be one valid group key at a time. The rekey policy would
need to state clearly the individual authorized to perform the rekey, the
time of the rekey, and the time allotted for graceful key changeover.

3.2.5 Compromise Policy

Compromise recovery policy involves several decisions. There is the
decision whether to pre-place a compromise recovery key hierarchy or to
delete and rebuild the group. Another decision, is who has the authority
to declare the group compromised and how was that decision communicated to
the group.

Perhaps the most difficult part about compromise recovery is discovering
the compromise. The rules for discovering a compromise and reporting it are
beyond the scope of this security protocol. However, the MSMP will need to

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 21]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

have the capability to accept notification that the group is compromised.
How that notification is communicated or utilized by the MSMP is a policy
decision. Compromise recovery key structures can be pre-placed in a secure
group along with the normal group encryption keys. However, the MSMP must
define the nature of the key structures' needs and pass it to the group at
the time of group establishment.

4 DESIGN RECOMMENDATIONS

The analysis and review of the MSMP requirements and policies have resulted
in two recommendations regarding the direction of the multicast security
effort. The first recommendation is to create a globally acceptable policy
mechanism that is accepted across the environments and would completely
define the cryptographic group. The second recommendation deals with the
design and implementation of the MSMP.

4.1 Global Policy Mechanism

One thing that became clear during the analysis of multicast group
requirements is that there are many policy decisions involved with
group establishment. The multicast environment, unlike the pairwise
environment where a peer-to-peer negotiation is uncomplicated, requires
more coordination between the group members. Certainly, a single group
member can make the cryptographic key. There are multiple ways the MSMP
could disseminate cryptographic key to the group. There is the issue of
whether or not the group needs a rekey and, if it does, how to orchestrate
the rekey. There is the whole issue of compromise recovery orchestration.
Many of these decisions are highly dependent upon the sensitivity of the
data, the duration of the group, and the criticality of the communication.

There is a strong argument for each of these options. The MSMP should be
capable of being configured to satisfy most environmental requirements.
Because the entire group needs a common policy and group definition, it
makes sense for a single mechanism to provide this information. It would
be best if this policy definition mechanism performed all MSMP configuration
actions. Hence, one recommended goal for the MSMP is that a single
mechanism is defined that will inform the MSMP of the group policy.

4.2 Limited Group of Security Mechanisms

The following recommendation deals with the protocol design and
implementation. A small subset of security protocols should be designed and
optimized for specific practical environments. These specialized protocols
come from a generally accepted group specification message.

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 22]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

This recommendation suggests a highly modularized MSMP with a small, fully
optimized, sub-protocol. There are benefits to doing this, including having
a universally accepted definition of multicast groups. The end points could
then either participate in a group (providing possession of the optimized
sub-protocol), go get the appropriate sub-protocol, or not join the group.
End systems could load those modules that are relevant to them and ignore
all the others. This leads to a protocol structure that works efficiently
for specific environments, provides universal protocol recognition, and
allows conservation of user resources.

>From the point of view of developing an international standard, the
modularized approach leads to a highly useful and efficient standard and
protocol. A high degree of interoperability exists due to the universally
accepted group definition. Each environment could have a the MSMP targeted
for that environment. Homogeneous environments could use CBT routers or
intermediate routers to distribute to key. Heterogeneous environments
could have the end systems generate group keys without the knowledge
of the routers. Extremely large unicast networks could utilize unique
communication infrastructures like group set-up servers. Extremely high
security systems could include a compromise recovery key structure.

4.3 Policy Decomposition Of Multicast Protocols

The following table illustrates how some multicast protocols would decompose
into the policy components previously identified. Each protocol makes
different assumptions of it's environment and those assumptions lead to
different policies. Yet, these policies can be represented using the same
decomposition format.

GKMP

Operational - Certificate Infrastructure ID, Group Controller IP address:
a.b.c, Group 1st member IP address: a.b.c.d, Group Owner Common Name: X,

Dissemination - Group Controller only (push or pull) or any member

Access Control - Mutual suspicious, IP address list or Rules: IP a.b.*,
Common Name: *.acme.com

Rekey - Token required, uses GKEK sent during group establishment

Compromise Recovery - Destroy group, create new, with certificate revocation
capability during establishment

SMKD

Operational - CBT routers relays key, routers undergo rigorous
authentication

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 23]

INTERNET-DRAFT MSMP Requirements and Policy March, 1999

Dissemination - Download from responding CBT router

Access Control - Host sends signature to router

Rekey - NA

Compromise Recovery - Destroy group, create new

Harney/Harder draft-harney-sparta-msmp-sec-00.txt [Page 24]