Internet Engineering Task Force Patrick McDaniel (U.of Michigan)
INTERNET-DRAFT Hugh Harney (Sparta)
draft-irtf-smug-mcast-policy-01.txt Peter Dinsmore (NAI Labs)
November 2000 Atul Prakash (U.of Michigan)
Multicast Security Policy
<draft-irtf-smug-mcast-policy-01.txt>
Status of this memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
Security is increasingly becoming a concern in applications built on
multi-party communication. Centrally, protection of the application
content from non-authorized or malicious parties is the fundamental
goal of any security policy specification. This draft seeks to
illuminate the design space of secure multicast communication
policy. The security requirements of existing application policies
are intended to be addressable by these policy dimensions. It is
from an understanding of policy design space that the mechanisms for
policy specification and enforcement can be derived.
Table of Contents
1. Introduction
Although security policy is an oft mentioned component of security
infrastructures, no single definition has been found to address the
needs of all parties and environments. One working definition
defines policy as:
``.. the group security relevant behaviors, access control
parameters, and security mechanisms.'...'' [HCH+00]
This definition best fits the viewpoint of policy as defining how
McDaniel, Harney, Dinsmore, and Prakash [Page 2]
security defines group behavior, who are the entities allowed to
participate, and which mechanisms will be used to achieve mission
critical goals. For the purposes of this document, we will accept
these dimensions as defining the relevant properties of secure
multicast policy.
A group security context is the set of keys, members, protocols, and
algorithms used to secure a singular group communication. A policy
defines (directly or indirectly) how the security context should be
derived. A policy framework defines the entities and protocols used
to define, interpret, negotiate, and distribute a secure group
policy.
Once an understanding of what constitutes a policy is obtained, the
natural question of policy specification arises. This question
speaks to the requirements of both the representation and
interpretation of policy, and the means by which policy is
distributed and authenticated.
The central aims of this document are the definition of a group
model and an investigation of the dimensions along which policy may
be defined in secure multiparty communication. The group model
should be comprehensive and flexible; the requirements of arbitrary
group communication security should be expressible and achievable.
In this model, we attempt to identify those dimensions of policy
relevant to secure multicast. This document does not seek to
identify specific solutions or mechanisms for providing group
security policy specification and enforcement, leaving this to other
future documents.
The remainder of this section describes the major components and
challenges of secure group policy. The following two subsection
describe a major distinction between group and local policy upon
which the model defined in this document rests. The issues of
policy specification and negotiation are briefly described in
subsequent sections.
1.1 Group Policy
A group policy defines the behavior of the group. Included in this
definition is the types of security guarantees provided to the
participants, the ways in which the guarantees are provided and the
definition of the relationships between the group participants.
1.2 Local Policy
Obtained from the local environment, a local policy defines the
requirements and credentials of the local entities. Upon receiving
the group policy, both the group and local policies should be
reconciled. Irreconcilable conflicts (see negotiation below)
requires the local host abstain from participation in the group.
In addition to specifying minimal standards for group behavior, the
McDaniel, Harney, Dinsmore, and Prakash [Page 3]
local policy should identify which identities or credentials should
be accepted as authoritative. In the case of identities, an
authentication method should also be defined.
1.3 Policy Specification
Once agreement has been reached on the policy dimensions that will
be supported by a policy framework the issue of specification
arises. A policy specification language defines both how a policy
is represented and the rules with which the representation is
interpreted. The following text outlines several design goals of
the policy representation.
The policy language should be unambiguous. Because a policy will be
interpreted by host software, the mapping of the policy to mechanism
and credentials must be deterministic.
The policy language should be succinct. The costs associated with
policy distribution is likely to be a key determinant in the success
of the policy framework. As such, the language should be designed
to be represented in as small a electronic format as possible.
The policy language should be clear. A requirement of the SMuG
architecture is that policy definitions must originate from security
personnel which may or may not be directly involved in application
development. Thus, the ability to relate the representation to real
world objects is a goal. Where possible, a policy representation
should be human readable.
1.4 Policy Negotiation
Reconciliation, possibly through participant negotiation, of local
and group policy is a key task of the SMuG framework. A open issue
is the extent to which a group policy may be altered during this
negotiation. Secure multicast groups may be large and extend over
several administrative domains. Thus, the potentially competing
requirements of group members must be weighed in creating a single,
coherent group security policy.
1.5 Related Documents
This informational document is intended to motivate the design of
the Secure Multicast Research Group [SMuG] secure multicast
architecture [HCBP99,CCP+99]. Specifically, this document intends
to identify potential policies that may be supported by the SMuG
secure multicast framework through the policy framework (problem
area 3). This should also serve as an informal policy requirements
specification for the management of keying material (problem area 2)
and multicast data handling (problem 1) layers of the SMuG
architecture. A more detailed document defining the requirements of
the policy framework is the subject of a future draft. A taxonomy
of issues relating to the SMuG framework can be found in [CP99].
McDaniel, Harney, Dinsmore, and Prakash [Page 4]
A secondary goal of this document is a requirements definition for
the framework policy specification language. In this, we intend to
outline a general model which can be used as the basis of policy
specification. While the specifics of the policy language are not
stipulated, we expect that future documents will realize this model
in defining an electronic policy representation.
1.6 Document Organization
The remainder of this document is as follows. Section 2 defines a
group model through a specification of the actions and roles of
group participants. Section 3 describes the potential dimensions on
which policy may be defined, and identifies those policies required
for secure multicast communication.
2. Group Model
This section outlines the group model under over which we define
policy, and is much motivated by the emerging GSAKMP protocol
[HCH+00]. In this model, the defining characteristic of a group is a
statement of rights associated with roles assumed by group members.
A role defines the rights and responsibilities of any group member
assuming that role. In gaining access to the group, a group member
must assume one or more roles. External entities may serve as roles
within the group. In this view, the task of the policy framework is
the specification and distribution of role definition, the means and
specifics of role access control, and rules guiding the realization
of these role defined activities in the underlying mechanisms.
To motivate (one definition) of roles, we present an enumeration of
activities relating to the management of a group security context.
## Action Description
-- ------------------- ------------------------------------------
1 key creation right to create a session key, or to
generate rekeying material
2 key dissemination This right allows a member to distribute
keying material.
3 rekey action right to initiate a group rekey.
initiation
4 key access right to gain access to the session key
5 policy creation right to create/assert a group policy
6 policy modification right to modify the group policy
7 grant rights right to grant rights to members/entities
external to the policy
McDaniel, Harney, Dinsmore, and Prakash [Page 5]
8 authorize member right to authorize/state authenticity of
group member
9 admit member right to admit a member to the group
10 eject member right to remove a member from the group
11 audit group right to monitor access control messages or
membership information
Tables 1 and 2 describe the set of access rights and roles assumed
by group participants. This description of roles and rights is
intended to be informational. Particular instantiations of the SMuG
framework may define roles and rights as appropriate for their
purposes. We describe the meaning of each role in the following
subsections.
------------------------------------------------------------------
# Role Access Rights
- ---------------------------- ------------------------
1 group owner 5, 6, 7, 11
2 group key authority 1, 2, 3, 4, 11
3 group membership authority 8, 9, 10
4 member 4
Table 1 - Role Access Rights
------------------------------------------------------------------
The following subsections describe the purpose, rights, and
responsibilities of the group roles defined in Table 1.
2.2.1 Group Owner
The group owner is the initiator of the group and controls the
policy for the group. The group owner is the entity that states
rules for admittance and determines the behavior of the group
(policy). Also, it must identify the authorities that perform the
various management duties for the group. Note that the group owner
may or may not be a member of the group.
2.2.2 Group Key Authority
The group key authority is the controller of keying actions within
the group. As such, this entity creates and coordinates the
distribution of all session keys and related keying material. The
entities to which keying material will largely be driven by
information received from the group membership authority. Note that
McDaniel, Harney, Dinsmore, and Prakash [Page 6]
the group key authority need not be a member of the group or
distinct from the group owner.
2.2.3 Group Membership Authority
The group membership authority is the controller of membership
actions within the group. As such, this entity authorizes and
admits the members of the group. The means used to perform these
actions is dependent on the policy stated by the group owner. Note
that the group key authority need not be a member of the group.
2.2.4 Member
A group member is a participant in the group. The right to access
the session key implies the ability to both send and receive
messages within the group. Obviously, the member is required to be
a member of the group. Note that a member specifically does not
have any rights to monitor the group control messages or membership.
If needed, these rights may later be granted through the definition
of a new role.
3. Policies
3.1 Group Policy
A group policy defines group services and participant roles to be
implemented by the group. The central goal of the SMuG policy
framework (problem area 3) is to provide services for specification,
distribution, and negotiation of the group policy.
As defined by roles (see section 2.2 above), specification of the
group policy is to be performed by some authorized entity. The
group policy is to be distributed to joining members by policy
distribution points (see [CCP+99]). The mechanism and architecture
of the specification and distribution mechanism is beyond the scope
of this document.
The following subsections define several dimensions along which a
group policy may be defined.
3.1.1 Rekeying Policy
A common strategy to support secure group communication among
trusted members is to use a common symmetric session key (e.g. GKMP
[HMR97a,HMR97b], GSAKMP [HCH+00], Antigone [MPH99], DCCM [DBH+00]).
An important policy issue for a group communication application is
deciding when a session must be rekeyed, i.e., the old session key
is discarded and a new session key is sent to all the members. This
policy is likely to drive much of the key management activities of
the key management protocols [HBH00].
A rekeying policy defines how and when session keys are created and
(re)distributed. The management of the session keys is a central
McDaniel, Harney, Dinsmore, and Prakash [Page 7]
determinant of the security afforded by the resulting session. As
such, the rekeying policy drives many subsequent policy and
mechanism related decisions.
Associated with each rekeying policy is a number of properties which
define the security guarantees being provided to the group. Several
properties of the session keying include:
session key independence - no meaningful information about one
session can be derived from another.
perfect forward secrecy (PFS)- the property that a session key
provides no meaningful information about future session keys.
membership forward secrecy (MFS) - the property that a member
leaving the group cannot obtain meaningful information about
future group communication.
perfect backward secrecy (PBW) - the property that a session key
provides no meaningful information about past session keys.
membership backward secrecy (MFS) - the property that a member
joining the group cannot obtain meaningful information about past
group communication.
failure secrecy - the property that a failed process can not
continue to actively or passively participate in the group. The
means in which failures are detected and reported is beyond the
scope of this document.
compromise secrecy - the property that a compromised process can
not continue to actively or passively participate in the group.
The means in which compromises are detected and reported is
beyond the scope of this document.
limited lifetime - the property that a session key has maximum
lifetime (which may be measured in time, bytes transmitted, or
some other globally measurable metric of group communication).
Similarly, the mechanism used to create session keys may have the
following properties:
contributory keying - the property that each group member
participate in the creation of the session key.
centralized keying - converse to contributory keying, this
property requires that (only) one or more trusted parties
contribute to the creation of the key.
These properties are realized in some combination of key creation
algorithm and rekeying protocols. The definition of these
algorithms, protocols, and the (policy to mechanism) mapping
function is beyond the scope of this document. The Antigone system
McDaniel, Harney, Dinsmore, and Prakash [Page 8]
[MPH99] investigates the means by which policy may be mapped into
mechanisms.
Support for some or all of the rekeying policies defined in this
section is a requirement of the SMuG Policy framework.
A representation of a rekeying policy may be the set of properties
which the rekeying mechanism is required to provide. Each property
may require additional policy specification and mechanisms. To
illustrate this point, we describe the features and requirements of
two policies mentioned above.
3.1.1.1 Membership Forward Secrecy
A membership forward secrecy policy is useful in secure conferencing
applications. The content of conferencing application is often
driven by the members of the group. (e.g. The content of a sales
meeting may need to be protected from suppliers who have exited the
session.)
In membership forward secrecy, The group is required to protect
content from members of past security contexts. Therefore, any
rekeying mechanism and protocol supporting an MFS policy must
provide the following features:
a) protection of the LEAVE process (reliable, authenticated, and
timely)
b) rekey after every group member LEAVE
c) provide PFS rekeying
It is immediately obvious MFS may be both be difficult to provide
and expensive. Thus, MFS policies may be incompatible with large or
highly dynamic groups. Support for MFS in the secure multicast
framework may not be required.
3.1.1.2 Limited Lifetime
Limited lifetime rekeying can be useful in a secure on-line
subscription service. Paying members would periodically be sent a
new key that is valid until the next subscription interval. The
GKMP [HMR97a,HMR97b] protocol implements a time-sensitive rekeying
policy (albeit without the session key independence required by the
this example). Limited lifetime rekeying without independence
provides (primarily) protection against cryptanalysis of the session
key. The MARKS system [Bri99] provides an efficient means of
supporting limited lifetime rekeying within arbitrarily large groups.
Where limited lifetime rekeying is used, the metric used to measure
key lifetime and the threshold at which rekeying is required must be
stated in the group policy. Mechanisms implementing this policy
must support the measurement of key lifetime and periodic PFS
rekeying.
McDaniel, Harney, Dinsmore, and Prakash [Page 9]
Limited lifetime rekeying is supported by the vast majority of
existing secure multicast and group communication frameworks. The
mechanism requirements of this policy are simple and strait-forward.
Finally, to avoid cryptanalysis of session keys, periodic rekeying
is a good security practice. Thus, support for limited lifetime
rekeying is a likely requirement of the SMuG policy framework.
3.1.2 Access Control Policy
An access control policy states the identities/credentials, rights
and responsibilities of each member of the group. Access control in
our current group model is defined by the roles assumed by group
participants. The specification, meaning, and mechanisms for
assuming these roles is as defined above in section 2.2.
Support for role defining access control policy is a requirement for
the SMuG policy framework.
3.1.3 Data Security Policy
The canonical security policy, a data security policy states the
security guarantees provided to application level messages. This
policy is likely to directly or indirectly state the data transforms
defined by the SMuG problem area 1 group [CRC00] used to secure
group messages. Several data security guarantees include;
confidentiality - Guarantee stating that no member outside the
group can obtain the contents of a group message.
integrity - Guarantee stating that any modification of a group
message during transmission is detectable by the receiver.
group authentication - Guarantee stating that a received message
was transmitted by some member of the group. This is typically a
byproduct of other (data security) guarantees.
source authentication (or sender authentication) - Guarantee
stating that the sender of a message can be uniquely identified.
Providing this guarantee in an efficient and scalable way is an
open issue. However, recent developments by Perrig et. al.
[PSTC00] outline several promising solutions for providing
efficient sender authentication.
non-repudiation - Guarantee stating that a sender should not be
able to falsely deny sending a previously transmitted message.
anonymity - Guarantee stating that the originator of a message
cannot be ascertained by receivers (or by outside parties).
The cryptographic algorithms and used to provide these guarantees
have varying strength and performance characteristics. As such, a
data-security policy should be able to state the algorithm(s) that
may used to provide data security. A result of the selection of
McDaniel, Harney, Dinsmore, and Prakash [Page 10]
cryptographic algorithms leads to the following kinds of secrecy:
ephemeral secrecy - the data be protected for (only) a short
period after transmission. That is, the algorithm should prevent
easy access to content, but strong guarantees are not required.
One example, from [CP99] is:
[... to maintain ephemeral secrecy when transmitting a video it
is sufficient to encrypt only the low-order Fourier coefficients
in an MPEG encoding.]
long-term secrecy - requirement that the transmitted data be
protected for an indefinite period after transmission. This
requires strong cryptographic algorithms.
A "cipher-suite" is one or more cryptographic algorithms used to
implement data related guarantees. The policy specification should
allow, at a minimum, cipher suite definitions that support the
specification of acceptable algorithm parameters and modes.
Additionally, the suite definition should indicate the guarantees
for which the suite should be used.
Support for some, if not all, data security policies is a
requirement of the SMuG policy framework. A definition of the
supported cipher suites should be developed by the multicast data
transform specifications (level 1).
3.1.4 Member-Data Policy
A member-data policy indicates the availability of group membership
information, states guarantees of the accuracy of this information,
and identifies the mechanism used for its distribution.
Identification of the membership within a group session is an
important requirement for a large class of applications. As
evidenced by a number of group communication systems, achieving
strong guarantees for the availability and correctness of group
membership can be costly. Several member-data policies worth
considering are:
best-effort member-data - In this policy, membership data will be
delivered as available. No guarantees about the accuracy or
timeliness of this information are provided. However,
due-diligence should be expended in providing accurate membership
data.
positive member-data - This policy guarantees that all members in
the membership data are actively participating in the group. That
is, a listed member is guaranteed to be receiving data and has not
failed (see below, in Failure Policy 3.1.6, for a definition of a
process failure).
negative member-data - This policy guarantees that every member of
McDaniel, Harney, Dinsmore, and Prakash [Page 11]
the current security context is listed in the membership data.
perfect member-data - This policy guarantees that all members in
the membership data actively participating in the group, and that
every member of the current security context is listed in the
membership data. That is, both positive and negative member-data
is provided.
A related policy is confidentiality of group membership. In
general, hiding the group membership information from members and
non-members is difficult to do in current networks. This is
primarily because the ability to monitor messages on the network
allows access to the source and destination of packets (in case of
unicasts) and at the multicast tree (in case of IP multicasts). In
mounting this traffic analysis attack, an adversary may deduce a
close approximation of group membership.
It is unclear if member-data policies are within the scope of the
SMuG framework. However, we note that the availability of accurate
membership information is a pre-requisite of some reliable multicast
solutions being discussed by the Reliable Multicast Research Group
[RM].
3.1.5 Compromise Policy
A compromise policy identifies the types of compromises to be
detected, the means by which they are reported, and the mechanism
used for recovery. Compromise related algorithms may or may not be
protocol and keying algorithm dependent. Further investigation of
the requirements of these policies is required.
It is unclear if compromise detection and recovery is within the
scope of the SMuG framework.
3.1.6 Failure Policy
A failure policy defines what kinds of (member) failures are to be
detected and the mechanisms used for failure detection, reporting,
and recovery. The definition of a failure policy should be derived
from a process "crash model". As defined in [Mul93], traditional
crash models include;
fail-stop - The failed process immediately and permanently stops
sending and receiving messages. The vast majority of secure group
and multicast frameworks and protocols assume a fail-stop failure
model, if any.
message-omission - The failed process will not receive or send
(omit) an arbitrary number of messages.
Byzantine - The failed process can exhibit any behavior
whatsoever. A failed process in a Byzantine failure model should
be assumed to be actively attempting to circumvent the security of
McDaniel, Harney, Dinsmore, and Prakash [Page 12]
the group. As demonstrated in RAMPART [Rei94] system, known
mechanisms providing protection from Byzantine failures are both
expensive and complex. Note that mechanisms used to combat
Byzantine failures are often similar to compromise recovery
algorithms.
Systems supporting failure detection and recovery techniques found
in survivability and distributed systems literature typically do not
address security. Thus, the integration of these services with a
security infrastructure requires careful design and analysis. It is
unclear if these policies should be addressed by the SMuG framework.
3.1.7 Domain Dependent Policy
A domain dependent policy dictates ways in which the security
context may be effected by forces external to secure multicast
services. Such a policy would specify the modification of group
behavior in response to the observation of an external event or
state.
An example of a domain dependent policy is the modification of group
access rights during a launch window. At the Kennedy Space Center
(NASA), monitoring devices on the space shuttle continuously
transmit data to a number of monitoring applications. Outside a
launch window, the applications may alter configuration or test
devices as needed. During the launch window, these devices transmit
monitoring data, but access to configuration and testing interfaces
is prohibited. One group (domain dependent) policy supporting the
requirements of this environment would state that no application
should be able to send to the group during the launch window.
Another policy would outright prohibit the (testing) applications
from participating in the group during a launch window.
Developing an enumeration of all potential domain dependent policies
is infeasible. Thus, if supported, flexible interfaces for
reporting external events and state must be provided. An open issue
are the security requirements for the event detection and state
assessment mechanisms. A second issue is the support of domain
dependent roles (such as the application role in the above example).
At a minimum, it seems necessary for the secure multicast group to
provide interfaces to secure group related activities. Such
activities may include (but are not restricted to); initiate
rekeying, member ejection, and compromise recovery.
3.2 Local Policy
A local policy states the security and performance requirements of
the local infrastructure on the SMuG framework. The mechanism used
for the specification and distribution of local policy is beyond the
scope of this document.
The following subsections define several dimensions along which a
McDaniel, Harney, Dinsmore, and Prakash [Page 13]
local policy may be defined.
3.2.1 Infrastructure Policy
An infrastructure policy identifies the locally trusted entities and
indicates which mechanisms may be used to obtain other credentials.
In this, a statement of what groups the host is allowed to join may
be implicitly specified.
Typically, this policy is used to identify the identity, location,
and mechanism of locally held credentials (e.g. long term keys). It
is from these credentials that access to the group services will be
likely be obtained. An example policy of this type may identify a
file in the local filesystem that contains a long term key. Note
that the means in which the contents of the file is interpreted must
also be specified.
Conversely, the infrastructure will also state the means in which
the identities and credentials received from the group will be
verified (.e.g. location of locally trusted CA). The identity of
trusted framework components (e.g. policy distribution points) may
also be specified.
Support for infrastructure policy is a requirement of the SMuG
framework.
3.2.2 Policy Requirements
This policy state the minimum services a host will accept. In this,
it may state the following requirements of any group:
trusted entities - This policy states which parties may assume
roles within the group. For example, one policy may state that a
local process may only join groups whose key controller is a
specific host (e.g. antigone.citi.umich.edu).
data security policies - This policy requires that groups provide
particular data security policies.
others - In general, any policy expressible in the group policy
should be able to be stated as a policy requirement.
Policy requirements are likely to drive any policy negotiation
process. Converging on a set of services that meet the requirements
of all members is an open issue.
Support for policy requirements is a requirement of the SMuG
framework.
4. References
[Bri99] Bob Briscoe, "MARKS: Zero Side-Effect Multicast Key
Management Using Arbitrarily Revealed Key Sequences", In Proceedings
McDaniel, Harney, Dinsmore, and Prakash [Page 14]
of First International Workshop on Networked Group Communication,
November 1999.
[CCP+99] R. Canetti, P-C. Cheng, D. Pendarakis, J.R. Rao, P.Rohatgi
and D. Saha, "An Architecture for Secure Internet Multicast",
Internet Engineering Task Force, February 1999,
draft-irtf-smug-sec-mcast-arch-00.txt (Draft).
[CP99] R. Canetti and B. Pinkas, "A Taxonomy of Multicast Security
Issues (updated version)", Internet Research Task Force, April,
1999, draft-irtf-smug-taxonomy-01.txt (Draft).
[CRC00] Ran Canetti, Pankaj Rohatgi, and Pau-Chen Cheng, "Multicast
Data Security Transformations: Requirements, Considerations, and
Prominent Choices", Internet Engineering Task Force, May 2000,
draft-data-transforms.txt (Draft).
[DBH+00] P. Dinsmore, D. Balenson, M. Heyman, P. Kruus, C Scace, and
A. Sherman "Policy-Based Security Management for Large Dynamic
Groups: A Overview of the DCCM Project", In Proceedings of DARPA
Information Survivability Conference and Exposition (DISCEX '00),
pages 64-73, DARPA, January 2000.
[HBH00] H. Harney, M. Baugher, and T. Hardjono, "GKM Building
Block: Group Security Association (GSA) Definition", Internet
Engineering Task Force, February 2000,
draft-irtf-smug-gkmbb-gsadef-00.txt (Draft).
[HCBP99] T. Hardjono, R. Canetti, M. Baugher and P. Dinsmore,
"Secure Multicast: Problem Areas, Framework, and Building Blocks",
Internet Engineering Task Force, October, 1999,
draft-irtf-smug-framework-00.txt (Draft)
[HCH+00] H. Harney, A Colegrove, E. Harder, U. Meth, and
R. Fleischer, "Group Secure Association Key Management Protocol",
Internet Engineering Task Force, May 2000,
draft-harney-sparta-gsakmp-sec-01.txt (Draft)
[HMR97a] Harney, Hugh, Carl Muckenhirn, and Thomas Rivers, "Group
key management protocol (GKMP) architecture," Request for Comments
(RFC) 2094, Internet Engineering Task Force (July 1997).
[HMR97b] Harney, Hugh, Carl Muckenhirn, and Thomas Rivers, "Group
key management protocol (GKMP) specification," Request for Comments
(RFC) 2093, Internet Engineering Task Force (July 1997).
[MPH99] P. McDaniel, A. Prakash and P. Honeyman, "Antigone: A
Flexible Framework for Secure Group Communication", In Proceedings
of the 8th USENIX Security Symposium, pages 99-114, August, 1999
[Mul93] Sape Mullender. Distributed Systems. Addison-Wesley, First
edition, 1993.
McDaniel, Harney, Dinsmore, and Prakash [Page 15]
[PSTC00] A. Perrig, D. Song, D. Tygar, and Ran Canetti, "Efficient
Authentication and Signature of Multicast Streams over Lossy
Channels" In Proceedings of 2000 IEEE Symposium on Security and
Privacy, IEEE, May 2000, (to appear).
[Rei94] M. Reiter. "Secure Agreement Protocols: Reliable and Atomic
Group Multicast in Rampart". In Proceedings of 2nd ACM Conference
on Computer and Communications Security, pages 68-80. ACM, November
1994.
[RM] The Reliable Multicast Research Group, Internet Research
Engineering Task Force. URL: http://www.east.isi.edu/rm/
[SMuG] Secure Multicast Research Group, Home Web Site,
URL: http://www.ipmulticast.com/community/smug/
Authors' addresses:
Patrick McDaniel
Department of Electrical Engineering and Computer Science
University of Michigan
3115 EECS Building
1301 Beal Avenue
Ann Arbor, MI 48109
pdmcdan@eecs.umich.edu
Hugh Harney
Sparta
9861 Broken Land Parkway
Columbia, MD 21046
(410) 381-9400 x203
hh@sparta.com
Peter Dinsmore
NAI Labs
3060 Washington Road,
Glenwood, MD 21738
(443) 259-2346
Pete_Dinsmore@NAI.com
Atul Prakash
Department of Electrical Engineering and Computer Science
University of Michigan
2231 EECS Building
1301 Beal Avenue
(734) 763-1585
aprakash@eecs.umich.edu
----------------------------------------------------------------------------