rfc2093.txt

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

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


           Group Key Management Protocol (GKMP) Specification

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. Background..................................................... 1
   2. Overview:  GKMP Roles.......................................... 3
   3. Data Item primitives........................................... 4
   4. Message definitions............................................ 6
   5. State definitions.............................................. 9
   6. Functional Definitions--Group Key Management Protocol.......... 13
   7. Security Considerations........................................ 23
   8. Author's Address............................................... 23

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 Background

   Traditional key management distribution has mimicked the military
   paper based key accounting system.  Key was distributed, ordered, and
   accounted physically leading to large lead times and expensive
   operations.

   Cooperative key management algorithms exist that allow pairwise keys
   to be generated between two equipment's.  This gives the a quicker
   more reliable key management structure capable of supporting large
   numbers of secure communications.  Unfortunately, only pairwise keys
   are supported using these methods today.




Harney & Muckenhirn           Experimental                      [Page 1]

RFC 2093                   GKMP Specification                  July 1997


   This document describes a protocol for establishing and rekeying
   groups of cryptographic keys (more than two) on the internet.  We
   refer to the approach as the Group Key Management Protocol (GKMP).

1.1 Protocol Overview

   The GKMP creates key for cryptographic groups, distributes key to the
   group members, ensures (via peer to peer reviews) rule based access
   control of keys, denies access to known compromised hosts, and allow
   hierarchical control of group actions.

   The key generation concept used by the GKMP is cooperative generation
   between two protocol entities.  There are several key generation
   algorithms viable for use in the GKMP (i.e., RSA, Diffe-Hellman,
   elliptic curves).  All these algorithms use asymmetric key technology
   to pass information between two entities to create a single
   cryptographic key.

   The GKMP then distributes the group keys to qualified GKMP entities.
   This distribution process is a mutually suspicious process (all
   actions and identities must be verified).

   The GKMP provides a peer to peer review process.  Protocol entities
   pass permission certificates (PC) as part of the group key
   distribution process.  The PCs contain access control information
   about a particular site.  This access control information is assigned
   by a higher authority which then signs the PC. Therefor each entity
   can verify the permissions of any other GKMP entity but can modify
   none.  Each protocol entity checks the permissions and compares them
   the level of service requested.  If the permissions do not exceed or
   equal the request, the service is denied.

   The GKMP supports compromise recovery.  A list of compromised GKMP
   entities is distributed to group members during key management
   actions.  In essence, a Compromise Recovery List (CRL) allows group
   members to drop connections with compromised entities.  The GKMP
   delegates control of groups to specific group controllers so it will
   be somewhat easier to distribute the CRL to the most important GKMP
   entities.  During each key management action the CRL version number
   is passed, when a CRL update is detected it is downloaded and
   verified (it is signed by a higher authority).

   The GKMP allows control of group actions.  In certain networks it is
   desirable for a higher authority to strictly control the generation
   of groups.  These networks usually have a central network operations
   authority.  The GKMP allows these authorities to remotely order group
   actions.  These orders are signed by that authority and verified by
   all entities involved with the group.



Harney & Muckenhirn           Experimental                      [Page 2]

RFC 2093                   GKMP Specification                  July 1997


   The GKMP is an application layer protocol.  It's independent of the
   underlying communication protocol.  However, if multicast service is
   available it will speed the rekey of the cryptographic groups.
   Hence, the GKMP does use multicast services if they are available.

2 Overview:  GKMP Roles

   Creation and distribution of grouped key require assignment of roles.
   These identify what functions the individual hosts perform in the
   protocol.  The two primary roles are those of key distributor and
   member.  The controller initiates the creation of the key, forms the
   key distribution messages, and collects acknowledgment of key receipt
   from the receivers.  The members wait for a distribution message,
   decrypt, validate, and acknowledge the receipt of new key.

