rfc2627.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,292 行 · 第 1/4 页

Network Working Group                                       D. Wallner
Request for Comments: 2627                                   E. Harder
Category: Informational                                        R. Agee
                                              National Security Agency
                                                             June 1999


         Key Management for Multicast: Issues and Architectures

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This report contains a discussion of the difficult problem of key
   management for multicast communication sessions.  It focuses on two
   main areas of concern with respect to key management, which are,
   initializing the multicast group with a common net key and rekeying
   the multicast group.  A rekey may be necessary upon the compromise of
   a user or for other reasons (e.g., periodic rekey).  In particular,
   this report identifies a technique which allows for secure compromise
   recovery, while also being robust against collusion of excluded
   users.  This is one important feature of multicast key management
   which has not been addressed in detail by most other multicast key
   management proposals [1,2,4].  The benefits of this proposed
   technique are that it minimizes the number of transmissions required
   to rekey the multicast group and it imposes minimal storage
   requirements on the multicast group.

1.0  MOTIVATION

   It is recognized that future networks will have requirements that
   will strain the capabilities of current key management architectures.
   One of these requirements will be the secure multicast requirement.
   The need for high bandwidth, very dynamic secure multicast
   communications is increasingly evident in a wide variety of
   commercial, government, and Internet communities.  Specifically, the
   secure multicast requirement is the necessity for multiple users who
   share the same security attributes and communication requirements to
   securely communicate with every other member of the multicast group
   using a common multicast group net key.  The largest benefit of the



Wallner, et al.              Informational                      [Page 1]

RFC 2627             Key Management for Multicast              June 1999


   multicast communication being that multiple receivers simultaneously
   get the same transmission.  Thus the problem is enabling each user to
   determine/obtain the same net key without permitting unauthorized
   parties to do likewise (initializing the multicast group) and
   securely rekeying the users of the multicast group when necessary.
   At first glance, this may not appear to be any different than current
   key management scenarios.  This paper will show, however, that future
   multicast scenarios will have very divergent and dynamically changing
   requirements which will make it very challenging from a key
   management perspective to address.

2.0  INTRODUCTION

   The networks of the future will be able to support gigabit bandwidths
   for individual users, to large groups of users.  These users will
   possess various quality of service options and multimedia
   applications that include video, voice, and data, all on the same
   network backbone.  The desire to create small groups of users all
   interconnected and capable of communicating with each other, but who
   are securely isolated from all other users on the network is being
   expressed strongly by users in a variety of communities.

   The key management infrastructure must support bandwidths ranging
   from kilobits/second to gigabits/second, handle a range of multicast
   group sizes, and be flexible enough for example to handle such
   communications environments as wireless and mobile technologies.  In
   addition to these performance and communications requirements, the
   security requirements of different scenarios are also wide ranging.
   It is required that users can be added and removed securely and
   efficiently, both individually and in bulk.  The system must be
   resistant to compromise, insofar as users who have been dropped
   should not be able to read any subsequent traffic, even if they share
   their secret information.  The costs we seek to minimize are time
   required for setup, storage space for each end user, and total number
   of transmissions required for setup, rekey and maintenance.  It is
   also envisioned that any proposed multicast security mechanisms will
   be implemented no lower than any layer with the characteristics of
   the network layer of the protocol stack.  Bandwidth efficiency for
   any key management system must also be considered.  The trade-off
   between security and performance of the entire multicast session
   establishment will be discussed in further detail later in this
   document.









Wallner, et al.              Informational                      [Page 2]

RFC 2627             Key Management for Multicast              June 1999


   The following section will explain several potential scenarios where
   multicast capabilities may be needed, and quantify their requirements
   from both a performance and security perspective.  It will be
   followed in Section 4.0 by a list of factors one must consider when
   designing a potential solution.  While there are several security
   services that will be covered at some point in this document, much of
   the focus of this document has been on the generation and
   distribution of multicast group net keys.  It is assumed that all
   potential multicast participants either through some manual or
   automated, centralized or decentralized mechanism have received
   initialization keying material (e.g. certificates).  This document
   does not address the initialization key distribution issue.  Section
   5 will then detail several potential multicast key management
   architectures, manual (symmetric) and public key based (asymmetric),
   and highlight their relative advantages and disadvantages (Note:The
   list of advantages and disadvantages is by no means all inclusive.).
   In particular, this section emphasizes our technique which allows for
   secure compromise recovery.

3.0  MULTICAST SCENARIOS

   There are a variety of potential scenarios that may stress the key
   management infrastructure.  These scenarios include, but are not
   limited to, wargaming, law enforcement, teleconferencing, command and
   control conferencing, disaster relief, and distributed computing.
   Potential performance and security requirements, particularly in
   terms of multicast groups that may be formed by these users for each
   scenario, consists of the potential multicast group sizes,
   initialization requirements (how fast do users need to be brought
   on-line), add/drop requirements (how fast a user needs to be added or
   deleted from the multicast group subsequent to initialization), size
   dynamics (the relative number of people joining/leaving these groups
   per given unit of time), top level security requirements, and
   miscellaneous special issues for each scenario.  While some scenarios
   describe future secure multicast requirements, others have immediate
   security needs.

   As examples, let us consider two scenarios, distributed gaming and
   teleconferencing.

   Distributed gaming deals with the government's need to simulate a
   conflict scenario for the purposes of training and evaluation.  In
   addition to actual communications equipment being used, this concept
   would include a massive interconnection of computer simulations
   containing, for example, video conferencing and image processing.
   Distributed gaming could be more demanding from a key management
   perspective than an actual scenario for several reasons.  First, the
   nodes of the simulation net may be dispersed throughout the country.



