rfc2094.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/4 页

Network Working Group                                         H. Harney
Request for Comments: 2094                                C. Muckenhirn
Category: Experimental                                     SPARTA, Inc.
                                                              July 1997


           Group Key Management Protocol (GKMP) Architecture

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.

Table of Contents

   1. Introduction.................................................   1
   2. Multicast Key Management Architectures.......................   3
   3. GKMP Protocol Overview.......................................   9
   4. Issues.......................................................  19
   5. Security Considerations......................................  22
   6. Authors' Address.............................................  22

Abstract

   This specification proposes a protocol to create grouped symmetric
   keys and distribute them amongst communicating peers. This protocol
   has the following advantages: 1) virtually invisible to operator, 2)
   no central key distribution site is needed, 3) only group members
   have the key, 4) sender or receiver oriented operation, 5) can make
   use of multicast communications protocols.

1 Introduction

   This document describes an architecture for the management of
   cryptographic keys for multicast communications.  We identify the
   roles and responsibilities of communications system elements in
   accomplishing multicast key management, define security and
   functional requirements of each, and provide a detailed introduction
   to the Group Key Management Protocol (GKMP) which provides the
   ability to create and distribute keys within arbitrary-sized groups
   without the intervention of a global/centralized key manager.  The
   GKMP combines techniques developed for creation of pairwise keys with
   techniques used to distribute keys from a KDC (i.e., symmetric
   encryption of keys) to distribute symmetric key to a group of hosts.





Harney & Muckenhirn           Experimental                      [Page 1]

RFC 2094                   GKMP Architecture                   July 1997


1.1 Multicast Communications Environments

   The work leading to this report was primarily concerned with military
   command and control and weapons control systems, these systems tend
   to have top--down, commander--commanded, communications flows.  The
   choice of what parties will be members of a particular communication
   (a multicast group for example) is at the discretion of the "higher"
   level party(ies).  This "sender-initiated" (assuming the higher-level
   party is sending) model maps well to broadcast (as in
   electromagnetic, free-space, transmission) and circuit switched
   communications media (e.g., video teleconferencing, ATM multicast).

   In looking to apply this technology to the Internet, a somewhat
   different model appears to be at work (at least for some portion of
   Internet multicast traffic).  IDRP and Distance Vector Multicast
   Routing Protocol (DVMRP) use multicast as a mechanism for parties to
   relay common information to their peers.  Each party both sends and
   receives information in the multicast channel.  As appropriate, a
   party may choose to leave or join the communication without the
   express permission of any of the other parties (this begs the
   question of meta-authorizations which allow the parties to
   cooperate).  More interestingly, the multicast IP model has the
   receiver telling the network to add it to the distribution for a
   particular multicast address, whether it exists yet or not, and the
   transmitter not being consulted as to the addition of the receiver.

   Other applications of multicast communications in the Internet, for
   example NASA Select broadcasts, can be viewed as implementing the
   sender model since the sender selects the broadcast time, channel,
   and content, though not the destinations.

   It is our intention to provide key management services which support
   both communications (and implied access control) models and operate
   in either a circuit switched or packet switched environment.

1.2 Security for Multicast

   Multicast communications, as with unicast, may require any of the
   security services defined in ISO 7498, access control, data
   confidentiality, traffic confidentiality, integrity/data
   authentication, source authentication, sender and receiver non-
   repudiation and service assurance.  From the perspective of key
   management processes, only data confidentiality, data authentication,
   and source authentication can be supported.  The other services,
   traffic confidentiality, non-repudiation, and service assurance must
   be provided by the communications protocol, they may rely on
   cryptographic services but are not guaranteed by them.




Harney & Muckenhirn           Experimental                      [Page 2]

RFC 2094                   GKMP Architecture                   July 1997


2 Multicast Key Management Architectures

2.1 Current Operations

   There are several electronic mechanisms for generating and
   distributing symmetric keys to several computers (i.e.,
   communications groups).  These techniques, generally, rely on a key
   distribution center (KDC) to act as a go between in setting up the
   symmetric key groups.  Military systems, such as BLACKER, STU-
   II/BELLFIELD, and EKMS, and commercial systems, such as X9.17 and
   Kerberos, all operate using dedicated KDCs.  A group key request is
   sent to the KDC via various means (on- or off-line) The KDC acting as
   an access controller decides whether or not the request is proper
   (i.e., all members of a group are cleared to receive all the data on
   a group).  The KDC would then call up each individual member of the
   group and down load the symmetric key.  When each member had the key
   the KDC would notify the requester.  Then secure group communication
   could begin.  While this was certainly faster then anything that
   requires human intervention.  It still requires quite a bit of set-up
   time.  Also, a third party, whose primary interest isn't the
   communication, needs to get involved.

   Pairwise keys can be created autonomously by the host on a network by
   using any number of key generation protocols (FireFly, Diffe-Hellman,
   RSA). These protocols all rely on cooperative key generation
   algorithms to create a cryptographic key.  These algorithms rely on
   random information generated by each host.  These algorithms also
   rely on peer review of permissions to ensure that the communication
   partners are who they claim to be and have authorization to receive
   the information being transmitted.  This peer review process relies
   on a trusted authority assigning permissions to each host in the
   network that wants the ability to create these keys.  The real beauty
   of these pairwise key management protocols is that they can be
   integrated into the communication protocol or the application.  This
   means that the key management becomes relatively invisible to the
   people in the system.

