authentication algorithm and parameters, the group authentication
algorithm and parameters, and/or replay protection information.
7. Scalability Considerations
The area of group communications is quite diverse. In
teleconferencing, a multipoint control unit (MCU) may be used to
aggregate a number of teleconferencing members into a single session;
MCUs may be hierarchically organized as well. A loosely coupled
teleconferencing session [RFC3550] has no central controller but is
fully distributed and end-to-end. Teleconferencing sessions tend to
have at most dozens of participants. However, video broadcast that
uses multicast communications and media-on-demand that uses unicast
are large-scale groups numbering hundreds to millions of
participants.
As described in the Requirements section, Section 2, the group key
management architecture supports multicast applications with a single
sender. The architecture described in this paper supports large-
scale operation through the following features.
1. There is no need for a unicast exchange to provide data keys to a
security protocol for members who have previously registered in
the particular group; data keys can be pushed in the rekey
protocol.
2. The registration and rekey protocols are separable to allow
flexibility in how members receive group secrets. A group may use
a smart-card based system in place of the registration protocol,
for example, to allow the rekey protocol to be used with no back
channel for broadcast applications such as television conditional
access systems.
3. The registration and rekey protocols support new keys, algorithms,
authentication mechanisms and authorization infrastructures in the
architecture. When the authorization infrastructure supports
delegation, as in X.509 and SPKI, the GCKS function can be
distributed as shown in Figure 3 below.
The first feature in the list allows fast keying of data security
protocols when the member already belongs to the group. While this
is realistic for subscriber groups and customers of service providers
who offer content events, it may be too restrictive for applications
that allow member enrollment at the time of the event. The MSEC
group key management architecture suggests hierarchically organized
key distribution to handle potential mass simultaneous registration
requests. The Figure 3 configuration may be needed when conventional
clustering and load balancing solutions of a central GCKS site cannot
meet customer requirements. Unlike conventional caching and content
distribution networks, however, the configuration shown in Figure 3
has additional security ramifications for physical security of a
GCKS.
+----------------------------------------+
| +-------+ |
| | GCKS | |
| +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| +-------------+ |
| | | |
| v ... v |
| +-------+ +-------+ |
| | GCKS | | GCKS | |
| +-------+ +-------+ |
| | ^ |
| | | |
| | +---------------+ |
| | ^ ^ |
| | | ... | |
| | +--------+ +--------+ |
| | | MEMBER | | MEMBER | |
| | +--------+ +--------+ |
| v |
| ... |
+----------------------------------------+
Figure 3: Hierarchically Organized Key Distribution
More analysis and work is needed on the protocol instantiations of
the group key management architecture, to determine how effectively
and securely the architecture can support large-scale multicast
applications. In addition to being as secure as pairwise key
management against man-in-the-middle, replay, and reflection attacks,
group key management protocols have additional security needs.
Unlike pairwise key management, group key management needs to be
secure against attacks by group members who attempt to impersonate a
GCKS or disrupt the operation of a GCKS, as well as by non-members.
Thus, secure groups need to converge to a common group key when
members are attacking the group, joining and leaving the group, or
being evicted from the group. Group key management protocols also
need to be robust when DoS attacks or network partition leads to
large numbers of synchronized requests. An instantiation of group
key management, therefore, needs to consider how GCKS operation might
be distributed across multiple GCKSs designated by the group owner to
serve keys on behalf of a designated GCKS. GSAKMP [GSAKMP] protocol
uses the policy token and allows designating some of the members as
subordinate GCKSs to address this scalability issue.
8. Security Considerations
This memo describes MSEC key management architecture. This
architecture will be instantiated in one or more group key management
protocols, which must be protected against man-in-the-middle,
connection hijacking, replay, or reflection of past messages, and
denial of service attacks.
Authenticated key exchange [STS,SKEME,RFC2408,RFC2412,RFC2409]
techniques limit the effects of man-in-the-middle and connection
hijacking attacks. Sequence numbers and low-computation message
authentication techniques can be effective against replay and
reflection attacks. Cookies [RFC2522], when properly implemented,
provide an efficient means to reduce the effects of denial of service
attacks.
This memo does not address attacks against key management or security
protocol implementations such as so-called type attacks that aim to
disrupt an implementation by such means as buffer overflow. The
focus of this memo is on securing the protocol, not on implementing
the protocol.
While classical techniques of authenticated key exchange can be
applied to group key management, new problems arise with the sharing
of secrets among a group of members: group secrets may be disclosed
by a member of the group, and group senders may be impersonated by
other members of the group. Key management messages from the GCKS
should not be authenticated using shared symmetric secrets unless all
members of the group can be trusted not to impersonate the GCKS or
each other. Similarly, members who disclose group secrets undermine
the security of the entire group. Group owners and GCKS
administrators must be aware of these inherent limitations of group
key management.
Another limitation of group key management is policy complexity.
While peer-to-peer security policy is an intersection of the policy
of the individual peers, a group owner sets group security policy
externally in secure groups. This document assumes there is no
negotiation of cryptographic or other security parameters in group
key management. Group security policy, therefore, poses new risks to
members who send and receive data from secure groups. Security
administrators, GCKS operators, and users need to determine minimal
acceptable levels of security (e.g., authentication and admission
policy of the group, key lengths, cryptographic algorithms and
protocols used) when joining secure groups.
Given the limitations and risks of group security, the security of
the group key management registration protocol should be as good as
the base protocols on which it is developed, such as IKE, IPsec, TLS,
or SSL. The particular instantiations of this group key management
architecture must ensure that the high standards for authenticated
key exchange are preserved in their protocol specifications, which
will be Internet standards-track documents that are subject to
review, analysis, and testing.
The second protocol, the group key management rekey protocol, is new
and has unknown risks. The source-authentication risks described
above are obviated by the use of public-key cryptography. The use of
multicast delivery may raise additional security issues such as
reliability, implosion, and denial-of-service attacks based upon the
use of multicast. The rekey protocol specification needs to offer
secure solutions to these problems. Each instantiation of the rekey
protocol, such as the GSAKMP Rekey or the GDOI Groupkey-push
operations, need to validate the security of their rekey
specifications.
Novelty and complexity are the biggest risks to group key management
protocols. Much more analysis and experience are needed to ensure
that the architecture described in this document can provide a well-
articulated standard for security and risks of group key management.
9. Acknowledgments
The GKM Building Block [GKMBB] I-D by SMuG was a precursor to this
document; thanks to Thomas Hardjono and Hugh Harney for their
efforts. During the course of preparing this document, Andrea
Colegrove, Brian Weis, George Gross, and several others in the MSEC
WG and GSEC and SMuG research groups provided valuable comments that
helped improve this document. The authors appreciate their
contributions to this document.
10. Informative References
[BatchRekey] Yang, Y. R., et al., "Reliable Group Rekeying: Design
and Performance Analysis", Proc. ACM SIGCOMM, San
Diego, CA, August 2001.
[CLIQUES] Steiner, M., Tsudik, G., and M. Waidner, "CLIQUES: A
New Approach to Group Key Agreement", IEEE ICDCS 97,
May 1997
[FN93] Fiat, A. and M. Naor, "Broadcast Encryption, Advances
in Cryptology", CRYPTO 93 Proceedings, Lecture Notes
in Computer Science, Vol. 773, pp. 480-491, 1994.
[GKMBB] Harney, H., M. Baugher, and T. Hardjono, "GKM
Building Block: Group Security Association (GSA)
Definition," Work in Progress, September 2000.
[GSAKMP] Harney, H., Colegrove, A., Harder, E., Meth, U., and
R. Fleischer, "Group Secure Association Key
Management Protocol", Work in Progress, February
2003.
[GSPT] Hardjono, T., Harney, H., McDaniel, P., Colegrove,
A., and P. Dinsmore, "The MSEC Group Security Policy
Token", Work in Progress, August 2003.
[H.235] International Telecommunications Union, "Security and
Encryption for H-Series (H.323 and other H.245-based)
Multimedia Terminals", ITU-T Recommendation H.235
Version 3, Work in progress, 2001.
[JKKV94] Just, M., Kranakis, E., Krizanc, D., and P. van
Oorschot, "On Key Distribution via True
Broadcasting", Proc. 2nd ACM Conference on Computer
and Communications Security, pp. 81-88, November
1994.
[MARKS] Briscoe, B., "MARKS: Zero Side Effect Multicast Key
Management Using Arbitrarily Revealed Key Sequences",
Proc. First International Workshop on Networked
Group Communication (NGC), Pisa, Italy, November
1999.
[MIKEY] Arkko, J., Carrara, E., Lindholm, F., Naslund, M.,
and K. Norrman, "MIKEY: Multimedia Internet KEYing",
RFC 3830, August 2004.
[MSEC-Arch] Hardjono, T. and B. Weis, "The Multicast Group
Security Architecture", RFC 3740, March 2004.
[MVV] Menzes, A.J., van Oorschot, P.C., and S.A. Vanstone,
"Handbook of Applied Cryptography", CRC Press, 1996.
[NORM] Adamon, B., Bormann, C., Handley, M., and J. Macker,
"Negative-acknowledgment (NACK)-Oriented Reliable
Multicast (NORM) Protocol", RFC 3940, November 2004.
[OFT] Balenson, D., McGrew, P.C., and A. Sherman, "Key
Management for Large Dynamic Groups: One-Way Function
Trees and Amortized Initialization", IRTF Work in
Progress, August 2000.
[RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2094] Harney, H., and C. Muckenhirn, "Group Key Management
Protocol (GKMP) Architecture" RFC 2094, July 1997.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session
Description Protocol", RFC 2327, April 1998.
[RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key
Management API, Version 2", RFC 2367, July 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2408] Maughan, D., Schertler, M., Schneider, M., and J.
Turner, "Internet Security Association and Key
Management Protocol (ISAKMP)", RFC 2408, November
1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998.
[RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key
Management Protocol", RFC 2522, March 1999.
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R.,
Thomas, B., and T. Ylonen, "SPKI Certificate Theory",
RFC 2693, September 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC
3280, April 2002.
[RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management
for Multicast: Issues and Architectures", RFC 2627,
June 1999.
[RFC3450] Luby, M., Gemmell, J., Vicisano, L., Rizzo, L., and
J. Crowcroft, "Asynchronous Layered Coding (ALC)
Protocol Instantiation", RFC 3450, December 2002.
[RFC3547] Baugher, M., Weis, B., Hardjono, T., and H. Harney,
"The Group Domain of Interpretation", RFC 3547, July
2003.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E.,
and K. Norrman, "The Secure Real-time Transport
Protocol (SRTP)", RFC 3711, March 2004.
[SD1] Naor, D., Naor, M., and J. Lotspiech, "Revocation and
Tracing Schemes for Stateless Receiver", Advances in
Cryptology - CRYPTO, Santa Barbara, CA: Springer-
Verlag Inc., LNCS 2139, August 2001.
[SD2] Naor, M. and B. Pinkas, "Efficient Trace and Revoke
Schemes", Proceedings of Financial Cryptography 2000,
Anguilla, British West Indies, February 2000.
[Self-Healing] Staddon, J., et. al., "Self-healing Key Distribution
with Revocation", Proc. 2002 IEEE Symposium on
Security and Privacy, Oakland, CA, May 2002.
[SKEME] H. Krawczyk, "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", ISOC Secure Networks and
Distributed Systems Symposium, San Diego, 1996.
[STS] Diffie, P. van Oorschot, M., and J. Wiener,
"Authentication and Authenticated Key Exchanges",
Designs, Codes and Cryptography, 2, 107-125 (1992),
Kluwer Academic Publishers.
[TAXONOMY] Canetti, R., et. al., "Multicast Security: A Taxonomy
and some Efficient Constructions", IEEE INFOCOM,
1999.
[TESLA-INFO] Perrig, A., Canetti, R., Song, D., Tygar, D., and B.
Briscoe, "TESLA: Multicast Source Authentication
Transform Introduction", Work in Progress, December
2004.
[TESLA-SPEC] Perrig, A., R. Canetti, and Whillock, "TESLA:
Multicast Source Authentication Transform
Specification", Work in Progress, April 2002.
[tGSAKMP] Harney, H., et. al., "Tunneled Group Secure
Association Key Management Protocol", Work in
Progress, May 2003.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1.0," RFC 2246, January 1999.
[TPM] Marks, D. and B. Turnbull, "Technical protection
measures: The Intersection of Technology, Law, and
Commercial Licenses", Workshop on Implementation
Issues of the WIPO Copyright Treaty (WCT) and the
WIPO Performances and Phonograms Treaty (WPPT), World
Intellectual Property Organization, Geneva, December
6 and 7, 1999.
[Wool] Wool, A., "Key Management for Encrypted broadcast",
5th ACM Conference on Computer and Communications
Security, San Francisco, CA, Nov. 1998.
Authors’ Addresses
Mark Baugher
Cisco Systems
5510 SW Orchid St.
Portland, OR 97219, USA
Phone: +1 408-853-4418
EMail: mbaugher@cisco.com
Ran Canetti
IBM Research
30 Saw Mill River Road
Hawthorne, NY 10532, USA
Phone: +1 914-784-7076
EMail: canetti@watson.ibm.com
Lakshminath R. Dondeti