Scalable Multicast Key Distribution
RFC 1949

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

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 1996