2.2 GKMP-Based Operations

   The GKMP described below, delegates the access control, key
   generation, and distribution functions to the communicating entities
   themselves rather than relying on a third party (KDC) for these
   functions.  As prelude to actually distributing key, a few things
   must be assumed (for purposes of this document): there exists a
   "security manager" responsible for creating and distributing to
   parties authentic identification and security permission information
   (The security manager function may be accomplished through a strictly
   hierarchical system (a la STU-III) or a more ad hoc system of



Harney & Muckenhirn           Experimental                      [Page 3]

RFC 2094                   GKMP Architecture                   July 1997


   cooperating peer "domain managers," the implementation of the
   certification hierarchy is not addressed in this document.);
   communicating parties are online for the keys formed and distributed
   by the GKMP.

2.2.1 Sender Initiated Operations

   This section describes the basic operational concept for multicast
   key management for sender initiated multicast support.  This model of
   multicast communications was the basis for our original work on
   multicast key management.  From a security viewpoint the sending
   application is able to control access to the transmission through
   both key distribution and communications distribution (not sending
   the transmission to some addresses).


   Identification of Group Key Controller -- The originator of the
   multicast group creates or obtains a group management certificate
   from its certification hierarchy.  The certificate identifies the
   holder as responsible for generation and distribution of the group
   key (Naming standards are not addressed here, the name should reflect
   the naming structures appropriate for the supported cryptographic
   service.  For example, IP-level encryptors should use naming
   reflecting "host" identities (IP addresses, or DNS host names), RTP
   encryptor would use session names).  The originator relays the
   membership list to the Group Key Management (GKM) application.


   Group Key Creation --   The GKM application, operating on behalf of
   the originator, selects one member of the group, contacts it, and
   creates a Group Key Packet (GKP). A GKP contains the current group
   traffic encrypting key (GTEK) and future group key encrypting key
   (GKEK). The GKM application then identifies itself as the group key
   controller, which the member validates, under cover of the GTEK.

        Group Key Packet (GKP) = [GTEKn,GKEKn+1]

   As part of group key packet formation, usage parameters, appropriate
   for the underlying crypto-system, are selected.  Unlike normal
   parameter negotiation, where common security-level/range, and
   services are arrived at, the originator's GKM application selects
   these parameters and the member must comply.


   Group Key Distribution --   After creation of the GKP, the group
   controller contacts each member of the group, creates a Session Key
   Package (SKP), validates their permissions (check member's
   certificate against group parameters), and create a Group Rekey



Harney & Muckenhirn           Experimental                      [Page 4]

RFC 2094                   GKMP Architecture                   July 1997


   Package for that member.  A SKP contains a session TEK and a session
   KEK for a particular member.  A GRP contains the GKP encrypted in a
   KEK and signed using the originator's certificate.

        Session Key Package (SKP) = [STEK, SKEK]

        Group Rekey Package (GRP) = {[GKP]KEK} SignatureController

   Group Rekey --   When the group needs to be rekeyed, the originating
   GKM application selects a member, creates a new GKP, creates a new
   GRP (which is encrypted in the previously distributed next GKEK) and
   broadcasts it to the group.

   This procedure is fairly complex, but other than for the distribution
   of site-specific certificates, no centralized key management
   resources are needed.  The only parties to the key management
   communications are the same parties which will be participating in
   the group.

2.2.2 Receiver Initiated Operations

   This section describes key management operational concept for
   receiver initiated multicast communication support.  The receiver
   initiated model presents some interesting problems from a security
   view point since the end-participants are not known a priori.  Also,
   in a purely receiver initiated application (such as DVMRP), there is
   no concept of an "originator" and the participants in the group may
   be quite dynamic with participants changing on a minute by minute
   basis.

   For secure group communications to take place, all members must
   obtain the same key.  This may be achieved by either using
   deterministic key generation techniques (using a secret, shared seed)
   or by making one member of the group responsible for creation of the
   key.  The use of a deterministic key generator presents security
   problems, particularly regarding loss of the seed (it compromises
   both past and future traffic).  The assignment of a member to the
   role of key "controller" also presents drawbacks, but these relate to
   determining which one should be the controller and the need for each
   member to contact him.  The remainder of this discussion will look at
   how the "controller" concept from above could work in the receiver
   initiated case.

   Selection of Group Key Controller --   A group member will be made
   responsible for initial group establishment and periodic generation
   and dissemination of new GRPs.  There is no need for the selected
   controller to be the controller for all time, but at any one time
   only one controller may be active for each group.  Selection of



Harney & Muckenhirn           Experimental                      [Page 5]

RFC 2094                   GKMP Architecture                   July 1997


   controller may be made through a voting system, by a simple default
   (the first to transmit to the group is the controller), or
   configuration.

   The current controller's identity must be made available to all
   members, and potential members, for initial group key load and error
   recovery.  The information may be relayed by broacast on a key
   management "channel," or through a directory service.

   Group Key Creation --   The GKP is created and distributed in much
   the same way as in sender initiated operations.  The controller
   creates a GKP with the first group member to initiate contact.  The
   GKM application then identifies itself as the group key controller,
   which the member validates, under cover of the GTEK. Parameter
   negotiation is performed and the first group member is keyed.

   Group Key Distribution --   After creation of the GKP, as other
   members contact the controller, a SKP is created, member permissions
   are validated and a GRP is loaded to the member.

   For widely distributed groups, a form of distributed dissemination
   may be used.  Some number of regional GKM applications are enabled
   with the ability to validate the permissions of new members and upon