Group Key Management Protocol (GKMP) Architecture
RFC 2094

 
Document Type RFC - Experimental (July 1997; No errata)
Was draft-harney-gkmp-arch (individual)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2094 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
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,
Show full document text