rfc1949.txt

RFC 的详细文档！

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


   IGMP [8] group membership report over a directly connected interface.
   A CBT join message is targeted at one of the group's core routers.
   The resulting acknowledgement traverses the reverse-path of the join,
   resulting in the creation of a tree branch. Routers along these
   branches are called non-core routers for the group, and there exists
   a parent-child relationship between adjacent routers along a branch
   of the same tree (group).

3.  How the CBT Architecture Complements Security

   The CBT architecture requires "leaf" routers to explicitly join a CBT
   tree. Hence, CBT is not data driven; the ack associated with a join
   "fixes" tree state in the routers that make up the tree. This so-
   called "hard state" remains until the tree re-configures, for
   example, due to receivers leaving the group, or because an upstream
   failure has occurred. The CBT protocol incorporates mechanisms
   enabling a CBT tree to repair itself in the event of the latter.

   As far as the establishment of an authenticated multicast
   distribution tree is concerned, DVMRP, M-OSPF, and PIM, are at a
   disadvan- tage; the nature of their "soft state" means a delivery
   tree only exists as long as there is data flow.  Also, routers
   implementing a multicast protocol that builds its delivery tree based
   on a reverse-path check (like DVMRP and PIM dense mode) cannot be
   sure of the previous-hop router, but only the interface a multicast
   packet arrived on.

   These problems do not occur in the CBT architecture. CBT's hard state
   approach means that all routers that make up a delivery tree know who
   their on-tree neighbours are; these neighbours can be authenticated
   as part of delivery tree set-up. As part of secure tree set-up,
   neighbours could exchange a secret packet handle for inclusion in the
   CBT header of data packets exchanged between those neighbours,
   allowing for the simple and efficient hop-by-hop authentication of
   data packets (on-tree).

   The presence of tree focal points (i.e. cores) provides CBT trees
   with natural authorization points (from a security viewpoint) -- the
   formation of a CBT tree requires a core to acknowledge at least one
   join in order for a tree branch to be formed. Thereafter,
   authorization and key distribution capability can be passed on to
   joining nodes that are authenticated.

   In terms of security, CBT's hard state approach offers several
   additional advantages: once a multicast tree is established, tree
   state maintained in the routers that make up the tree does not time
   out or change necessarily to reflect underlying unicast topology.
   The security implications of this are that nodes need not be subject



Ballardie                     Experimental                      [Page 3]

RFC 1949          Scalable Multicast Key Distribution           May 1996


   to repeated authentication subsequent to a period of inactivity, and
   tree nodes do not need to re-authenticate themselves as a result of
   an underlying unicast topology change, unless of course, an network
   (node) failure has occurred.

   Hard-state protocol mechanisms are often thought of as being less
   fault tolerant than soft-state schemes, but there are pros and cons
   to both approaches; we see here that security is one of the pros.

4.  The Multicast Key Distribution Problem

   We believe that multicast key distribution needs to be combined with
   group access control. Without group access control, there is no point
   in employing multicast key distribution, since, if there are no group
   restrictions, then it should not matter to whom multicast information
   is divulged.

   There are different ways of addressing group access control. The
   group access control we describe requires identifying one group
   member (we suggest in [14] that this should be the group initiator)
   who has the ability to create, modify and delete all or part of a
   group access control list. The enforcement of group access control
   may be done by a network entity external to the group, or by a group
   member.

   The essential problem of distributing a session (or group) key to a
   group of multicast receivers lies in the fact that some central key
   management entity, such as a key distribution centre (KDC) (A Key
   Distribution Centre (KDC) is a network entity, usually residing at a
   well-known address. It is a third party entity whose responsibility
   it to generate and distribute symmetric key(s) to peers, or group
   receivers in the case of multicast, wishing to engage in a "secure"
   communication. It must therefore be able to identify and reliably
   authenticate requestors of symmetric keys.), must authenticate each
   of a group's receivers, as well as securely distribute a session key
   to each of them.  This involves encrypting the relevant message n
   times, once with each secret key shared between the KDC and
   corresponding receiver (or alternatively, with the public key of the
   receiver), before multicasting it to the group. (Alternatively, the
   KDC could send an encrypted message to each of the receivers
   individually, but this does not scale either.)  Potentially, n may be
   very large.  Encrypting the group key with the secret key (of a
   secret-public key pair) of the KDC is not an option, since the group
   key would be accessible to anyone holding the KDC's public key, and
   public keys are either well-known or readily available.  In short,
   existing multicast key distribution methods do not scale.