Wallner, et al.              Informational                      [Page 3]

RFC 2627             Key Management for Multicast              June 1999


   Second, very large bandwidth communications, which enable the
   possibility for real time simulation capabilities, will drive the
   need to drop users in and out of the simulation quickly.  This is
   potentially the most demanding scenario of any considered.

   This scenario may involve group sizes of potentially 1000 or more
   participants, some of which may be collected in smaller subgroups.
   These groups must be initialized very rapidly, for example, in a ten
   second total initialization time.  This scenario is also very
   demanding in that users may be required to be added or dropped from
   the group within one second.  From a size dynamics perspective, we
   estimate that approximately ten percent of the group members may
   change over a one minute time period.  Data rate requirements are
   broad, ranging from kilobits per second (simulating tactical users)
   to gigabits per second (multicast video). The distributed gaming
   scenario has a fairly thorough set of security requirements covering
   access control, user to user authentication, data confidentiality,
   and data integrity.  It also must be "robust" which implies the need
   to handle noisy operating environments that are typical for some
   tactical devices.  Finally, the notion of availability is applied to
   this scenario which implies that the communications network supplying
   the multicast capability must be up and functioning a specified
   percentage of the time.

   The teleconference scenario may involve group sizes of potentially
   1000 or more participants.  These groups may take up to minutes to be
   initialized.  This scenario is less demanding in that users may be
   required to be added or dropped from the group within seconds.  From
   a size dynamics perspective, we estimate that approximately ten
   percent of the group members may change over a period of minutes.
   Data rate requirements are broad, ranging from kilobits per second to
   100's of Mb per second.  The teleconference scenario also has a
   fairly thorough set of security requirements covering access control,
   user to user authentication, data confidentiality, data integrity,
   and non-repudiation.  The notion of availability is also applicable
   to this scenario.  The time frame for when this scenario must be
   provided is now.

4.0   ARCHITECTURAL ISSUES

   There are many factors that must be taken into account when
   developing the desired key management architecture.  Important issues
   for key management architectures include level (strength) of
   security, cost, initializing the system, policy concerns, access
   control procedures, performance requirements and support mechanisms.
   In addition, issues particular to multicast groups include:





Wallner, et al.              Informational                      [Page 4]

RFC 2627             Key Management for Multicast              June 1999


      1. What are the security requirements of the group members? Most
         likely there will be some group controller, or controllers.  Do
         the other members possess the same security requirements as the
         controller(s)?

      2. Interdomain issues - When crossing from one "group domain" to
         another domain with a potentially different security policy,
         which policy is enforced?  An example would be two users
         wishing to communicate, but having different cryptoperiods
         and/or key length policies.

      3. How does the formation of the multicast group occur?  Will the
         group controller initiate the user joining process, or will the
         users initiate when they join the formation of the multicast
         group?

      4. How does one handle the case where certain group members have
         inferior processing capabilities which could delay the
         formation of the net key?  Do these users delay the formation
         of the whole multicast group, or do they come on-line later
         enabling the remaining participants to be brought up more
         quickly?

      5. One must minimize the number of bits required for multicast
         group net key distribution.  This greatly impacts bandwidth
         limited equipments.

   All of these and other issues need to be taken into account, along
   with the communication protocols that will be used which support the
   desired multicast capability.  The next section addresses some of
   these issues and presents some candidate architectures that could be
   used to tackle the key management problem for multicasting.

5.0  CANDIDATE ARCHITECTURES

   There are several basic functions that must be performed in order for
   a secure multicast session to occur.  The order in which these
   functions will be performed, and the efficiency of the overall
   solution results from making trade-offs of the various factors listed
   above.  Before looking at specific architectures, these basic
   functions will be outlined, along with some definition of terms that
   will be used in the representative architectures. These definitions
   and functions are as follows:








Wallner, et al.              Informational                      [Page 5]

RFC 2627             Key Management for Multicast              June 1999


      1. Someone determines the need for a multicast session, sets the
         security attributes for that particular session (e.g.,
         classification levels of traffic, algorithms to be used, key
         variable bit lengths, etc.), and creates the group access
         control list which we will call the initial multicast group
         participant list.  The entity which performs these functions
         will be called the INITIATOR.  At this point, the multicast
         group participant list is strictly a list of users who the
         initiator wants to be in the multicast group.

      2. The initiator determines who will control the multicast group.
         This controller will be called the ROOT (or equivalently the
         SERVER). Often, the initiator will become the root, but the
         possibility exists where this control may be passed off to
         someone other than the initiator. (Some key management
         architectures employ multiple roots, see [4].) The root's job
         is to perform the addition and deletion of group participants,
         perform user access control against the security attributes of
         that session, and distribute the traffic encryption key for the
         session which we will call the multicast group NET KEY.  After
         initialization, the entity with the authority to accept or
         reject the addition of future group participants, or delete
         current group participants is called the LIST CONTROLLER.

         This may or may not be the initiator. The list controller has
         been distinguished from the root for reasons which will become
         clear later.  In short, it may be desirable for someone to have
         the authority to accept or reject new members, while another
         party (the root) would actually perform the function.

      3. Every participant in the multicast session will be referred to
         as a GROUP PARTICIPANT.  Specific group participants other than
         the root or list controller will be referred to as LEAVES.

      4. After the root checks the security attributes of the
         participants listed on the multicast group participant list to
         make sure that they all support the required security