RFC 4535
GSAKMP: Group Secure Association Key Management Protocol
Pages: 106
Proposed Standard
Proposed Standard
Part 1 of 4 – Pages 1 to 15
Network Working Group H. Harney Request for Comments: 4535 U. Meth Category: Standards Track A. Colegrove SPARTA, Inc. G. Gross IdentAware June 2006 GSAKMP: Group Secure Association Key Management Protocol Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).Abstract
This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys.
Table of Contents
1. Introduction ....................................................7 1.1. GSAKMP Overview ............................................7 1.2. Document Organization ......................................9 2. Terminology .....................................................9 3. Security Considerations ........................................12 3.1. Security Assumptions ......................................12 3.2. Related Protocols .........................................13 3.2.1. ISAKMP .............................................13 3.2.2. FIPS Pub 196 .......................................13 3.2.3. LKH ................................................13 3.2.4. Diffie-Hellman .....................................14 3.3. Denial of Service (DoS) Attack ............................14 3.4. Rekey Availability ........................................14 3.5. Proof of Trust Hierarchy ..................................15 4. Architecture ...................................................15 4.1. Trust Model ...............................................15 4.1.1. Components .........................................15 4.1.2. GO .................................................16 4.1.3. GC/KS ..............................................16 4.1.4. Subordinate GC/KS ..................................17 4.1.5. GM .................................................17 4.1.6. Assumptions ........................................18 4.2. Rule-Based Security Policy ................................18 4.2.1. Access Control .....................................19 4.2.2. Authorizations for Security-Relevant Actions .......20 4.3. Distributed Operation .....................................20 4.4. Concept of Operation ......................................22 4.4.1. Assumptions ........................................22 4.4.2. Creation of a Policy Token .........................22 4.4.3. Creation of a Group ................................23 4.4.4. Discovery of GC/KS .................................24 4.4.5. GC/KS Registration Policy Enforcement ..............24 4.4.6. GM Registration Policy Enforcement .................24 4.4.7. Autonomous Distributed GSAKMP Operations ...........24 5. Group Life Cycle ...............................................27 5.1. Group Definition ..........................................27 5.2. Group Establishment .......................................27 5.2.1. Standard Group Establishment .......................28 5.2.1.1. Request to Join ...........................30 5.2.1.2. Key Download ..............................31 5.2.1.3. Request to Join Error .....................33 5.2.1.4. Key Download - Ack/Failure ................34 5.2.1.5. Lack of Ack ...............................35 5.2.2. Cookies: Group Establishment with Denial of Service Protection .................................36 5.2.3. Group Establishment for Receive-Only Members .......39
5.3. Group Maintenance .........................................39
5.3.1. Group Management ...................................39
5.3.1.1. Rekey Events ..............................39
5.3.1.2. Policy Updates ............................40
5.3.1.3. Group Destruction .........................40
5.3.2. Leaving a Group ....................................41
5.3.2.1. Eviction ..................................41
5.3.2.2. Voluntary Departure without Notice ........41
5.3.2.3. De-Registration ...........................41
5.3.2.3.1. Request to Depart ..............41
5.3.2.3.2. Departure_Response .............43
5.3.2.3.3. Departure_ACK ..................44
6. Security Suite .................................................45
6.1. Assumptions ...............................................45
6.2. Definition Suite 1 ........................................45
7. GSAKMP Payload Structure .......................................47
7.1. GSAKMP Header .............................................47
7.1.1. GSAKMP Header Structure ............................47
7.1.1.1. GroupID Structure .........................51
7.1.1.1.1. UTF-8 ..........................51
7.1.1.1.2. Octet String ...................52
7.1.1.1.3. IPv4 Group Identifier ..........52
7.1.1.1.4. IPv6 Group Identifier ..........53
7.1.2. GSAKMP Header Processing ...........................53
7.2. Generic Payload Header ....................................55
7.2.1. Generic Payload Header Structure ...................55
7.2.2. Generic Payload Header Processing ..................56
7.3. Policy Token Payload ......................................56
7.3.1. Policy Token Payload Structure .....................56
7.3.2. Policy Token Payload Processing ....................57
7.4. Key Download Payload ......................................58
7.4.1. Key Download Payload Structure .....................58
7.4.1.1. Key Datum Structure .......................61
7.4.1.2. Rekey Array Structure .....................63
7.4.2. Key Download Payload Processing ....................63
7.5. Rekey Event Payload .......................................64
7.5.1. Rekey Event Payload Structure ......................64
7.5.1.1. Rekey Event Header Structure .............66
7.5.1.2. Rekey Event Data Structure ...............67
7.5.1.2.1. Key Package Structure ..........68
7.5.2. Rekey Event Payload Processing .....................69
7.6. Identification Payload ....................................71
7.6.1. Identification Payload Structure ...................71
7.6.1.1. ID_U_NAME Structure .......................74
7.6.2. Identification Payload Processing ..................74
7.6.2.1. ID_U_NAME Processing ......................75
7.7. Certificate Payload .......................................75
7.7.1. Certificate Payload Structure ......................75
7.7.2. Certificate Payload Processing .....................77
7.8. Signature Payload .........................................78
7.8.1. Signature Payload Structure ........................78
7.8.2. Signature Payload Processing .......................80
7.9. Notification Payload ......................................81
7.9.1. Notification Payload Structure .....................81
7.9.1.1. Notification Data - Acknowledgement
(ACK) Payload Type ........................83
7.9.1.2. Notification Data -
Cookie_Required and Cookie Payload Type ...83
7.9.1.3. Notification Data - Mechanism
Choices Payload Type ......................84
7.9.1.4. Notification Data - IPv4 and IPv6
Value Payload Types .......................85
7.9.2. Notification Payload Processing ....................85
7.10. Vendor ID Payload ........................................86
7.10.1. Vendor ID Payload Structure .......................86
7.10.2. Vendor ID Payload Processing ......................87
7.11. Key Creation Payload .....................................88
7.11.1. Key Creation Payload Structure ....................88
7.11.2. Key Creation Payload Processing ...................89
7.12. Nonce Payload ............................................90
7.12.1. Nonce Payload Structure ...........................90
7.12.2. Nonce Payload Processing ..........................91
8. GSAKMP State Diagram ...........................................92
9. IANA Considerations ............................................95
9.1. IANA Port Number Assignment ...............................95
9.2. Initial IANA Registry Contents ............................95
10. Acknowledgements ..............................................96
11. References ....................................................97
11.1. Normative References .....................................97
11.2. Informative References ...................................98
Appendix A. LKH Information ......................................100
A.1. LKH Overview .............................................100
A.2. LKH and GSAKMP ...........................................101
A.3. LKH Examples .............................................102
A.3.1. LKH Key Download Example ..........................102
A.3.2. LKH Rekey Event Example ..........................103
List of Figures
1 GSAKMP Ladder Diagram .........................................28 2 GSAKMP Ladder Diagram with Cookies ............................37 3 GSAKMP Header Format ..........................................47 4 GroupID UTF-8 Format ..........................................51 5 GroupID Octet String Format ...................................52 6 GroupID IPv4 Format ...........................................52 7 GroupID IPv6 Format ...........................................53 8 Generic Payload Header ........................................55 9 Policy Token Payload Format ...................................56 10 Key Download Payload Format ...................................58 11 Key Download Data Item Format .................................59 12 Key Datum Format ..............................................61 13 Rekey Array Structure Format ..................................63 14 Rekey Event Payload Format ....................................64 15 Rekey Event Header Format .....................................66 16 Rekey Event Data Format .......................................68 17 Key Package Format ............................................68 18 Identification Payload Format .................................72 19 Unencoded Name (ID-U-NAME) Format .............................74 20 Certificate Payload Format ....................................76 21 Signature Payload Format ......................................78 22 Notification Payload Format ...................................81 23 Notification Data - Acknowledge Payload Type Format ...........83 24 Notification Data - Mechanism Choices Payload Type Format......84 25 Vendor ID Payload Format ......................................86 26 Key Creation Payload Format ...................................88 27 Nonce Payload Format ..........................................90 28 GSAKMP State Diagram ..........................................92 29 LKH Tree .....................................................100 30 GSAKMP LKH Tree ..............................................101
List of Tables
1 Request to Join (RTJ) Message Definition ......................30 2 Key Download (KeyDL) Message Definition .......................31 3 Request to Join Error (RTJ-Err) Message Definition ............33 4 Key Download - Ack/Failure (KeyDL-A/F) Message Definition .....34 5 Lack of Ack (LOA) Message Definition ..........................35 6 Cookie Download Message Definition ............................37 7 Rekey Event Message Definition ................................40 8 Request_to_Depart (RTD) Message Definition ....................42 9 Departure_Response (DR) Message Definition ....................43 10 Departure_ACK (DA) Message Definition .........................44 11 Group Identification Types ....................................48 12 Payload Types .................................................49 13 Exchange Types ................................................49 14 Policy Token Types ............................................57 15 Key Download Data Item Types ..................................60 16 Cryptographic Key Types .......................................62 17 Rekey Event Types .............................................66 18 Identification Classification .................................72 19 Identification Types ..........................................73 20 Certificate Payload Types .....................................77 21 Signature Types ...............................................79 22 Notification Types ............................................82 23 Acknowledgement Types .........................................83 24 Mechanism Types ...............................................84 25 Nonce Hash Types ..............................................85 26 Types Of Key Creation Information .............................89 27 Nonce Types ...................................................91 28 GSAKMP States .................................................93 29 State Transition Events .......................................94
1. Introduction
GSAKMP provides policy distribution, policy enforcement, key distribution, and key management for cryptographic groups. Cryptographic groups all share a common key (or set of keys) for data processing. These keys all support a system-level security policy so that the cryptographic group can be trusted to perform security- relevant services. The ability of a group of entities to perform security services requires that a Group Secure Association (GSA) be established. A GSA ensures that there is a common "group-level" definition of security policy and enforcement of that policy. The distribution of cryptographic keys is a mechanism utilizing the group-level policy enforcements.1.1. GSAKMP Overview
Protecting group information requires the definition of a security policy and the enforcement of that policy by all participating parties. Controlling dissemination of cryptographic key is the primary mechanism to enforce the access control policy. It is the primary purpose of GSAKMP to generate and disseminate a group key in a secure fashion. GSAKMP separates group security management functions and responsibilities into three major roles:1) Group Owner, 2) Group Controller Key Server, and 3) Group Member. The Group Owner is responsible for creating the security policy rules for a group and expressing these in the policy token. The Group Controller Key Server (GC/KS) is responsible for creating and maintaining the keys and enforcing the group policy by granting access to potential Group Members (GMs) in accordance with the policy token. To enforce a group's policy, the potential Group Members need to have knowledge of the access control policy for the group, an unambiguous identification of any party downloading keys to them, and verifiable chains of authority for key download. In other words, the Group Members need to know who potentially will be in the group and to verify that the key disseminator is authorized to act in that capacity. In order to establish a Group Secure Association (GSA) to support these activities, the identity of each party in the process MUST be unambiguously asserted and authenticated. It MUST also be verified that each party is authorized, as defined by the policy token, to function in his role in the protocol (e.g., GM or GC/KS).
The security features of the establishment protocol for the GSA include - Group policy identification - Group policy dissemination - GM to GC/KS SA establishment to protect data - Access control checking GSAKMP provides mechanisms for cryptographic group creation and management. Other protocols may be used in conjunction with GSAKMP to allow various applications to create functional groups according to their application-specific requirements. For example, in a small-scale video conference, the organizer might use a session invitation protocol like SIP [RFC3261] to transmit information about the time of the conference, the address of the session, and the formats to be used. For a large-scale video transmission, the organizer might use a multicast announcement protocol like SAP [RFC2974]. This document describes a useful default set of security algorithms and configurations, Security Suite 1. This suite allows an entire set of algorithms and settings to be described to prospective group members in a concise manner. Other security suites MAY be defined as needed and MAY be disseminated during the out-of-band announcement of a group. Distributed architectures support large-scale cryptographic groups. Secure distributed architectures require authorized delegation of GSA actions to network resources. The fully specified policy token is the mechanism to facilitate this authorization. Transmission of this policy token to all joining GMs allows GSAKMP to securely support distributed architectures and multiple data sources. Many-to-many group communications require multiple data sources. Multiple data sources are supported because the inclusion of a policy token and policy payloads allow group members to review the group access control and authorization parameters. This member review process gives each member (each potential source of data) the ability to determine if the group provides adequate protection for member data.
1.2. Document Organization
The remainder of this document is organized as follows:Section 2 presents the terminology and concepts used to present the requirements of this protocol. Section 3 outlines the security considerations with respect to GSAKMP. Section 4 defines the architecture of GSAKMP. Section 5 describes the group management life cycle. Section 6 describes the Security Suite Definition. Section 7 presents the message types and formats used during each phase of the life cycle. Section 8 defines the state diagram for the protocol.2. Terminology
The following terminology is used throughout this document. Requirements Terminology: Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119]. Certificate: A data structure used to verifiably bind an identity to a cryptographic key (e.g., X.509v3). Compromise Recovery: The act of recovering a secure operating state after detecting that a group member cannot be trusted. This can be accomplished by rekey. Cryptographic Group: A set of entities sharing or desiring to share a GSA. Group Controller Key Server (GC/KS): A group member with authority to perform critical protocol actions including creating and distributing keys and building and maintaining the rekey structures. As the group evolves, it MAY become desirable to have multiple controllers perform these functions. Group Member (GM): A Group Member is any entity with access to the group keys. Regardless of how a member becomes a part of the group or how the group is structured, GMs will perform the following actions: - Authenticate and validate the identities and the authorizations of entities performing security-relevant actions - Accept group keys from the GC/KS - Request group keys from the GC/KS
- Enforce the cooperative group policies as stated in the group
policy token
- Perform peer review of key management actions
- Manage local key
Group Owner (GO): A Group Owner is the entity authorized for
generating and modifying an authenticatable policy token for the
group, and notifying the GC/KS to start the group.
Group Policy: The Group Policy completely describes the protection
mechanisms and security-relevant behaviors of the group. This
policy MUST be commonly understood and enforced by the group for
coherent secure operations.
Group Secure Association (GSA): A GSA is a logical association of
users or hosts that share cryptographic key(s). This group may be
established to support associations between applications or
communication protocols.
Group Traffic Protection Key (GTPK): The key or keys created for
protecting the group data.
Key Datum: A single key and its associated attributes for its usage.
Key Encryption Key (KEK): Key used in an encryption mechanism for
wrapping another key.
Key Handle: The identifier of a particular instance or version of a
key.
Key ID: The identifier for a key that MUST stay static throughout the
life cycle of this key.
Key Package: Type/Length/Data format containing a Key Datum.
Logical Key Hierarchy (LKH) Array: The group of keys created to
facilitate the LKH compromise recovery methodology.
Policy Token (PT): The policy token is a data structure used to
disseminate group policy and the mechanisms to enforce it. The
policy token is issued and signed by an authorized Group Owner.
Each member of the group MUST verify the token, meet the group
join policy, and enforce the policy of the group (e.g., encrypt
application data with a specific algorithm). The group policy
token will contain a variety of information including:
- GSAKMP protocol version
- Key creation method
- Key dissemination policy
- Access control policy
- Group authorization policy
- Compromise recovery policy
- Data protection mechanisms
Rekey: The act of changing keys within a group as defined by policy.
Rekey Array: The construct that contains all the rekey information
for a particular member.
Rekey Key: The KEK used to encrypt keys for a subset of the group.
Subordinate Group Controller Key Server (S-GC/KS): Any group member
having the appropriate processing and trust characteristics, as
defined in the group policy, that has the potential to act as a
S-GC/KS. This will allow the group processing and communication
requirements to be distributed equitably throughout the network
(e.g., distribute group key). The optional use of GSAKMP with
Subordinate Group Controller Key Servers will be documented in a
separate paper.
Wrapping KeyID: The Key ID of the key used to wrap a Key Package.
Wrapping Key Handle: The key handle of the key used to wrap the Key
Package.
3. Security Considerations
In addition to the specification of GSAKMP itself, the security of an implemented GSAKMP system is affected by supporting factors. These are discussed here.3.1. Security Assumptions
The following assumptions are made as the basis for the security discussion: 1. GSAKMP assumes its supporting platform can provide the process and data separation services at the appropriate assurance level to support its groups. 2. The key generation function of the cryptographic engine will only generate strong keys. 3. The security of this protocol is critically dependent on the randomness of the randomly chosen parameters. These should be generated by a strong random or properly seeded pseudo-random source [RFC4086]. 4. The security of a group can be affected by the accuracy of the system clock. Therefore, GSAKMP assumes that the system clock is close to correct time. If a GSAKMP host relies on a network time service to set its local clock, then that protocol must be secure against attackers. The maximum allowable clock skew across the group membership is policy configurable, with a default of 5 minutes. 5. As described in the message processing section, the use of the nonce value used for freshness along with a signature is the mechanism used to foil replay attacks. In any use of nonces, a core requirement is unpredictability of the nonce, from an attacker's viewpoint. The utility of the nonce relies on the inability of an attacker either to reuse old nonces or to predict the nonce value. 6. GSAKMP does not provide identity protection. 7. The group's multicast routing infrastructure is not secured by GSAKMP, and therefore it may be possible to create a multicast flooding denial of service attack using the multicast application's data stream. Either an insider (i.e., a rogue GM) or a non-member could direct the multicast routers to spray data at a victim system.
8. The compromise of a S-GC/KS forces the re-registration of all GMs
under its control. The GM recognizes this situation by finding
the S-GC/KS's certificate on a CRL as supplied by a service such
as LDAP.
9. The compromise of the GO forces termination of the group. The GM
recognizes this situation by finding the GO's certificate on a
Certificate Revocation List (CRL) as supplied by a service such
as LDAP.
3.2. Related Protocols
GSAKMP derives from two (2) existing protocols: ISAKMP [RFC2408] and
FIPS Pub 196 [FIPS196]. In accordance with Security Suite 1, GSAKMP
implementations MUST support the use of Diffie-Hellman key exchange
[DH77] for two-party key creation and MAY use Logical Key Hierarchy
(LKH) [RFC2627] for rekey capability. The GSAKMP design was also
influenced by the following protocols: [HHMCD01], [RFC2093],
[RFC2094], [BMS], and [RFC2412].
3.2.1. ISAKMP
ISAKMP provides a flexible structure of chained payloads in support
of authenticated key exchange and security association management for
pairwise communications. GSAKMP builds upon these features to
provide policy enforcement features in support of diverse group
communications.
3.2.2. FIPS Pub 196
FIPS Pub 196 provides a mutual authentication protocol.
3.2.3. LKH
When group policy dictates that a recovery of the group security is
necessary after the discovery of the compromise of a GM, then GSAKMP
relies upon a rekey capability (i.e., LKH) to enable group recovery
after a compromise [RFC2627]. This is optional since in many
instances it may be better to destroy the compromised group and
rebuild a secure group.
3.2.4. Diffie-Hellman
A Group may rely upon two-party key creation mechanisms, i.e., Diffie-Hellman, to protect sensitive data during download. The information in this section borrows heavily from [IKEv2], as this protocol has already worked through similar issues and GSAKMP is using the same security considerations for its purposes. This section will contain paraphrased sections of [IKEv2] modified for GSAKMP as appropriate. The strength of a key derived from a Diffie-Hellman exchange using specific p and g values depends on the inherent strength of the values, the size of the exponent used, and the entropy provided by the random number generator used. A strong random number generator combined with the recommendations from [RFC3526] on Diffie-Hellman exponent size is recommended as sufficient. An implementation should make note of this conservative estimate when establishing policy and negotiating security parameters. Note that these limitations are on the Diffie-Hellman values themselves. There is nothing in GSAKMP that prohibits using stronger values, nor is there anything that will dilute the strength obtained from stronger values. In fact, the extensible framework of GSAKMP encourages the definition of more Security Suites. It is assumed that the Diffie-Hellman exponents in this exchange are erased from memory after use. In particular, these exponents MUST NOT be derived from long-lived secrets such as the seed to a pseudo- random generator that is not erased after use.3.3. Denial of Service (DoS) Attack
This GSAKMP specification addresses the mitigation for a distributed IP spoofing attack (a subset of possible DoS attacks) in Section 5.2.2, "Cookies: Group Establishment with Denial of Service Protection".3.4. Rekey Availability
In addition to GSAKMP's capability to do rekey operations, GSAKMP MUST also have the capability to make this rekey information highly available to GMs. The necessity of GMs receiving rekey messages requires the use of methods to increase the likelihood of receipt of rekey messages. These methods MAY include multiple transmissions of the rekey message, posting of the rekey message on a bulletin board, etc. Compliant GSAKMP implementations supporting the optional rekey capability MUST support retransmission of rekey messages.
3.5. Proof of Trust Hierarchy
As defined by [HCM], security group policy MUST be defined in a verifiable manner. GSAKMP anchors its trust in the creator of the group, the GO. The policy token explicitly defines all the parameters that create a secure verifiable infrastructure. The GSAKMP Policy Token is issued and signed by the GO. The GC/KS will verify it and grant access to GMs only if they meet the rules of the policy token. The new GMs will accept access only if 1) the token verifies, 2) the GC/KS is an authorized disseminator, and 3) the group mechanisms are acceptable for protecting the GMs data.
(page 15 continued on part 2)