Ballardie                     Experimental                      [Page 4]

RFC 1949          Scalable Multicast Key Distribution           May 1996


   The scaling problem of secure multicast key distribution is
   compounded for the case where sender-specific keys need to be
   distributed to a group. This is required for sender-specific
   authentication of data traffic. It is not possible to achieve per-
   sender authentication, given only a group session key.

   Recently a proposal has emerged, called the Group Key Management
   Protocol (GKMP) [15]. This was designed for military networks, but
   the authors have demonstrated how the architecture could be applied
   to a network like the Internet, running receiver-oriented multicast
   applications.

   GKMP goes a considerable way to addressing the problems of multicast
   key distribution: it does not rely on a centralised KDC, but rather
   places the burden of key management on a group member(s). This is the
   approach adopted by the CBT solution, but our solution can take this
   distributed approach further, which makes our scheme that much more
   scalable. Furthermore, our scheme is relatively simple.

   The CBT model for multicast key distribution is unique in that it is
   integrated into the CBT multicast protocol itself. It offers a
   simple, low-cost, scalable solution to multicast key distribution. We
   describe the CBT multicast key distribution approach below.

5.  Multicast Security Associations

   The IP security architecture [2] introduces the concept of "Security
   Associations" (SAs), which must be negotiated in advance during the
   key management phase, using a protocol such as Photuris [20], or
   ISAKMP [21].  A Security Association is normally one-way, so if two-
   way communication is to take place (e.g. a typical TCP connection),
   then two Security Associations need to be negotiated.  During the
   negotiation phase, the destination system normally assigns a Security
   Parameter Index to the association, which is used, together with the
   destination address (or, for the sender, the sender's user-id) to
   index into a Security Association table, maintained by the
   communicating parties.  This table enables those parties to index the
   correct security parameters pertinent to an association.  The
   security association parameters include authentication algorithm,
   algorithm mode, cryptographic keys, key lifetime, sensitivity level,
   etc.

   The establishment of Security Associations (SA) for multicast
   communication does not scale using protocols like Photuris, or
   ISAKMP.  This is why it is often assumed that a multicast group will
   be part of a single Security Association, and hence share a single
   SPI. It is assumed that one entity (or a pair of entities) creates
   the SPI "by some means" (which may be an SA negotiation protocol,



Ballardie                     Experimental                      [Page 5]

RFC 1949          Scalable Multicast Key Distribution           May 1996


   like [20] and [21]), which is then simply multicast, together with
   the SA parameters, to the group for subsequent use. However, this
   precludes multicast receivers from performing sender-specific origin
   authentication; all a receiver can be sure of is that the sender is
   part of the multicast Security Association.

   We advocate that the primary core, either alone, or in conjunction
   with the group initiator, establish the security parameters to be
   used in the group communication. These are distributed as part of the
   secure join process. Thereafter, individual senders can distribute
   their own key and security parameters to the group.  In the case of
   the latter, there are two cases to consider:

   +    the sender is already a group member. In this case, the sender
        can decide upon/generate its own security parameters, and multi-
        cast them to the group using the current group session key.

   +    the sender is not a group member. In this case, before the
        sender begins sending, it must first negotiate the security
        parameters with the primary core, using a protocol such as Pho-
        turis [20] or ISAKMP [21].  Once completed, the primary core
        multicasts (securely) the new sender's session key and security
        parameters to the group.

   Given that we assume the use of asymmetric cryptotechniques
   throughout, this scheme provides a scalable solution to multicast
   origin authentication.

   Sender-specific keys are also discussed in section 8.

6.  The CBT Multicast Key Distribution Model

   The security architecture we propose allows not only for the secure
   joining of a CBT multicast tree, but also provides a solution to the
   multicast key distribution problem [16]. Multicast key distribution
   is an optional, but integral, part of the secure tree joining
   process; if a group session key is not required, its distribution may
   be omitted.

   The use of CBT for scalable multicast key distribution does not
   preclude the use of other multicast protocols for the actual
   multicast communication.  CBT could be used solely for multicast key
   distribution -- any multicast protocol could be used for the actual
   multicast communication itself.

   The model that we propose does not rely on the presence of a
   centralised KDC -- indeed, the KDC we propose need not be dedicated
   to key distribution. We are proposing that each group have its own



Ballardie                     Experimental                      [Page 6]