2.1 Group controller

   The group controller (GC) is the a group member with authority to
   perform critical protocol actions (i.e., create key, distribute key,
   create group rekey messages, and report on the progress of these
   actions).  All group members have the capability to be a GC and could
   assume this duty upon assignment.

   The GC helps the cryptographic group reach and maintain key
   synchronization.  A group must operate on the same symmetric
   cryptographic key.  If part of the group loses or inappropriately
   changes it's key, it will not be able to send or receive data to
   another host operating on the correct key.  Therefor, it is important
   that those operations that create or change key are unambiguous and
   controlled (i.e., it would not be appropriate for multiple hosts to
   try to rekey a net simultaneously).  Hence, someone has to be in
   charge -- that is the controller.

2.2 Group member

   Simply stated a group member is any group host who is not acting as
   the controller.  The group members will:  assist the controller in
   creating key, validate the controller authorization to perform
   actions, accept key from the controller, request key from the
   controller, maintain local CRL lists, perform peer review of key
   management actions, and manage local key.










Harney & Muckenhirn           Experimental                      [Page 3]

RFC 2093                   GKMP Specification                  July 1997


3 Data Item primitives

3.1 Group members list:

   In a sender oriented group, the GC must be given a list of net
   members.  The controller will then initiate contact with these net
   members and create the group.

3.2 Group Token:

   The group token is created by the authority which commands a group.
   The Token contains information the net members need to ensure a
   controller is authorized to create a group and exactly what
   constrains are intended to be places on the group.  The group token
   contains the following fields:  Group identification,

   o  GC ID,

   o  Group action (create, rekey, delete),

   o  Group permissions (rules to guide access control),

   o  Rekey interval (life span of group key),

   o  Token version (identifier to identify current token),

   o  Token signature (asymmetric signature using the group
      commanders private key),

   o  Group commanders public key (this public key is itself signed by
      the network security manager to bind the public to a specific net
      member ID).

3.3 Grp ID:

   The group must be uniquely identified to allow for several different
   groups to coexist on a network.

3.4 GTEK ID:

   Unique identifier of GTEK (can include state information).

3.5 GKEK ID:

   Unique identifier of GKEK (can include state information).






Harney & Muckenhirn           Experimental                      [Page 4]

RFC 2093                   GKMP Specification                  July 1997


3.6 GTEK creation field:

   In a cooperative key creation protocol each party contributes some
   field used to create the key.

3.7 GKEK creation field:

   In a cooperative key creation protocol each party contributes some
   field used to create the key.

3.8 Distributor signature:

   Asymmetric signature using the GCs private key.

3.9 Distributor public key:

   Public half of the GCs signature key pair.  (this public key is
   itself signed by the network security manager to bind the public to a
   specific net member ID.

3.10 Member signature:

   Asymmetric signature using the selected members private key.

3.11 Member public:

   Public half of the selected members signature key pair.  (this public
   key is itself signed by the network security manager to bind the
   public to a specific net member ID.

3.12 Controller permissions:

   Controller permissions are assigned by the security manager.  The
   security managers signature will bind the permissions to the
   controller ID.

3.13 SKEK ID:

   This field identifies exactly which SKEK is being created.  This
   allows multiple groups to interoperate on a net simultaneously.

3.14 SKEK creation field:

   This field contains the information contributed for use in the KEK
   creation process.






Harney & Muckenhirn           Experimental                      [Page 5]

RFC 2093                   GKMP Specification                  July 1997


3.15 Member permissions:

   Member permissions are assigned by the security manager.  The
   security managers signature will bind the permissions to the
   controller ID.

3.16 Encrypted Grp Keys:

   This data item is encrypted in the KEK (session or group) created for
   the download of keys.  It is the GTEK and GKEK created for a group.
   A checksum is also encrypted.  This ensures the confidentiality and
   data integrity of the GTEK and GKEK.

3.17 Confirmation of decryption:

   This is a short (byte) field indicating decryption of the message and
   exactly what type of message was decrypted.

3.18 Request:

   A request field contains the specific request one net member may make
   to another.  The requests range from (group join, CRL update,
   pairwise TEK generation, detection, group creation, status).

   Member delete list:

   A list of group members being administratively deleted from the
   group.

4 Message definitions

4.1 Command_Create Group:

   This message contains the following data item primitives (Group
   members, Grp ID, Grp controller ID, Grp action, Grp permissions,
   Rekey interval, Token version, Token signature, Token public key).
   This message may be confidential due to the group permissions field.