Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4535

GSAKMP: Group Secure Association Key Management Protocol

Pages: 106
Proposed Standard
Part 1 of 4 – Pages 1 to 15
None   None   Next

Top   ToC   RFC4535 - Page 1
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.
Top   ToC   RFC4535 - Page 2

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
Top   ToC   RFC4535 - Page 3
      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
Top   ToC   RFC4535 - Page 4
           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
Top   ToC   RFC4535 - Page 5

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
Top   ToC   RFC4535 - Page 6

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
Top   ToC   RFC4535 - Page 7

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).
Top   ToC   RFC4535 - Page 8
   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.
Top   ToC   RFC4535 - Page 9

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
Top   ToC   RFC4535 - Page 10
      -  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:
Top   ToC   RFC4535 - Page 11
         -  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.
Top   ToC   RFC4535 - Page 12

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.
Top   ToC   RFC4535 - Page 13
   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.
Top   ToC   RFC4535 - Page 14

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.
Top   ToC   RFC4535 - Page 15

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)

Next Section