Scalable Multicast Key Distribution
RFC 1949
Document | Type |
RFC - Experimental
(May 1996; No errata)
Was draft-ietf-idmr-msec (idmr WG)
|
|
---|---|---|---|
Author | Anthony Ballardie | ||
Last updated | 2013-03-02 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 1949 (Experimental) | |
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
Network Working Group A. Ballardie Request for Comments: 1949 University College London Category: Experimental May 1996 Scalable Multicast Key Distribution Status of this Memo This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Abstract The benefits of multicasting are becoming ever-more apparent, and its use much more widespread. This is evident from the growth of the MBONE [1]. Providing security services for multicast, such as traffic integrity, authentication, and confidentiality, is particularly problematic since it requires securely distributing a group (session) key to each of a group's receivers. Traditionally, the key distribution function has been assigned to a central network entity, or Key Distribution Centre (KDC), but this method does not scale for wide-area multicasting, where group members may be widely-distributed across the internetwork, and a wide-area group may be densely populated. Even more problematic is the scalable distribution of sender-specific keys. Sender-specific keys are required if data traffic is to be authenticated on a per-sender basis. This memo provides a scalable solution to the multicast key distribution problem. NOTE: this proposal requires some simple support mechanisms, which, it is recommended here, be integrated into version 3 of IGMP. This support is described in Appendix B. 1. Introduction Growing concern about the integrity of Internet communication [13] (routing information and data traffic) has led to the development of an Internet Security Architecture, proposed by the IPSEC working group of the IETF [2]. The proposed security mechanisms are implemented at the network layer - the layer of the protocol stack at which networking resources are best protected [3]. Ballardie Experimental [Page 1] RFC 1949 Scalable Multicast Key Distribution May 1996 Unlike many network layer protocols, the Core Based Tree (CBT) multicast protocol [4] makes explicit provision for security; it has its own protocol header, unlike existing IP multicast schemes [10,11], and other recently proposed schemes [12]. In this document we describe how the CBT multicast protocol can provide for the secure joining of a CBT group tree, and how this same process can provide a scalable solution to the multicast key distribution problem. These security services are an integral part of the CBT protocol [4]. Their use is optional, and is dependent on each individual group's requirements for security. Furthermore, the use of the CBT multicast protocol for multicast key distribution does not preclude the use of other multicast protocols for the actual multicast communication itself, that is, CBT need only be the vehicle with which to distribute keys. Secure joining implies the provision for authentication, integrity, and optionally, confidentiality, of CBT join messages. The scheme we describe provides for the authentication of tree nodes (routers) and receivers (end-systems) as part of the tree joining process. Key distribution (optional) is an integral part of secure joining. Network layer multicast protocols, such as DVMRP [7] and M-OSPF [9], do not have their own protocol header(s), and so cannot provision for security in themselves; they must rely on whatever security is provided by IP itself. Multicast key distribution is not addressed to any significant degree by the new IP security architecture [2]. The CBT security architecture is independent of any particular cryptotechniques, although many security services, such as authentication, are easier if public-key cryptotechniques are employed. What follows is an overview of the CBT multicasting. The description of our proposal in section 6.1 assumes the reader is reasonably familiar with the CBT protocol. Details of the CBT architecture and protocol can be found in [7] and [4], respectively. 2. Overview of BCT Multicasting CBT is a new architecture for local and wide-area IP multicasting, being unique in its utilization of just one shared delivery tree per group, as opposed to the source-based delivery tree approach of existing IP multicast schemes, such as DVMRP and MOSPF. A shared multicast delivery tree is built around several so-called core routers. A group receiver's local multicast router is required to explicitly join the corresponding delivery tree after receiving an Ballardie Experimental [Page 2] RFC 1949 Scalable Multicast Key Distribution May 1996Show full document text