summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2094.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2094.txt')
-rw-r--r--doc/rfc/rfc2094.txt1235
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc2094.txt b/doc/rfc/rfc2094.txt
new file mode 100644
index 0000000..32705e9
--- /dev/null
+++ b/doc/rfc/rfc2094.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+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
+ validation send to them the current GKP.(Access control is not
+ defined in this document, but it is assumed that both hierarchical
+ and discretionaly (rule-based and identity-based) access control will
+ be supported.) These regional key distributors perform the same
+ functions as the controller, except that they do not create the GKP.
+ This concept can be expanded to the point where all current members
+ are capable of downloading the GKP, and passing on that capability.
+
+ Group Rekey -- When the group need rekeying the procedure would be
+ identical to the sender initiated case. The controlling 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.
+
+2.3 GKMP Features
+
+ This section highlights areas which we believe the GKMP approach has
+ advantages over the "traditional" KDC based approaches.
+
+2.3.1 Multicast
+
+ Multicast protocols are a growing area of interest for the Internet.
+ The largest benefit of a multicast protocol is the ability of several
+ receivers to simultaneously get the same transmission. If the
+ transmission is of a sensitive nature, it should be encrypted. This
+
+
+
+Harney & Muckenhirn Experimental [Page 6]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ means that the all members of the group must share the same
+ encryption key to take benefit of the multicast transmission.
+
+ To date the only way of setting up a group of symmetric keys is with
+ the assistance of a centralized key management facility. This
+ facility would act as a key broker creating a distributing key to
+ qualified group members. There are several problems with this
+ centralized concept. These problems give rise to many of the
+ following motivations for creating a distributed key management
+ protocol.
+
+2.3.2 Increase the autonomy of key groups
+
+ The GKMP proposes to extend the pairwise key paradigm to grouped
+ keys. This protocol can be integrated into the communication
+ protocols or applications and can become invisible to the host's
+ operator. We will use peer review to enforce our security policy.
+
+ The GKMP allows any host on a network to create and manage a secure
+ group. Maintenance of these group keys can be performed by the hosts
+ interested in the group. The groups themselves will be relatively
+ autonomous. This simplifies the installation of this technology
+ allowing more host to use secure multicast communications.
+
+2.3.3 Latency
+
+ Latency refers to the time to set-up or tear down or to re-key a
+ group. In short this corresponds to the length of time it would take
+ to set-up a multicast address.
+
+ The GKMP can allow delegation of group creation authority to any host
+ in the network. In essence, when a host needs a group it will have
+ the tools needed to create that group and manage it. Additionally,
+ since the host only needs to create a single group it can concentrate
+ on that particular group.
+
+ In the current centralized key distribution approach. The group must
+ be requested from the central site. The central site would process
+ that request in accordance with it's priority and current workload.
+ Latencies would develop if the workload of the central site gets
+ unwieldy or if the communications to the site become overloaded.
+
+2.3.4 Extendibility
+
+ One of the problems with a centralized key distribution system is the
+ concentration of key management workload at a single site. The
+ process of creating key groups -- key creation, access review,
+ communication to group members takes time and effort. As the number
+
+
+
+Harney & Muckenhirn Experimental [Page 7]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ of groups on the network grows and the number of group members group.
+ The workload at that central sight quickly reaches capacity.
+
+ GKMP should allow a great number of groups to exist on the Internet
+ without overloading any particular host. Delegation of the net wide
+ group creation and management workload places the burden of
+ maintaining groups on the hosts interested in using those groups.
+ Not only is this more efficient, but it places the burden in an
+ appropriate location.
+
+ The GKMP distributes the communication requirements to manage groups
+ across the network. Each group manages the group using the same
+ communication resources needed to pass traffic. It is likely that if
+ a communication group can support the traffic of a group, it will be
+ able to support the minimal traffic needed to management the keys for
+ that group.
+
+ GKMP provides it's own access control, based on signed netwide
+ permission certificates. This partially disseminates the burden of
+ access control and permission management. A system wide authority
+ must assign the permission certificates, but day to day access
+ control decisions are a GKMP responsibility.
+
+2.3.5 Operating expense
+
+ A centralized key distribution site contains, at one time or another,
+ the keys for the net. This is a valuable target for someone to
+ compromise. To protect this site physical and procedural security
+ mechanisms are employed (e.g., guards, fences, intrusion alarms, two
+ person safes, no-alone zones). These mechanisms do not come cheap.
+
+ Allowing the hosts to create and manage their keys eliminates the
+ need for an on-line centralized key distribution site. The protocol
+ approach restricts access to the keys to the hosts using them (the
+ minimal set). Since, the encryption mechanisms will have already
+ incurred the cost to be physically secured there is no additional
+ cost levied on the system by the key management system.
+
+2.3.6 Communication Resources
+
+ Because a centralized site is involved in creating, distributing,
+ rekeying, and providing access control for every group, it is
+ frequently accessed. The communication resources available to this
+ site often become a bottle neck for the groups. Therefore a big pipe
+ is usually installed to this facility.
+
+
+
+
+
+
+Harney & Muckenhirn Experimental [Page 8]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ The GKMP proposes delegating most of the key creation, distribution,
+ rekey and access control mission to the hosts that need the secure
+ communication. There no longer is a single third party that must be
+ consulted prior to every group key management action. Hence, the
+ communications requirements to manage the keys have shifted to the
+ groups themselves. The need for special high capacity communications
+ has been eliminated.
+
+2.3.7 Reliability
+
+ Delegating key management responsibility to the groups eliminates the
+ centralized key management site as a single point of failure. The
+ groups that will use the key are responsible for it. If the
+ communications system fails for the key management it is also down
+ for the communications.
+
+ The GKMP will attempt to delegate as many functions to the group as
+ possible. There will be some functions which still need to be
+ performed outside of the group (granting of privileges). These
+ functions can still fail. The GKMP will operate on the old set of
+ permissions. These functions need not be in-line. They are
+ performed separate from the key management actions and are not
+ crucial to day-to-day operation.
+
+2.3.8 Security
+
+ People are the most risky element for security. A distributed
+ protocol eliminates many people from the key distribution chain.
+ This limits "exposure" of the key.
+
+3 GKMP Protocol Overview
+
+3.1 Supporting functions
+
+ A secure key management protocol needs a number of supporting
+ functions, especially in a military environment. The two major
+ support functions are security management and network group
+ management. In the commercial world a company could provide these
+ support functions.
+
+ The issue of Security Management is permission management, in a
+ military environment separation of data occurs along classical
+ classification lines (i.e., TOP SECRET to UNCLASSIFIED). In the
+ commercial world these levels are proprietary or need to know access.
+
+ Network group management provides an interface to the communications
+ system and control of network resources. Some entity either a
+ commercial or military system, the host or network operations center,
+
+
+
+Harney & Muckenhirn Experimental [Page 9]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ must provide the key management protocol with a list of the group
+ members. Also, if the network resources, bandwidth and processing,
+ are considered scarce a management structure must allocate them.
+
+3.1.1 Security management
+
+ Security management is a role performed for the entire network. It
+ involves netwide issues of permission management, initialization of
+ software, and compromise recovery. The GKMP relies on security
+ management to operate. Refer to figure 1: Security management view.
+
+ The GKMP must assume trusted handling of the protocol software prior
+ and during installation. If the GKMP is to use peer to peer access
+ control the system must control the assignment of permissions. These
+ permissions must be monitored and updated as needed. Finally,
+ overview of these permissions must include the maintenance of a
+ Certificate Revocation List.
+
+ Secure start-up We need to control the process of loading GKMP
+ software onto a host and initializing it. The protocol needs keys,
+
+
+ Security Manager --> --> --> --> --> --> --> --> --> --> --> Network
+ Permissions
+ Secure Start-ups
+ Compromise recovery
+
+ Figure 1: Security Management View
+
+ public and private, to operate. It also must have identify
+ information of the host on whose behalf it will act.
+
+ There are some life cycle and security concerns with the software
+ while in transit, stored, distributed, and installed. A one time
+ start-up procedure must verify the identity of the host. Procedural
+ and physical identification techniques will verify the identity of
+ the host (i.e., the Armed Forces Courier Service (ARFCS) accounting,
+ or registered mail). Upon key delivery the security manager logs
+ it's receipt and assumes responsibility for the key.
+
+ After proper installation of the software a paper trail verifies the
+ recipient. The computer would initiate an association with the
+ security management function to initialize the protocol software
+ (create a unique public and private key pair for network operation
+ and receive network permissions). This activation process uses keys
+ distributed with the software (good only for initialization) to
+ secure an exchange with the security manager. The host then creates
+ a unique public and private pair and sends the public key to the
+
+
+
+Harney & Muckenhirn Experimental [Page 10]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ security manager. The security manager creates a credential that
+ uniquely identifies the host and it permissions. This credential is
+ signed by the security management with its private key and can be
+ verified by all net members with the public key.
+
+ Permission management Each host on the network is given a
+ permissions certificate signed by the security management which
+ uniquely identify that host and identifies the access permissions it
+ is allowed. These permission certificates are used by the network
+ hosts to assign permissions to other hosts.
+
+ This process assigns permissions to equipment or human beings in
+ accordance with their duties. This process involves security
+ clearances and human judgment therefore it is outside the scope of
+ this protocol.
+
+ The security management function, especially in military operations,
+ would be responsible for managing permissions and classifications at
+ each host. In the commercial world, permission management
+ corresponds to projects or duties.
+
+
+ Compromise recovery management If a group member is found
+ compromised, the protocol must facilitate the exclusion of the
+ compromised member and return to secure operations. The security
+ management function will provide control of compromise recovery.
+
+ Usually, physical inspections or accounting techniques find
+ compromises. These separate systems report the compromise to the key
+ management system. We must assume the loss of all key resident at
+ that host. The security management function will rescind the
+ permission allocated to this compromised host. We create a list of
+ all know compromised hosts and distribution that list across the
+ network. Each host is then responsible for reviewing the propriety
+ of each association and enforcing access control to data.
+
+3.1.2 Group management
+
+ The group manager interacts with other management functions in the
+ network to provide the GKMP with group membership lists and group
+ relevant commands. The GKMP deals strictly with cryptographic key.
+ It relies on external communication and network management services
+ to supply network related information. Primarily, it relies on the
+ network management service to provide it with the addresses of group
+ members (if the group is sender initiated).
+
+
+
+
+
+
+Harney & Muckenhirn Experimental [Page 11]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ The GKMP allows an external entity to determine the controller of a
+ group. The controller of the group should be able to handle the
+ additional processing and communication requirements associated with
+ the role. If this is not a necessary function given the
+ implementation, this assignment of controller duties can be set to
+ some automated default. However, even if defaulted some external
+ management entity determines how the role of controller is allocated.
+
+ The group manager can receive group progress reports from the group
+ controller. The GKMP provides a service for the network. It makes
+ sense that someone in the network is interested in the progress of
+ this service. The GKMP can provide progress reports. It is up to
+ the network management to determine the manner and recipient of the
+ reports. Reference figure 2: Network manager interaction.
+
+
+ Group Manager --> --> --> --> --> --> --> --> -->Network Manager
+ /\
+ |
+ | Commands, Role assignments
+ | Group member list, Reports
+ |
+ \/
+ {[Group Controller] Network}
+
+ Figure 2: Network Manager Interaction
+
+ Group to member mapping When the GKMP is implemented in sender
+ initiated group establishment mode, a list of group member addresses
+ must be provided as part of the group establishment command. The
+ GKMP will use these addresses to contact the group members and create
+ the group.
+
+ The creation of groups involves the assignment of a group address,
+ update of router databases, and distribution of this group address to
+ the group members. This is a classic function of network management.
+ The GKMP group controller would be another recipient of this
+ information.
+
+ Protocol role allocation The Group Management Protocol assigns roles
+ to members of a particular group. These roles are binary one is
+ either the control over the group or a member of a group. Some
+ external entity will allocate the identity of the group controller
+ and group receiver. This is a desirable aspect because some
+ computers are more capable (i.e., central site, great deal of process
+ power available to control a group). We allow some external entity
+ to allocate these roles to individual group members, this is
+ important in the military application do to the fact that in a
+
+
+
+Harney & Muckenhirn Experimental [Page 12]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ commercial application the allocating authority and group controller
+ may very well always be the same.
+
+ Group key progress reporting The Group Key Management Protocol has
+ to be able to report to somebody. If we create a group, we should
+ report it to group requester. Contrarily if we are not able to
+
+
+ Network = {[(Group 1 controller) Group 1 members],
+ [(Group 2 controller) Group 2 members],
+ [(Group 3 controller) Group 3 members], }
+
+ Figure 3: Distributed Group Management
+
+ create a group we should report that especially since failure to
+ create a group at least as a first study will highly correlate with a
+ failure of the underlying communications. The Group Key Management
+ Protocol does not have an ability to fix the underlying
+ communications so the communication management function must deal
+ with these failures.
+
+3.2 Protocol 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 controller and
+ receiver. The controller initiates the creation of the key, forms
+ the key distribution messages, and collects acknowledgment of key
+ receipt from the receivers. The receivers wait for a distribution
+ message, decrypt, validate, and acknowledge the receipt of new key.
+
+ One of the essential concepts behind the GKMP is delegation of group
+ control. Since each host in the network has the capability to act as
+ a group controller, the processing and communication requirements of
+ controlling the groups in the network can be distributed equitably
+ throughout the network. This avoids potential single points of
+ failure, communication congestion, and processor overloading. Refer
+ to figure 3: Distributed group management.
+
+3.2.1 Group controller
+
+ The group controller 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 group controller and
+ could assume this duty upon assignment.
+
+
+
+
+
+Harney & Muckenhirn Experimental [Page 13]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ The group controller 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).
+
+3.2.2 Group receiver
+
+ Simply stated a group receiver is any group member who is not acting
+ as the controller. The group receivers 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.
+
+3.3 Scenarios
+
+3.3.1 Group establishment
+
+ The protocol to establish a group of host that share a cryptographic
+ key must create a high quality key, verify that all intended
+ recipients have permission to join the group, distribute the key to
+ all qualified members, and report on the progress. This process
+ consists of two phases: creation of the key and distribution of the
+ key. Refer to figure 4: Group Establishment.
+
+ The group establishment process is proceeds in the following manner.
+ First, a "create group" command is issued to the group commander.
+ The group controller validates the command to ensure it came from an
+ authorized commander and the group is within the controller's
+ permission range. Next, the controller creates a key. Then that key
+ is passed to the group members, after they pass the peer to peer
+ review process.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney & Muckenhirn Experimental [Page 14]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ Group Controller
+ |
+ |
+ \/ Create group keys
+ |--> --> --> --> --> --> -->Group member
+ |
+ |
+ \/ Distribute keys
+ |--> --> --> --> --> --> --> Group member
+ |
+ |
+ \/ Distribute keys
+ |--> --> --> --> --> --> --> Group member
+ |
+ |
+ \/ Distribute keys
+ |--> --> --> --> --> --> --> Group member
+
+ Figure 4: Group Establishment
+
+ Validate command The create group command is signed by the group
+ commander ( they may be the same device). This signature should be
+ asymmetric in nature. The public key to validate this command can be
+ sent with the command itself, if the public bound to the identity of
+ the commander.
+
+ The group controller receives the command. It verifies that the
+ signature, thereby ensuring the message was sent by the claimed
+ source and the message has not been modified in transit.
+
+ Creation of group keys The controller initiates the creation of two
+ keys for use in the group. The creation of a cryptographic key
+ requires that the key be sufficiently random. Randomizers, capable
+ of creating high grade cryptographic key, tend to be hardware based
+ and are not likely to be practical for this protocol. There are
+ several established key creation protocols based in software (e.g.,
+ Diffe-Hellman, FireFly, RSA). All these software based algorithms
+ involve two hosts cooperating to create a cryptographic key. These
+ software algorithms are more appropriate for this protocol.
+
+ Also important, in the creation of these keys, is verification of the
+ authorization of the key creation partner. Authorization to posses
+ the keys include permissions that equal or exceed the group traffic
+ and identity verification.
+
+
+
+
+
+
+
+Harney & Muckenhirn Experimental [Page 15]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ Distribution of group keys The controller distributes the group keys
+ to the net members. The controller must verify the identity and
+ permissions of each member prior to the key being distributed.
+
+
+ Rekey Group
+ Group Controller --> --> --> --> --> -->{Group (group member 1-n)}
+
+
+ Figure 5: Group Rekey
+
+ Likewise, the net member must verify the controller's identity,
+ authorization to perform this action, and permissions.
+
+ The key being distributed is the same level as the data that it will
+ encrypt. Hence, we must encrypt the key during distribution. If no
+ suitable key exists between the controller and member, a new key must
+ be created. This new key is cooperatively created between the
+ controller and net member in a similar manner as the net keys.
+
+ The controller creates a message for encryption in the key held
+ between the controller and member. This message will include key
+ management information and the keys.
+
+3.3.2 Group rekey
+
+ Cryptographic key has a life span. New key must replace "old" key
+ prior to the end of its cryptographic life. This process is rekey.
+
+ Rekey has the advantage of using an existing cryptographic
+ association to distribute key. Also, there is no requirement to
+ verify the identity and authorization for the other members.
+ Identify and authorization are assumed.
+
+ A group rekey consists of two stages. First the Group Controller
+ creates new group keys. Second these "new" keys are sent to the
+ Group Members in a multicast message. Refer to figure 5: Group
+ Rekey.
+
+ Creation of group keys The controller of the rekey will create the
+ new keys in exactly the same manner as used during group
+ establishment.
+
+
+
+
+
+
+
+
+
+Harney & Muckenhirn Experimental [Page 16]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ Distribution of group keys The GKMP creates a message for the group
+ address. This message uses one of the keys distributed during group
+ establishment to encrypt the new keys. It also contains an
+ authorization token identifying the controller as the rekey agent and
+ new management data. All members of the group using a multicast
+ protocol (if one exists) accept this message.
+
+ The message which rekeys the group encrypts the new keys in the
+ existing KEK. Since all group members possess the KEK the entire
+ group can decrypt this message.
+
+ The token authorizing the group controller to perform this rekey is
+ also included. This token is asymmetrically signed by the group
+ commander. It uniquely identifies the group controller's authority
+ to rekey this group. It also identifies the group the level of
+ traffic and rekey interval.
+
+3.3.3 Deletion
+
+ It is desirable to be able to delete group members for either
+ administrative purposes or security reasons. Administrative deletion
+ is the deletion of a trusted group member. It is possible to confirm
+ the deletion of trusted group members. Security relevant deletion is
+ the deletion of an untrusted member. It assumes that the member is
+ ignore all deletion commands.
+
+ Administrative delete Administrative deletion removes the group keys
+ from trusted group members. This deletion consists of two messages
+ the first sends a command to the group encrypted in the groups TEK.
+ The command essentially says: acknowledge receipt and then delete
+ group keys. This command is signed by the group controller to
+ prevent unauthorized deletions.
+
+ The acknowledgment message is also encrypted under the group TEK and
+ is sent to acknowledge receipt of the command. We could acknowledge
+ accomplishment of the command if the net is willing to accept the
+ burden of creating pairwise keys between the exiting group members
+ and the group controller.
+
+ Compromise recovery Compromise recovery is the deletion of untrusted
+ group members. This actually involves the creation of an entirely
+ new group, without the untrusted member. Once the new group is
+ created, net operations can be shifted to the new group, effectively
+ denying the untrusted member access to the data.
+
+
+
+
+
+
+
+Harney & Muckenhirn Experimental [Page 17]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ There is always a trade-off between security and continued net
+ operations when a member is found to be compromised. The security
+ first position states that if a member is compromised, the group must
+ be destroyed and then a new secure group created. However,
+ operational concerns sometimes out weigh the security concerns. The
+ operational position is that the group will continue to operate with
+ the compromised member and will shift to a new secure group when it
+ becomes available.
+
+ The GKMP does not mandate either position. However, the speed and
+ flexibility of the GKMP does allow a new secure group to be created
+ quickly. Thereby, restricting the potential damage done by a
+ compromised member.
+
+ Once a member is found to be compromised, that members certificate is
+ added to a Certificate Revocation List (CRL). The CRL is an
+ asymmetrically signed piece of data, signed by a security manager.
+ The list is made up of compromised resource ID's, a version of the
+ CRL, and perhaps an identifier of the security manager. The CRL is
+ accessed every time a new key is negotiated. If one of the key
+ creators is on the CRL the key is destroyed and interaction
+ terminated.
+
+ The idea behind a CRL is each host would keep records of all open
+ associations and compromised resources. The host would then make
+ sure that it does not have and will not create a secure association
+ open with anyone who is on the CRL. The CRL concept of becomes more
+ complicated in the case of groups. This is because it is not
+ necessary for every member in the group to know who the other group
+ members are. Hence, a group member does not have sufficient
+ information to identify compromised group associations. The GKMP
+ proposes that the group controllers be responsible for reviewing the
+ CRL and taking appropriate actions should a group member be
+ compromised.
+
+ Another issue with CRLs is the speed that they can be distributed
+ across a network. Every time a key is created the cooperating hosts
+ exchange the version number of their current CRL. If the versions do
+ not match. The most current version is passed to the host with the
+ old version. Hence, CRLs propagate when keys are created. If this
+ is infrequently and there is a single CRL insertion point, the list
+ may take a few days to move across the net. The GKMP allows a
+ speedier distribution of the CRL.
+
+ The GKMP delegates control of groups to specific group controllers (a
+ subset of the network). These controllers are responsible for
+ maintaining the security of the group. If quicker distribution of
+ the CRL were desired, the CRL generator ( security management
+
+
+
+Harney & Muckenhirn Experimental [Page 18]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ function could seed the CRL at these controllers. Controllers are
+ points of key management activity and are logical CRL staging areas.
+
+4 Issues
+
+ What are the unresolved issues with this protocol?
+
+4.1 Access Control
+
+ One interesting issue with a grouped key protocol is access control.
+ This is because we are moving away from having humans in the loop or
+ having a central authority to check the propriety of the group.
+
+ The group protocol must police itself. It must ensure that each
+ member of a group meets the classic military access control policy (
+ i.e., a group member`s classification level must be higher or equal
+ to the classification of the group that it's in).
+
+ Is allocation of permissions by a higher authority sufficient to
+ provide access control? Or is a more discretionary mechanism
+ necessary?
+
+4.2 MLS
+
+ A GKMP must be capable of operating in a multi-level secure
+ environment. The integration of a key management protocol capable of
+ creating keys of several different classifications with an operating
+ system capable of operating with multiple classifications in non-
+ trivial.
+
+ Classified label standards needed to be incorporated. The
+ classification labels used by the key management protocol should
+ coincide with the labels used by the MLS operating system. These
+ interoperability issues need to be addressed.
+
+4.3 Error Conditions
+
+ A group protocol is more complex than a pairwise protocol hence there
+ are more possible error conditions. In a pairwise protocol you have
+ two parties; they must communicate between themselves. It is
+ relatively simple to define an take care of all the potential error
+ conditions.
+
+
+
+
+
+
+
+
+
+Harney & Muckenhirn Experimental [Page 19]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ One assumption with any group protocol is the underlying internet is,
+ to some degree, always broken. The protocol designer has to assume
+ that messages will be delayed or destroyed in transit, all member
+ will not receive all multicast messages, and acknowledgment of
+ actions may not be delivered. This assumption is important if a
+ protocol uses multicast functions to speed-up actions.
+
+ The protocol must provide recovery mechanisms to allow group members
+ to recover from loss of messages. It must recover in a way that is
+ transparent to the host and underlying communications network.
+
+ For example, there is an issue whether or not we can create an
+ application layer acknowledgment of multi-cast actions. The issue
+ deals with the required bandwidth that acknowledgment would take up.
+ It may be much more friendly to the underlying communications systems
+ to have each member identify potential errors and correct them in a
+ pairwise manner. The task of handling error conditions in a key
+ management protocol is double difficult because many error conditions
+ can be induced error condition (invoked by a third party trying to
+ break the security of that system) to retrieve there key that is in
+ transit or to block the successful dissemination of a key thereby
+ attacking the system security mechanism.
+
+4.4 Commercial vs. Military
+
+ Commercial and military key management differ in many ways.
+ Commercial Key management protocols tend to emphasize inter-
+ operability, freedom of action, and performance. Military systems
+ tend to emphasize security and control of operations.
+
+ There will be a difference in cryptographic algorithms. The military
+ protocol would certainly use high grade encryption because of
+ protecting classified information. The commercial system would
+ probably using algorithms. and techniques certified for unclassified
+ communication systems. The main difference is in the algorithms
+ length and type.
+
+ A military protocol would require more management and structure than
+ a commercial one. The military has always adopted a hierarchical
+ communication structure and the commercial system, especially if you
+ look at the internet, work mainly by anarchist style.
+
+4.4.1 Algorithm Type
+
+ Another difference between military and commercial key management is
+ the type of cryptographic algorithms. The commercial world uses
+ encryption algorithms like DES and in the future Skipjack. The
+ military uses other cryptographic algorithms that differ in key
+
+
+
+Harney & Muckenhirn Experimental [Page 20]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ length and have more restrictions. An example of this would be the
+ identification of ACCORDION, as a military key encryption algorithm
+ as used in the EKMS program run by NSA.
+
+ Any experiments with a grouped key management protocol must consider
+ the differences between military and commercial algorithms. The
+ commercial algorithms tend to be quicker to implement, run faster,
+ involve less processing time, and allows an unclassified experiment.
+ However, we must be careful not paint an unrealistic picture of the
+ performance of the protocol based on these commercial algorithms. A
+ military algorithm tends to be more cumbersome to process, slow to
+ process, require more bandwidth, a lot of unpleasant characteristics
+ from the commercial stand point, but allow for a higher grade of
+ cryptographic security. One way of dealing with the disparity
+ between algorithms is to use the commercial cryptographic algorithms
+ and leave the fields the size used by a comparative DOD cryptographic
+ algorithms and insert delays to simulate DOD algorithm processing
+ times.
+
+4.4.2 Management Philosophy
+
+ Management for a military network is far more structured than a
+ commercial network. A military network would restrict the creation
+ of network groups, the rekeying of those groups, and access to the
+ data contained in those groups. In contrast the commercial world
+ would enable any member in the network to create a group and allow
+ any other member of the net to join that group.
+
+ The group Key Management Protocol must allow for both these
+ architectures i.e., all for very structure command control hierarchy
+ and another free form group creation.
+
+4.5 Receiver Initiated Operations
+
+ How do they actually work, what are the performance trades,
+ experimentation needed.
+
+ Who is the group leader?
+
+ How do we elect a new leader?
+
+ Will multiple leaders be created?
+
+ Will rule based access control allow fine enough access disgression?
+
+
+
+
+
+
+
+Harney & Muckenhirn Experimental [Page 21]
+
+RFC 2094 GKMP Architecture July 1997
+
+
+ Methods for distributed GKP/GRP dissemination need to be examined.
+ This includes:
+
+ o resolving group identification issues, such as how to notify
+ potential members of membership requirements without compromising
+ any security-relevant information about the group;
+
+ o approaches for rapidly identifying GKP/GRP sources must be
+ developed, such as a "Key ARP" whereby a new member broadcasts
+ into the group a request for key service and existing members
+ resolve which will provide service; and,
+
+ o Security effects of distributing access control decisions must
+ also be reviewed.
+
+5 Security Considerations
+
+ This document, in entirety, concerns security.
+
+6 Addresses of Authors
+
+ Hugh Harney
+ SPARTA, Inc.
+ Secure Systems Engineering Division
+ 9861 Broken Land Parkway, Suite 300
+ Columbia, MD 21046-1170
+ United States
+ telephone: +1 410 381 9400 (ext. 203)
+ electronic mail: hh@columbia.sparta.com
+
+
+
+ Carl Muckenhirn
+ SPARTA, Inc.
+ Secure Systems Engineering Division
+ 9861 Broken Land Parkway, Suite 300
+ Columbia, MD 21046-1170
+ United States
+ telephone: +1 410 381 9400 (ext. 208)
+ electronic mail: cfm@columbia.sparta.com
+
+
+
+
+
+
+
+
+
+
+
+Harney & Muckenhirn Experimental [Page 22]
+