tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 4535

Proposed STD
Pages: 106
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: MSEC

GSAKMP: Group Secure Association Key Management Protocol

Part 1 of 4, p. 1 to 15
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part