summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4535.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4535.txt')
-rw-r--r--doc/rfc/rfc4535.txt5939
1 files changed, 5939 insertions, 0 deletions
diff --git a/doc/rfc/rfc4535.txt b/doc/rfc/rfc4535.txt
new file mode 100644
index 0000000..a16b3d9
--- /dev/null
+++ b/doc/rfc/rfc4535.txt
@@ -0,0 +1,5939 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 1]
+
+RFC 4535 GSAKMP June 2006
+
+
+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
+
+
+
+Harney, et al. Standards Track [Page 2]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 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
+
+
+
+Harney, et al. Standards Track [Page 3]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 4]
+
+RFC 4535 GSAKMP June 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 5]
+
+RFC 4535 GSAKMP June 2006
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 6]
+
+RFC 4535 GSAKMP June 2006
+
+
+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).
+
+
+
+
+
+Harney, et al. Standards Track [Page 7]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 8]
+
+RFC 4535 GSAKMP June 2006
+
+
+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
+
+
+
+
+Harney, et al. Standards Track [Page 9]
+
+RFC 4535 GSAKMP June 2006
+
+
+ - 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:
+
+
+
+
+Harney, et al. Standards Track [Page 10]
+
+RFC 4535 GSAKMP June 2006
+
+
+ - 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 11]
+
+RFC 4535 GSAKMP June 2006
+
+
+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.
+
+
+
+
+Harney, et al. Standards Track [Page 12]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 13]
+
+RFC 4535 GSAKMP June 2006
+
+
+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.
+
+
+
+Harney, et al. Standards Track [Page 14]
+
+RFC 4535 GSAKMP June 2006
+
+
+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.
+
+4. Architecture
+
+ This architecture presents a trust model for GSAKMP and a concept of
+ operations for establishing a trusted distributed infrastructure for
+ group key and policy distribution.
+
+ GSAKMP conforms to the IETF MSEC architectural concepts as specified
+ in the MSEC Architecture document [RFC3740]. GSAKMP uses the MSEC
+ components to create a trust model for operations that implement the
+ security principles of mutual suspicion and trusted policy creation
+ authorities.
+
+4.1. Trust Model
+
+4.1.1. Components
+
+ The trust model contains four key components:
+
+ - Group Owner (GO),
+
+ - Group Controller Key Server (GC/KS),
+
+ - Subordinate GC/KS (S-GC/KS), and
+
+ - Group Member (GM).
+
+ The goal of the GSAKMP trust model is to derive trust from a common
+ trusted policy creation authority for a group. All security-relevant
+ decisions and actions implemented by GSAKMP are based on information
+ that ultimately is traceable to and verified by the trusted policy
+ creation authority. There are two trusted policy creation
+ authorities for GSAKMP: the GO (policy creation authority) and the
+ PKI root that allows us to verify the GO.
+
+
+
+
+Harney, et al. Standards Track [Page 15]
+
+RFC 4535 GSAKMP June 2006
+
+
+4.1.2. GO
+
+ The GO is the policy creation authority for the group. The GO has a
+ well-defined identity that is relevant to the group. That identity
+ can be of a person or of a group-trusted component. All potential
+ entities in the group have to recognize the GO as the individual with
+ authority to specify policy for the group.
+
+ The policy reflects the protection requirements of the data in a
+ group. Ultimately, the data and the application environment drives
+ the security policy for the group.
+
+ The GO has to determine the security rules and mechanisms that are
+ appropriate for the data being protected by the group keys. All this
+ information is captured in a policy token (PT). The GO creates the
+ PT and signs it.
+
+4.1.3. GC/KS
+
+ The GC/KS is authorized to perform several functions: key creation,
+ key distribution, rekey, and group membership management.
+
+ As the key creation authority, the GC/KS will create the set of keys
+ for the group. These keys include the Group Traffic Protection Keys
+ (GTPKs) and first-tier rekey keys. There may be second-tier rekey
+ trees if a distributed rekey management structure is required for the
+ group.
+
+ As the key distribution (registration) authority, it has to notify
+ the group of its location for registration services. The GC/KS will
+ have to enforce key access control as part of the key distribution
+ and registration processes.
+
+ As the group rekey authority, it performs rekey in order to change
+ the group's GTPK. Change of the GTPK limits the exposure of data
+ encrypted with any single GTPK.
+
+ Finally, as the group membership management authority, the GC/KS can
+ manage the group membership (registration, eviction, de-registration,
+ etc.). This may be done in part by using a key tree approach, such
+ as Logical Key Hierarchies (LKH), as an optional approach.
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 16]
+
+RFC 4535 GSAKMP June 2006
+
+
+4.1.4. Subordinate GC/KS
+
+ A subordinate GC/KS is used to distribute the GC/KS functionality
+ across multiple entities. The S-GC/KS will have all the authorities
+ of the GC/KS except one: it will not create the GTPK. It is assumed
+ here that the group will transmit data with a single GTPK at any one
+ time. This GTPK comes from the GC/KS.
+
+ Note that relative to the GC/KS, the S-GC/KS is responsible for an
+ additional security check: the S-GC/KS must register as a member with
+ the GC/KS, and during that process it has to verify the authority of
+ the GC/KS.
+
+4.1.5. GM
+
+ The GM has two jobs: to make sure all security-relevant actions are
+ authorized and to use the group keys properly. During the
+ registration process, the GM will verify that the PT is signed by a
+ recognized GO. In addition, it will verify that the GC/KS or S-GC/KS
+ engaged in the registration process is authorized, as specified in
+ the PT. If rekey and new PTs are distributed to the group, the GM
+ will verify that they are proper and all actions are authorized.
+
+ The GM is granted access to group data through receipt of the group
+ keys This carries along with it a responsibility to protect the key
+ from unauthorized disclosure.
+
+ GSAKMP does not offer any enforcement mechanisms to control which GMs
+ are multicast speakers at a given moment. This policy and its
+ enforcement depend on the multicast application and its protocols.
+ However, GSAKMP does allow a group to have one of three Group
+ Security Association multicast speaker configurations:
+
+ - There is a single GM authorized to be the group's speaker. There
+ is one multicast application SA allocated by the GO in support of
+ that speaker. The PT initializes this multicast application SA
+ and identifies the GM that has been authorized to be speaker. All
+ GMs share a single TPK with that GM speaker. Sequence number
+ checking for anti-replay protection is feasible and enabled by
+ default. This is the default group configuration. GSAKMP
+ implementations MUST support this configuration.
+
+ - The GO authorizes all of the GMs to be group speakers. The GO
+ allocates one multicast application SA in support of these
+ speakers. The PT initializes this multicast application SA and
+ indicates that any GM can be a speaker. All of the GMs share a
+ single GTPK and other SA state information. Consequently, some SA
+ security features such as sequence number checking for anti-replay
+
+
+
+Harney, et al. Standards Track [Page 17]
+
+RFC 4535 GSAKMP June 2006
+
+
+ protection cannot be supported by this configuration. GSAKMP
+ implementations MUST support this group configuration.
+
+ - The GO authorizes a subset of the GMs to be group speakers (which
+ may be the subset composed of all GMs). The GO allocates a
+ distinct multicast application SA for each of these speakers. The
+ PT identifies the authorized speakers and initializes each of
+ their multicast application Security Associations. The speakers
+ still share a common TPK across their SA, but each speaker has a
+ separate SA state information instance at every peer GM.
+ Consequently, this configuration supports SA security features,
+ such as sequence number checking for anti-replay protection, or
+ source authentication mechanisms that require per-speaker state at
+ the receiver. The drawback of this configuration is that it does
+ not scale to a large number of speakers. GSAKMP implementations
+ MAY support this group configuration.
+
+4.1.6. Assumptions
+
+ The assumptions for this trust model are that:
+
+ - the GCKS is never compromised,
+
+ - the GO is never compromised,
+
+ - the PKI, subject to certificate validation, is trustworthy,
+
+ - The GO is capable of creating a security policy to meet the
+ demands of the group,
+
+ - the compromises of a group member will be detectable and reported
+ to the GO in a trusted manner,
+
+ - the subsequent recovery from a compromise will deny inappropriate
+ access to protected data to the compromised member,
+
+ - no security-relevant actions depend on a precise network time,
+
+ - there are confidentiality, integrity, multicast source
+ authentication, and anti-replay protection mechanisms for all
+ GSAKMP control messages.
+
+4.2. Rule-Based Security Policy
+
+ The trust model for GSAKMP revolves around the definition and
+ enforcement of the security policy. In fact, the use of the key is
+ only relevant, in a security sense, if it represents the successful
+ enforcement of the group security policy.
+
+
+
+Harney, et al. Standards Track [Page 18]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Group operations lend themselves to rule-based security policy. The
+ need for distribution of data to many endpoints often leads to the
+ defining of those authorized endpoints based on rules. For example,
+ all IETF attendees at a given conference could be defined as a single
+ group.
+
+ If the security policy rules are to be relevant, they must be coupled
+ with validation mechanisms. The core principle here is that the
+ level of trust one can afford a security policy is exactly equal to
+ the level of trust one has in the validation mechanism used to prove
+ that policy. For example, if all IETF attendees are allowed in, then
+ they could register their identity from their certificate upon
+ check-in to the meetings. That certificate is issued by a trusted
+ policy creation authority (PKI root) that is authorized to identify
+ someone as an IETF attendee. The GO could make admittance rules to
+ the IETF group based on the identity certificates issued from trusted
+ PKIs.
+
+ In GSAKMP, every security policy rule is coupled with an explicit
+ validation mechanism. For interoperability considerations, GSAKMP
+ requires that its supporting PKI implementations MUST be compliant to
+ RFC 3280.
+
+ If a GM's public key certificate is revoked, then the entity that
+ issues that revocation SHOULD signal the GO, so that the GO can expel
+ that GM. The method that signals this event to the GO is not
+ standardized by this specification.
+
+ A direct mapping of rule to validation mechanism allows the use of
+ multiple rules and PKIs to create groups. This allows a GO to define
+ a group security policy that spans multiple PKI domains, each with
+ its own Certificate Authority public key certificate.
+
+4.2.1. Access Control
+
+ The access control policy for the group keys is equivalent to the
+ access control policy for the multicast application data the keys are
+ protecting.
+
+ In a group, each data source is responsible for ensuring that the
+ access to the source's data is appropriate. This implies that every
+ data source should have knowledge of the access control policy for
+ the group keys.
+
+ In the general case, GSAKMP offers a suite of security services to
+ its applications and does not prescribe how they use those services.
+
+
+
+
+
+Harney, et al. Standards Track [Page 19]
+
+RFC 4535 GSAKMP June 2006
+
+
+ GSAKMP supports the creation of GSAs with multiple data sources. It
+ also supports architectures where the GC/KS is not itself a data
+ source. In the multiple data source architectures GSAKMP requires
+ that the access control policy is precisely defined and distributed
+ to each data source. The reference for this data structure is the
+ GSAKMP Policy Token [RFC4534].
+
+4.2.2. Authorizations for Security-Relevant Actions
+
+ A critical aspect of the GSAKMP trust model is the authorization of
+ security-relevant actions. These include download of group key,
+ rekey, and PT creation and updates. These actions could be used to
+ disrupt the secure group, and all entities in the group must verify
+ that they were instigated by authorized entities within the group.
+
+4.3. Distributed Operation
+
+ Scalability is a core feature of GSAKMP. GSAKMP's approach to
+ scalable operations is the establishment of S-GC/KSes. This allows
+ the GSAKMP systems to distribute the workload of setting up and
+ managing very large groups.
+
+ Another aspect of distributed S-GC/KS operations is the enabling of
+ local management authorities. In very large groups, subordinate
+ enclaves may be best suited to provide local management of the
+ enclaves' group membership, due to a direct knowledge of the group
+ members.
+
+ One of the critical issues involved with distributed operation is the
+ discovery of the security infrastructure location and security suite.
+ Many group applications that have dynamic interactions must "find"
+ each other to operate. The discovery of the security infrastructure
+ is just another piece of information that has to be known by the
+ group in order to operate securely.
+
+ There are several methods for infrastructure discovery:
+
+ - Announcements
+
+ - Anycast
+
+ - Rendezvous points / Registration
+
+ One method for distributing the security infrastructure location is
+ to use announcements. The SAP is commonly used to announce the
+ existence of a new multicast application or service. If an
+
+
+
+
+
+Harney, et al. Standards Track [Page 20]
+
+RFC 4535 GSAKMP June 2006
+
+
+ application uses SAP [RFC2974] to announce the existence of a service
+ on a multicast channel, that service could be extended to include the
+ security infrastructure location for a particular group.
+
+ Announcements can also be used by GSAKMP in one of two modes:
+ expanding ring searches (ERSes) of security infrastructure and ERSes
+ for infrastructure discovery. In either case, the GSAKMP would use a
+ multicast broadcast that would slowly increase in its range by
+ incremental multicast hops. The multicast source controls the
+ packet's multicast range by explicitly setting its Time To Live
+ count.
+
+ An expanding ring announcement operates by the GC/KS announcing its
+ existence for a particular group. The number of hops this
+ announcement would travel would be a locally configured number. The
+ GMs would listen on a well-known multicast address for GC/KSes that
+ provide service for groups of interest. If multiple GC/KSes are
+ found that provide service, then the GM would pick the closest one
+ (in terms of multicast hops). The GM would then send a GSAKMP
+ Request to Join message (RTJ) to the announced GC/KS. If the
+ announcement is found to be spurious, then that is reported to the
+ appropriate management authorities. The ERA concept is slightly
+ different from SAP in that it could occur over the data channel
+ multicast address, instead of a special multicast address dedicated
+ for the SAP service.
+
+ An expanding ring search operates in the reverse order of the ERA.
+ In this case, the GM is the announcing entity. The (S-)GC/KSes
+ listen for the requests for service, specifically the RTJ. The
+ (S-)GC/KS responds to the RTJ. If the GM receives more than one
+ response, it would either ignore the responses or send NACKs based on
+ local configuration.
+
+ Anycast is a service that is very similar to ERS. It also can be
+ used to provide connection to the security infrastructure. In this
+ case, the GM would send the RTJ to a well-known service request
+ address. This anycast service would route the RTJ to an appropriate
+ GC/KS. The anycast service would have security infrastructure and
+ network connectivity knowledge to facilitate this connection.
+
+ Registration points can be used to distribute many group-relevant
+ data, including security infrastructure. Many group applications
+ rely on well-known registration points to advertise the availability
+ of groups. There is no reason that GSAKMP could not use the same
+ approach for advertising the existence and location of the security
+ infrastructure. This is a simple process if the application being
+ supported already supports registration. The GSAKMP infrastructure
+ can always provide a registration site if the existence of this
+
+
+
+Harney, et al. Standards Track [Page 21]
+
+RFC 4535 GSAKMP June 2006
+
+
+ security infrastructure discovery hub is needed. The registration of
+ S-GC/KSes at this site could be an efficient way to allow GM
+ registration.
+
+ GSAKMP infrastructure discovery can use whatever mechanism suits a
+ particular multicast application's requirements, including mechanisms
+ that have not been discussed by this architecture. However, GSAKMP
+ infrastructure discovery is not standardized by this version of the
+ GSAKMP specification.
+
+4.4. Concept of Operation
+
+ This concept of operation shows how the different roles in GSAKMP
+ interact to set up a secure group. This particular concept of
+ operation focuses on a secure group that utilizes the distributed key
+ dissemination services of the S-GC/KS.
+
+4.4.1. Assumptions
+
+ The most basic assumption here is that there is one or more
+ trustworthy PKIs for the group. That trusted PKI will be used to
+ create and verify security policy rules.
+
+ There is a GO that all GMs recognize as having group policy creation
+ authority. All GM must be securely pre-configured to know the GO
+ public key.
+
+ All GMs have access to the GO PKI information, both the trusted
+ anchor public keys and the certificate path validation rules.
+
+ There is sufficient connectivity between the GSAKMP entities.
+
+ - The registration SA requires that GM can connect to the GC/KS or
+ S-GC/KS using either TCP or UDP.
+
+ - The Rekey SA requires that the data-layer multicast communication
+ service be available. This can be multicast IP, overlay networks
+ using TCP, or NAT tunnels.
+
+ - GSAKMP can support many different data-layer secure applications,
+ each with unique connectivity requirements.
+
+4.4.2. Creation of a Policy Token
+
+ The GO creates and signs the policy token for a group. The policy
+ token contains the rules for access control and authorizations for a
+ particular group.
+
+
+
+
+Harney, et al. Standards Track [Page 22]
+
+RFC 4535 GSAKMP June 2006
+
+
+ The PT consists of the following information:
+
+ - Identification: This allows an unambiguous identification of the
+ PT and the group.
+
+ - Access Control Rules: These rules specify who can have access to
+ the group keys.
+
+ - Authorization Rules: These rules specify who can be a S-GC/KS.
+
+ - Mechanisms: These rules specify the security mechanisms that will
+ be used by the group. This is necessary to ensure there is no
+ weak link in the group security profile. For example, for IPsec,
+ this could include SPD/SAD configuration data.
+
+ - Source authentication of the PT to the GO: The PT is a CMS signed
+ object, and this allows all GMs to verify the PT.
+
+4.4.3. Creation of a Group
+
+ The PT is sent to a potential GC/KS. This can occur in several ways,
+ and the method of transmittal is outside the scope of GSAKMP. The
+ potential GC/KS will verify the GO signature on the PT to ensure that
+ it comes from a trusted GO. Next, the GC/KS will verify that it is
+ authorized to become the GC/KS, based on the authorization rules in
+ the PT. Assuming that the GC/KS trusts the PT, is authorized to be a
+ GC/KS, and is locally configured to become a GC/KS for a given group
+ and the GO, then the GC/KS will create the keys necessary to start
+ the group. The GC/KS will take whatever action is necessary (if any)
+ to advertise its ability to distribute key for the group. The GC/KS
+ will then listen for RTJs.
+
+ The PT has a sequence number. Every time a PT is distributed to the
+ group, the group members verify that the sequence number on the PT is
+ increasing. The PT lifetime is not limited to a particular time
+ interval, other than by the lifetimes imposed by some of its
+ attributes (e.g., signature key lifetime). The current PT sequence
+ number is downloaded to the GM in the "Key Download" message. Also,
+ to avoid replay attacks, this sequence number is never reset to a
+ lower value (i.e., rollover to zero) as long as the group identifier
+ remains valid and in use. The GO MUST preserve this sequence number
+ across re-boots.
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 23]
+
+RFC 4535 GSAKMP June 2006
+
+
+4.4.4. Discovery of GC/KS
+
+ Potential GMs will receive notice of the new group via some
+ mechanism: announcement, Anycast, or registration look-up. The GM
+ will send an RTJ to the GC/KS.
+
+4.4.5. GC/KS Registration Policy Enforcement
+
+ The GC/KS may or may not require cookies, depending on the DoS
+ environment and the local configuration.
+
+ Once the RTJ has been received, the GC/KS will verify that the GM is
+ allowed to have access to the group keys. The GC/KS will then verify
+ the signature on the RTJ to ensure it was sent by the claimed
+ identity. If the checks succeed, the GC/KS will ready a Key Download
+ message for the GM. If not, the GC/KS can notify the GM of a non-
+ security-relevant problem.
+
+4.4.6. GM Registration Policy Enforcement
+
+ Upon receipt of the Key Download message, the GM will verify the
+ signature on the message. Then the GM will retrieve the PT from the
+ Key Download message and verify that the GO created and signed the
+ PT. Once the PT is verified as valid, the GM will verify that the
+ GC/KS is authorized to distribute key for this group. Then the GM
+ will verify that the mechanisms used in the group are available and
+ acceptable for protection of the GMs data (assuming the GM is a data
+ source). The GM will then accept membership in this group.
+
+ The GM will then check to see if it is allowed to be a S-GC/KS for
+ this group. If the GM is allowed to be a S-GC/KS AND the local GM
+ configuration allows the GM to act as a S-GC/KS for this group, then
+ the GM changes its operating state to S-GC/KS. The GO needs to
+ assign the authority to become a S-GC/KS in a manner that supports
+ the overall group integrity and operations.
+
+4.4.7. Autonomous Distributed GSAKMP Operations
+
+ In autonomous mode, each S-GC/KS operates a largely self-contained
+ sub-group for which the Primary-GC/KS delegates the sub-group's
+ membership management responsibility to the S-GC/KS. In general, the
+ S-GC/KS locally handles each Group Member's registration and
+ de-registration without any interaction with the Primary-GC/KS.
+ Periodically, the Primary-GC/KS multicasts a Rekey Event message
+ addressed only to its one or more S-GC/KS.
+
+ After a S-GC/KS successfully processes a Rekey Event message from the
+ Primary-GC/KS, the S-GC/KS transmits to its sub-group its own Rekey
+
+
+
+Harney, et al. Standards Track [Page 24]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Event message containing a copy of the group's new GTPK and policy
+ token. The S-GC/KS encrypts its Rekey Event message's sub-group key
+ management information using Logical Key Hierarchy or a comparable
+ rekey protocol. The S-GC/KS uses the rekey protocol to realize
+ forward and backward secrecy, such that only the authorized sub-group
+ members can decrypt and acquire access to the new GTPK and policy
+ token. The frequency at which the Primary-GC/KS transmits a Rekey
+ Event message is a policy token parameter.
+
+ For the special case of a S-GC/KS detecting an expelled or
+ compromised group member, a mechanism is defined to trigger an
+ immediate group rekey rather than wait for the group's rekey period
+ to elapse. See below for details.
+
+ Each S-GC/KS will be registered by the GC/KS as a management node
+ with responsibility for GTPK distribution, access control policy
+ enforcement, LKH tree creation, and distribution of LKH key arrays.
+ The S-GC/KS will be registered into the primary LKH tree as an
+ endpoint. Each S-GC/KS will hold an entire LKH key array for the
+ GC's LKH key tree.
+
+ For the purpose of clarity, the process of creating a distributed
+ GSAKMP group will be explained in chronological order.
+
+ First, the Group Owner will create a policy token that authorizes a
+ subset of the group's membership to assume the role of S-GC/KS.
+
+ The GO needs to ensure that the S-GC/KS rules in the policy token
+ will be stringent enough to ensure trust in the S-GC/KSes. This
+ policy token is handed off to the primary GC.
+
+ The GC will create the GTPK and initial LKH key tree. The GC will
+ then wait for a potential S-GC/KS to send a Request to Join (RTJ)
+ message.
+
+ A potential S-GC/KS will eventually send an RTJ. The GC will enforce
+ the access control policy as defined in the policy token. The
+ S-GC/KS will accept the role of S-GC/KS and create its own LKH key
+ tree for its sub-group membership.
+
+ The S-GC/KS will then offer registration services for the group.
+ There are local management decisions that are optional to control the
+ scope of group members that can be served by a S-GC/KS. These are
+ truly local management issues that allow the administrators of an
+ S-GC/KS to restrict service to potential GMs. These local controls
+ do not affect the overall group security policy, as defined in the
+ policy token.
+
+
+
+
+Harney, et al. Standards Track [Page 25]
+
+RFC 4535 GSAKMP June 2006
+
+
+ A potential Group Member will send an RTJ to the S-GC/KS. The
+ S-GC/KS will enforce the entire access control policy as defined in
+ the PT. The GM will receive an LKH key array that corresponds to the
+ LKH tree of the S-GC/KS. The key tree generated by the S-GC/KS is
+ independent of the key tree generated by the GC/KS; they share no
+ common keys.
+
+ The GM then has the keys it needs to receive group traffic and be
+ subject to rekey from the S-GC/KS. For the sake of this discussion,
+ let's assume the GM is to be expelled from the group membership.
+
+ The S-GC/KS will receive notification that the GM is to be expelled.
+ This mechanism is outside the scope of this protocol.
+
+ Upon notification that a GM that holds a key array within its LKH
+ tree is to be expelled, the S-GC/KS does two things. First, the
+ S-GC/KS initiates a de-registration exchange with the GC/KS
+ identifying the member to be expelled. (The S-GC/KS proxies a Group
+ Member's de-registration informing the GC/KS that the Group Member
+ has been expelled from the group.) Second, the S-GC/KS will wait for
+ a rekey action by the GC/KS. The immediacy of the rekey action by
+ the GC/KS is a management decision at the GC/KS. Security is best
+ served by quick expulsion of untrusted members.
+
+ Upon receipt of the de-registration notification from the S-GC/KS,
+ the GC/KS will register the member to be expelled. The GC/KS will
+ then follow group procedure for initiating a rekey action (outside
+ the scope of this protocol). The GC/KS will communicate to the GO
+ the expelled member's information (outside the scope of this
+ protocol). With this information, the GO will create a new PT for
+ the group with the expelled GM identity added to the excluded list in
+ the group's access control rules. The GO provides this new PT to the
+ GC/KS for distribution with the Rekey Event Message.
+
+ The GC/KS will send out a rekey operation with a new PT. The S-GC/KS
+ will receive the rekey and process it. At the same time, all other
+ S-GC/KSes will receive the rekey and note the excluded GM identity.
+ All S-GC/KSes will review local identities to ensure that the
+ excluded GM is not a local member. If it is, then the S-GC/KS will
+ create a rekey message. The S-GC/KSes must always create a rekey
+ message, whether or not the expelled Group Member is a member of
+ their subtrees.
+
+ The S-GC/KS will then create a local rekey message. The S-GC/KS will
+ send the wrapped Group TPK to all members of its local LKH tree,
+ except the excluded member(s).
+
+
+
+
+
+Harney, et al. Standards Track [Page 26]
+
+RFC 4535 GSAKMP June 2006
+
+
+5. Group Life Cycle
+
+ The management of a cryptographic group follows a life cycle: group
+ definition, group establishment, and security-relevant group
+ maintenance. Group definition involves defining the parameters
+ necessary to support a secure group, including its policy token.
+ Group establishment is the process of granting access to new members.
+ Security-relevant group maintenance messages include rekey, policy
+ changes, member deletions, and group destruction. Each of these life
+ cycle phases is discussed in the following sections.
+
+ The use and processing of the optional Vendor ID payload for all
+ messages can be found in Section 7.10.
+
+5.1. Group Definition
+
+ A cryptographic group is established to support secure communications
+ among a group of individuals. The activities necessary to create a
+ policy token in support of a cryptographic group include:
+
+ - Determine Access Policy: identify the entities that are authorized
+ to receive the group key.
+
+ - Determine Authorization Policy: identify which entities are
+ authorized to perform security-relevant actions, including key
+ dissemination, policy creation, and initiation of security-
+ management actions.
+
+ - Determine Mechanisms: define the algorithms and protocols used by
+ GSAKMP to secure the group.
+
+ - Create Group Policy Token: format the policies and mechanisms into
+ a policy token, and apply the GO signature.
+
+5.2. Group Establishment
+
+ GSAKMP Group Establishment consists of three mandatory-to-implement
+ messages: the Request to Join, the Key Download, and the Key Download
+ Ack/Failure. The exchange may also include two OPTIONAL error
+ messages: the Request to Join Error and the Lack_of_Ack messages.
+ Operation using the mandatory messages only is referred to as "Terse
+ Mode", while inclusion of the error messaging is referred to as
+ "Verbose Mode". GSAKMP implementations MUST support Terse Mode and
+ MAY support Verbose Mode. Group Establishment is discussed in
+ Section 5.2.1.
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 27]
+
+RFC 4535 GSAKMP June 2006
+
+
+ A group is set in Terse or Verbose Mode by a policy token parameter.
+ All (S-)GC/KSes in a Verbose Mode group MUST support Verbose Mode.
+ GSAKMP allows Verbose Mode groups to have GMs that do not support
+ Verbose Mode. Candidate GMs that do not support Verbose Mode and
+ receive a RTJ-Error or Lack-of-Ack message must handle these messages
+ gracefully. Additionally, a GM will not know ahead of time that it
+ is interacting with the (S-)GC/KS in Verbose or Terse Mode until the
+ policy token is received.
+
+ For denial of service protection, a Cookie Exchange MAY precede the
+ Group Establishment exchange. The Cookie Exchange is described in
+ Section 5.2.2.
+
+ Regardless of mode, any error message sent between component members
+ indicates the first error encountered while processing the message.
+
+5.2.1. Standard Group Establishment
+
+ After the out-of-band receipt of a policy token, a potential Group
+ Controller Key Server (GC/KS) verifies the token and its eligibility
+ to perform GC/KS functionality. It is then permitted to create any
+ needed group keys and begin to establish the group.
+
+ The GSAKMP Ladder Diagram, Figure 1, illustrates the process of
+ establishing a cryptographic group. The left side of the diagram
+ represents the actions of the GC/KS. The right side of the diagram
+ represents the actions of the GMs. The components of each message
+ shown in the diagram are presented in Sections 5.2.1.1 through
+ 5.2.1.5.
+
+ CONTROLLER Mandatory/ MESSAGE MEMBER
+ Optional
+ !<-M----------Request to Join-------------!
+ <Process> ! !
+ <RTJ> ! !
+ !--M----------Key Download--------------->!
+ ! !<Process KeyDL>
+ !--O-------Request to Join Error--------->! or
+ ! ! <Proc RTJ-Err>
+ !<-M----Key Download - Ack/Failure--------!
+ <Process >! !
+ <KeyDL-A/F>! !
+ !--O------Lack of Acknowledgement-------->!
+ ! ! <Proc LOA>
+ !<=======SHARED KEYED GROUP SESSION======>!
+
+ Figure 1: GSAKMP Ladder Diagram
+
+
+
+
+Harney, et al. Standards Track [Page 28]
+
+RFC 4535 GSAKMP June 2006
+
+
+ The Request to Join message is sent from a potential GM to the GC/KS
+ to request admission to the cryptographic group. The message
+ contains key creation material, freshness data, an optional selection
+ of mechanisms, and the signature of the GM.
+
+ The Key Download message is sent from the GC/KS to the GM in response
+ to an accepted Request to Join. This GC/KS-signed message contains
+ the identifier of the GM, freshness data, key creation material,
+ encrypted keys, and the encrypted policy token. The policy token is
+ used to facilitate well-ordered group creation and MUST include the
+ group's identification, group permissions, group join policy, group
+ controller key server identity, group management information, and
+ digital signature of the GO. This will allow the GM to determine
+ whether group policy is compatible with local policy.
+
+ The Request to Join Error message is sent from the GC/KS to the GM in
+ response to an unaccepted Request to Join. This message is not
+ signed by the GC/KS for two reasons: 1) the GM, at this point, has no
+ knowledge of who is authorized to act as a GC/KS, and so the
+ signature would thus be meaningless to the GM, and 2) signing
+ responses to denied join requests would provide a denial of service
+ potential. The message contains an indication of the error
+ condition. The possible values for this error condition are:
+ Invalid-Payload-Type, Invalid-Version, Invalid-Group-ID, Invalid-
+ Sequence-ID, Payload-Malformed, Invalid-ID-Information, Invalid-
+ Certificate, Cert-Type-Unsupported, Invalid-Cert-Authority,
+ Authentication-Failed, Certificate-Unavailable, Unauthorized-Request,
+ Prohibited-by-Group-Policy, and Prohibited-by-Locally-Configured-
+ Policy.
+
+ The Key Download Ack/Failure message indicates Key Download receipt
+ status at the GM. It is a GM-signed message containing freshness
+ data and status.
+
+ The Lack_of_Ack message is sent from the GC/KS to the GM in response
+ to an invalid or absent Key Download Ack/Failure message. The signed
+ message contains freshness and status data and is used to warn the GM
+ of impending eviction from the group if a valid Key Download
+ Ack/Failure is not sent. Eviction means that the member will be
+ excluded from the group after the next Rekey Event. The policy of
+ when a particular group needs to rekey itself is stated in the policy
+ token. Eviction is discussed further in Section 5.3.2.1.
+
+ For the following message structure sections, details about payload
+ format and processing can be found in Section 7. Each message is
+ identified by its exchange type in the header of the message. Nonces
+ MUST be present in the messages unless synchronization time is
+ available to the system.
+
+
+
+Harney, et al. Standards Track [Page 29]
+
+RFC 4535 GSAKMP June 2006
+
+
+5.2.1.1. Request to Join
+
+ The exchange type for Request to Join is eight (8).
+
+ The components of a Request to Join Message are shown in Table 1.
+
+ Table 1: Request to Join (RTJ) Message Definition
+
+ Message Name : Request to Join (RTJ)
+ Dissection : {HDR-GrpID, Key Creation, Nonce_I, [VendorID],
+ : [Notif_Mechanism_Choices], [Notif_Cookie],
+ : [Notif_IPValue]} SigM, [Cert]
+ Payload Types : GSAKMP Header, Key Creation, [Nonce], [Vendor
+ ID], Signature, [Certificate], [Notifications]
+
+ SigM : Signature of Group Member
+ Cert : Necessary Certificates, zero or more
+ {}SigX : Indicates fields used in Signature
+ [] : Indicate an optional data item
+
+
+ As shown by Figure 1, a potential GM MUST generate and send an RTJ
+ message to request permission to join the group. At a minimum, the
+ GM MUST be able to manually configure the destination for the RTJ.
+ As defined in the dissection of the RTJ message, this message MUST
+ contain a Key Creation payload for KEK determination. A Nonce
+ payload MUST be included for freshness and the Nonce_I value MUST be
+ saved for potential later use. The GC/KS will use this supplied
+ nonce only if the policy token for this group defines the use of
+ nonces versus synchronization time. An OPTIONAL Notification payload
+ of type Mechanism Choices MAY be included to identify the mechanisms
+ the GM wants to use. Absence of this payload will cause the GC/KS to
+ select appropriate default policy-token-specified mechanisms for the
+ Key Download.
+
+ In response, the GC/KS accepts or denies the request based on local
+ configuration. <Process RTJ> indicates the GC/KS actions that will
+ determine if the RTJ will be acted upon. The following checks SHOULD
+ be performed in the order presented.
+
+ In this procedure, the GC/KS MUST verify that the message header is
+ properly formed and confirm that this message is for this group by
+ checking the value of the GroupID. If the header checks pass, then
+ the identity of the sender is extracted from the Signature payload.
+ This identity MUST be used to perform access control checks and find
+ the GMs credentials (e.g., certificate) for message verification. It
+ MUST also be used in the Key Download message. Then, the GC/KS will
+ verify the signature on the message to ensure its authenticity. The
+
+
+
+Harney, et al. Standards Track [Page 30]
+
+RFC 4535 GSAKMP June 2006
+
+
+ GC/KS MUST use verified and trusted authentication material from a
+ known root. If the message signature verifies, the GC/KS then
+ confirms that all required payloads are present and properly
+ formatted based upon the mechanisms announced and/or requested. If
+ all checks pass, the GC/KS will create and send the Key Download
+ message as described in Section 5.2.1.2.
+
+ If the GM receives no response to the RTJ within the GM's locally
+ configured timeout value, the GM SHOULD resend the RTJ message up to
+ three (3) times.
+
+ NOTE: At any one time, a GC/KS MUST process no more than one (1)
+ valid RTJ message from a given GM per group until its pending
+ registration protocol exchange concludes.
+
+ If any error occurs during RTJ message processing, and the GC/KS is
+ running in Terse Mode, the registration session MUST be terminated,
+ and all saved state information MUST be cleared.
+
+ The OPTIONAL Notification payload of type Cookie is discussed in
+ Section 5.2.2.
+
+ The OPTIONAL Notification payload of type IPValue may be used for the
+ GM to convey a specific IP value to the GC/KS.
+
+5.2.1.2. Key Download
+
+ The exchange type for Key Download is nine (9).
+
+ The components of a Key Download Message are shown in Table 2:
+
+ Table 2: Key Download (KeyDL) Message Definition
+
+ Message Name : Key Download (KeyDL)
+ Dissection : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C], Key
+ Creation, (Policy Token)*, (Key Download)*,
+ [VendorID]} SigC, [Cert]
+ Payload Types : GSAKMP Header, Identification, [Nonce], Key
+ Creation, Policy Token, Key Download, [Vendor
+ ID], Signature, [Certificate]
+
+ SigC : Signature of Group Controller Key Server
+ Cert : Necessary Certificates, zero or more
+ {}SigX : Indicates fields used in Signature
+ [] : Indicate an optional data item
+ (data)* : Indicates encrypted information
+
+
+
+
+
+Harney, et al. Standards Track [Page 31]
+
+RFC 4535 GSAKMP June 2006
+
+
+ In response to a properly formed and verified RTJ message, the GC/KS
+ creates and sends the KeyDL message. As defined in the dissection of
+ the message, this message MUST contain payloads to hold the following
+ information: GM identification, Key Creation material, encrypted
+ policy token, encrypted key information, and signature information.
+ If synchronized time is not available, the Nonce payloads MUST be
+ included in the message for freshness.
+
+ If present, the nonce values transmitted MUST be the GC/KS's
+ generated Nonce_R value and the combined Nonce_C value that was
+ generated by using the GC/KS's Nonce_R value and the Nonce_I value
+ received from the GM in the RTJ.
+
+ If two-party key determination is used, the key creation material
+ supplied by the GM and/or the GC/KS will be used to generate the key.
+ Generation of this key is dependent on the key exchange, as defined
+ in Section 7.11, "Key Creation Payload". The policy token and key
+ material are encrypted in the generated key.
+
+ The GM MUST be able to process the Key Download message. <Process
+ KeyDL> indicates the GM actions that will determine how the Key
+ Download message will be acted upon. The following checks SHOULD be
+ performed in the order presented.
+
+ In this procedure, the GM will verify that the message header is
+ properly formed and confirm that this message is for this group by
+ checking the value of the GroupID. If the header checks pass, the GM
+ MUST confirm that this message was intended for itself by comparing
+ the Member ID in the Identification payload to its identity.
+
+ After identification confirmation, the freshness values are checked.
+ If using nonces, the GM MUST use its saved Nonce_I value, extract the
+ received GC/KS Nonce_R value, compute the combined Nonce_C value, and
+ compare it to the received Nonce_C value. If not using nonces, the
+ GM MUST check the timestamp in the Signature payload to determine if
+ the message is new.
+
+ After freshness is confirmed, the signature MUST be verified to
+ ensure its authenticity. The GM MUST use verified and trusted
+ authentication material from a known root. If the message signature
+ verifies, the key creation material is extracted from the Key
+ Creation payload to generate the KEK. This KEK is then used to
+ decrypt the policy token data. The signature on the policy token
+ MUST be verified. Access control checks MUST be performed on both
+ the GO and the GC/KS to determine both their authorities within this
+ group. After all these checks pass, the KEK can then be used to
+
+
+
+
+
+Harney, et al. Standards Track [Page 32]
+
+RFC 4535 GSAKMP June 2006
+
+
+ decrypt and process the key material from the Key Download payload.
+ If all is successful, the GM will create and send the Key Download -
+ Ack/Failure message as described in Section 5.2.1.4.
+
+ The Policy Token and Key Download Payloads are sent encrypted in the
+ KEK generated by the Key Creation Payload information using the
+ mechanisms defined in the group announcement. This guarantees that
+ the sensitive policy and key data for the group and potential rekey
+ data for this individual cannot be read by anyone but the intended
+ recipient.
+
+ If any error occurs during KeyDL message processing, regardless of
+ whether the GM is in Terse or Verbose Mode, the registration session
+ MUST be terminated, the GM MUST send a Key Download - Ack/Failure
+ message, and all saved state information MUST be cleared. If in
+ Terse Mode, the Notification Payload will be of type NACK to indicate
+ termination. If in Verbose Mode, the Notification Payload will
+ contain the type of error encountered.
+
+5.2.1.3. Request to Join Error
+
+ The exchange type for Request to Join Error is eleven (11).
+
+ The components of the Request to Join Error Message are shown in
+ Table 3:
+
+ Table 3: Request to Join Error (RTJ-Err) Message Definition
+
+ Message Name : Request to Join Error (RTJ-Err)
+ Dissection : {HDR-GrpID, [Nonce_I], Notification, [VendorID]}
+ Payload Types : GSAKMP Header, [Nonce] Notification, [Vendor ID]
+
+ In response to an unacceptable RTJ, the GC/KS MAY send a Request to
+ Join Error (RTJ-Err) message containing an appropriate Notification
+ payload. Note that the RTJ-Err message is not a signed message for
+ the following reasons: the lack of awareness on the GM's perspective
+ of who is a valid GC/KS as well as the need to protect the GC/KS from
+ signing messages and using valuable resources. Following the sending
+ of an RTJ-Err, the GC/KS MUST terminate the session, and all saved
+ state information MUST be cleared.
+
+ Upon receipt of an RTJ-Err message, the GM will validate the
+ following: the GroupID in the header belongs to a group to which the
+ GM has sent an RTJ, and, if present, the Nonce_I matches a Nonce_I
+ sent in an RTJ to that group. If the above checks are successful,
+ the GM MAY terminate the state associated with that GroupID and
+
+
+
+
+
+Harney, et al. Standards Track [Page 33]
+
+RFC 4535 GSAKMP June 2006
+
+
+ nonce. The GM SHOULD be capable of receiving a valid KeyDownload
+ message for that GroupID and nonce after receiving an RTJ-Err for a
+ locally configured amount of time.
+
+5.2.1.4. Key Download - Ack/Failure
+
+ The exchange type for Key Download - Ack/Failure is four (4).
+
+ The components of the Key Download - Ack/Failure Message are shown in
+ Table 4:
+
+ Table 4: Key Download - Ack/Failure (KeyDL-A/F) Message Definition
+
+ Message Name : Key Download - Ack/Failure (KeyDL-A/F)
+ Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
+ Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
+ ID], Signature
+ SigM : Signature of Group Member
+ {}SigX : Indicates fields used in Signature
+
+ In response to a properly processed KeyDL message, the GM creates and
+ sends the KeyDL-A/F message. As defined in the dissection of the
+ message, this message MUST contain payloads to hold the following
+ information: Notification payload of type Acknowledgement (ACK) and
+ signature information. If synchronized time is not available, the
+ Nonce payload MUST be present for freshness, and the nonce value
+ transmitted MUST be the GM's generated Nonce_C value. If the GM does
+ not receive a KeyDL message within a locally configured amount of
+ time, the GM MAY send a new RTJ. If the GM receives a valid LOA (see
+ Section 5.2.1.5) message from the GC/KS before receipt of a KeyDL
+ message, the GM SHOULD send a KeyDL-A/F message of type NACK followed
+ by a new RTJ.
+
+ The GC/KS MUST be able to process the KeyDL-A/F message. <Process
+ KeyDL-A/F> indicates the GC/KS actions that will determine how the
+ KeyDL-A/F message will be acted upon. The following checks SHOULD be
+ performed in the order presented.
+
+ In this procedure, the GC/KS will verify that the message header is
+ properly formed and confirm that this message is for this group by
+ checking the value of the GroupID. If the header checks pass, the
+ GC/KS MUST check the message for freshness. If using nonces, the
+ GC/KS MUST use its saved Nonce_C value and compare it for equality
+ with the received Nonce_C value. If not using nonces, the GC/KS MUST
+ check the timestamp in the Signature payload to determine if the
+ message is new. After freshness is confirmed, the signature MUST be
+ verified to ensure its authenticity. The GC/KS MUST use verified and
+ trusted authentication material from a known root. If the message
+
+
+
+Harney, et al. Standards Track [Page 34]
+
+RFC 4535 GSAKMP June 2006
+
+
+ signature verifies, the GC/KS processes the Notification payload. If
+ the notification type is of type ACK, then the registration has
+ completed successfully, and both parties SHOULD remove state
+ information associated with this GM's registration.
+
+ If the GC/KS does not receive a KeyDL-A/F message of proper form or
+ is unable to correctly process the KeyDL-A/F message, the
+ Notification payload type is any value except ACK; or if no KeyDL-A/F
+ message is received within the locally configured timeout, the GC/KS
+ MUST evict this GM from the group in the next policy-defined Rekey
+ Event. The GC/KS MAY send the OPTIONAL Lack_of_Ack message if
+ running in Verbose Mode as defined in Section 5.2.1.5.
+
+5.2.1.5. Lack of Ack
+
+ The exchange type for Lack of Ack is twelve (12).
+
+ The components of a Lack of Ack Message are shown in Table 5:
+
+ Table 5: Lack of Ack (LOA) Message Definition
+
+ Message Name : Lack of Ack (LOA)
+ Dissection : {HDR-GrpID, Member ID, [Nonce_R, Nonce_C],
+ Notification, [VendorID]} SigC, [Cert]
+ Payload Types : GSAKMP Header, Identification, [Nonce],
+ Notification, [Vendor ID], Signature,
+ [Certificate]
+
+ SigC : Signature of Group Controller Key Server
+ Cert : Necessary Certificates, zero or more
+ {}SigX : Indicates fields used in Signature
+ [] : Indicate an optional data item
+
+ If the GC/KS's local timeout value expires prior to receiving a
+ KeyDL-A/F from the GM, the GC/KS MAY create and send a LOA message to
+ the GM. As defined in the dissection of the message, this message
+ MUST contain payloads to hold the following information: GM
+ identification, Notification of error, and signature information.
+
+ If synchronized time is not available, the Nonce payloads MUST be
+ present for freshness, and the nonce values transmitted MUST be the
+ GC/KS's generated Nonce_R value and the combined Nonce_C value which
+ was generated by using the GC/KS's Nonce_R value and the Nonce_I
+ value received from the GM in the RTJ. These values were already
+ generated during the Key Download message phase.
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 35]
+
+RFC 4535 GSAKMP June 2006
+
+
+ The GM MAY be able to process the LOA message based upon local
+ configuration. <Process LOA> indicates the GM actions that will
+ determine how the LOA message will be acted upon. The following
+ checks SHOULD be performed in the order presented.
+
+ In this procedure, the GM MUST verify that the message header is
+ properly formed and confirm that this message is for this group by
+ checking the value of the GroupID. If the header checks pass, the GM
+ MUST confirm that this message was intended for itself by comparing
+ the Member ID in the Identification payload to its identity. After
+ identification confirmation, the freshness values are checked. If
+ using nonces, the GM MUST use its save Nonce_I value, extract the
+ received GC/KS Nonce_R value, compute the combined Nonce_C value, and
+ compare it to the received Nonce_C value. If not using nonces, the
+ GM MUST check the timestamp in the Signature payload to determine if
+ the message is new. After freshness is confirmed, access control
+ checks MUST be performed on the GC/KS to determine its authority
+ within this group. Then signature MUST be verified to ensure its
+ authenticity, The GM MUST use verified and trusted authentication
+ material from a known root.
+
+ If the checks succeed, the GM SHOULD resend a KeyDL-A/F for that
+ session.
+
+5.2.2. Cookies: Group Establishment with Denial of Service Protection
+
+ This section defines an OPTIONAL capability that MAY be implemented
+ into GSAKMP when using IP-based groups. The information in this
+ section borrows heavily from [IKEv2] as this protocol has already
+ worked through this issue and GSAKMP is copying this concept. This
+ section will contain paraphrased sections of [IKEv2] modified for
+ GSAKMP to define the purpose of Cookies.
+
+ An optional Cookie mode is being defined for the GSAKMP to help
+ against DoS attacks.
+
+ The term "cookies" originates with Karn and Simpson [RFC2522] in
+ Photuris, an early proposal for key management with IPSec. The
+ ISAKMP fixed message header includes two eight-octet fields titled
+ "cookies". Instead of placing this cookie data in the header, in
+ GSAKMP this data is moved into a Notification payload.
+
+ An expected attack against GSAKMP is state and CPU exhaustion, where
+ the target GC/KS is flooded with Request to Join requests from forged
+ IP addresses. This attack can be made less effective if a GC/KS
+ implementation uses minimal CPU and commits no state to the
+ communication until it knows the initiator potential GM can receive
+ packets at the address from which it claims to be sending them. To
+
+
+
+Harney, et al. Standards Track [Page 36]
+
+RFC 4535 GSAKMP June 2006
+
+
+ accomplish this, the GC/KS (when operating in Cookie mode) SHOULD
+ reject initial Request to Join messages unless they contain a
+ Notification payload of type "cookie". It SHOULD instead send a
+ Cookie Download message as a response to the RTJ and include a cookie
+ in a notify payload of type Cookie_Required. Potential GMs who
+ receive such responses MUST retry the Request to Join message with
+ the responder-GC/KS-supplied cookie in its notification payload of
+ type Cookie, as defined by the optional Notification payload of the
+ Request to Join Msg in Section 5.2.1.1. This initial exchange will
+ then be as shown in Figure 2 with the components of the new message
+ Cookie Download shown in Table 6. The exchange type for Cookie
+ Download is ten (10).
+
+ CONTROLLER MESSAGE MEMBER
+ in Cookie Mode
+ !<--Request to Join without Cookie Info---!
+ <Gen Cookie>! !
+ <Response >! !
+ !----------Cookie Download--------------->!
+ ! ! <Process CD>
+ !<----Request to Join with Cookie Info----!
+ <Process> ! !
+ <RTJ > ! !
+ !-------------Key Download--------------->!
+ ! ! <Proc KeyDL>
+ !<-----Key Download - Ack/Failure--------!
+ <Process >! !
+ <KeyDL-A/F>! !
+ !<=======SHARED KEYED GROUP SESSION======>!
+
+ Figure 2: GSAKMP Ladder Diagram with Cookies
+
+
+ Table 6: Cookie Download Message Definition
+
+ Message Name : Cookie Download
+ Dissection : {HDR-GrpID, Notif_COOKIE_REQUIRED, [VendorID]}
+ Payload Types : GSAKMP Header, Notification, [Vendor ID]
+
+
+ The first two messages do not affect any GM or GC/KS state except for
+ communicating the cookie.
+
+ A GSAKMP implementation SHOULD implement its GC/KS cookie generation
+ in such a way as not to require any saved state to recognize its
+ valid cookie when the second Request to Join message arrives. The
+ exact algorithms and syntax they use to generate cookies does not
+ affect interoperability and hence is not specified here.
+
+
+
+Harney, et al. Standards Track [Page 37]
+
+RFC 4535 GSAKMP June 2006
+
+
+ The following is an example of how an endpoint could use cookies to
+ implement limited DoS protection.
+
+ A good way to do this is to set the cookie to be:
+
+ Cookie = <SecretVersionNumber> | Hash(Ni | IPi | <secret>)
+
+ where <secret> is a randomly generated secret known only to the
+ responder GC/KS and periodically changed, Ni is the nonce value taken
+ from the initiator potential GM, and IPi is the asserted IP address
+ of the candidate GM. The IP address is either the IP header's source
+ IP address or else the IP address contained in the optional
+ Notification "IPvalue" payload (if it is present).
+ <SecretVersionNumber> should be changed whenever <secret> is
+ regenerated. The cookie can be recomputed when the "Request to Join
+ with Cookie Info" arrives and compared to the cookie in the received
+ message. If it matches, the responder GC/KS knows that all values
+ have been computed since the last change to <secret> and that IPi
+ MUST be the same as the source address it saw the first time.
+ Incorporating Ni into the hash assures that an attacker who sees only
+ the Cookie_Download message cannot successfully forge a "Request to
+ Join with Cookie Info" message. This Ni value MUST be the same Ni
+ value from the original "Request to Join" message for the calculation
+ to be successful.
+
+ If a new value for <secret> is chosen while connections are in the
+ process of being initialized, a "Request to Join with Cookie Info"
+ might be returned with a <SecretVersionNumber> other than the current
+ one. The responder GC/KS in that case MAY reject the message by
+ sending another response with a new cookie, or it MAY keep the old
+ value of <secret> around for a short time and accept cookies computed
+ from either one. The responder GC/KS SHOULD NOT accept cookies
+ indefinitely after <secret> is changed, since that would defeat part
+ of the denial of service protection. The responder GC/KS SHOULD
+ change the value of <secret> frequently, especially if under attack.
+
+ An alternative example for Cookie value generation in a NAT
+ environment is to substitute the IPi value with the IPValue received
+ in the Notification payload in the RTJ message. This scenario is
+ indicated by the presence of the Notification payload of type
+ IPValue. With this substitution, a calculation similar to that
+ described above can be used.
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 38]
+
+RFC 4535 GSAKMP June 2006
+
+
+5.2.3. Group Establishment for Receive-Only Members
+
+ This section describes an OPTIONAL capability that may be implemented
+ in a structured system where the authorized (S-)GC/KS is known in
+ advance through out-of-band means and where synchronized time is
+ available.
+
+ Unlike Standard Group Establishment, in the Receive-Only system, the
+ GMs and (S-)GC/KSes operate in Terse Mode and exchange one message
+ only: the Key Download. Potential new GMs do not send an RTJ.
+ (S-)GC/KSes do not expect Key Download - ACK/Failure messages and do
+ not remove GMs for lack or receipt of the message.
+
+ Operation is as follows: upon notification via an authorized out-of-
+ band event, the (S-)GC/KS forms and sends a Key Download message to
+ the new member with the Nonce payloads ABSENT. The GM verifies
+
+ - the ID payload identifies that GM
+
+ - the timestamp in the message is fresh
+
+ - the message is signed by an authorized (S-)GC/KS
+
+ - the signature on the message verifies
+
+ When using a Diffie-Hellman Key Creation Type for receive-only
+ members, a static-ephemeral model is assumed: the Key Creation
+ payload in the Key Download message contains the (S-)GC/KS's public
+ component. The member's public component is assumed to be obtained
+ through secure out-of-band means.
+
+5.3. Group Maintenance
+
+ The Group Maintenance phase includes member joins and leaves, group
+ rekey activities, policy updates, and group destruction. These
+ activities are presented in the following sections.
+
+5.3.1. Group Management
+
+5.3.1.1. Rekey Events
+
+ A Rekey Event is any action, including a compromise report or key
+ expiration, that requires the creation of a new group key and/or
+ rekey information.
+
+ Once an event has been identified (as defined in the group security
+ policy token), the GC/KS MUST create and provide a signed message
+ containing the GTPK and rekey information to the group.
+
+
+
+Harney, et al. Standards Track [Page 39]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Each GM who receives this message MUST verify the signature on the
+ message to ensure its authenticity. If the message signature does
+ not verify, the message MUST be discarded. Upon verification, the GM
+ will find the appropriate rekey download packet and decrypt the
+ information with a stored rekey key(s). If a new Policy Token is
+ distributed with the message, it MUST be encrypted in the old GTPK.
+
+ The exchange type for Rekey Event is five (5).
+
+ The components of a Rekey Event message are shown in Table 7:
+
+ Table 7: Rekey Event Message Definition
+
+ Message Name : Rekey Event
+ Dissection : {HDR-GrpID, ([Policy Token])*, Rekey Array,
+ [VendorID]}SigC, [Cert]
+ Payload Types : GSAKMP Header, [Policy Token], Rekey Event,
+ [Vendor ID], Signature, [Certificate],
+
+ SigC : Signature of Group Controller Key Server
+ Cert : Necessary Certificates, zero or more
+ {}SigX : Indicates fields used in Signature
+ (data)* : Indicates encrypted information
+ [] : Indicate an optional data item
+
+5.3.1.2. Policy Updates
+
+ New policy tokens are sent via the Rekey Event message. These policy
+ updates may be coupled with an existing rekey event or may be sent in
+ a message with the Rekey Event Type of the Rekey Event Payload set to
+ None(0) (see Section 7.5.1).
+
+ A policy token MUST NOT be processed if the processing of the Rekey
+ Event message carrying it fails. Policy token processing is type
+ dependent and is beyond the scope of this document.
+
+5.3.1.3. Group Destruction
+
+ Group destruction is also accomplished via the Rekey Event message.
+ In a Rekey Event message for group destruction, the Sequence ID is
+ set to 0xFFFFFFFF. Upon receipt of this authenticated Rekey Event
+ message, group components MUST terminate processing of information
+ associated with the indicated group.
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 40]
+
+RFC 4535 GSAKMP June 2006
+
+
+5.3.2. Leaving a Group
+
+ There are several conditions under which a member will leave a group:
+ eviction, voluntary departure without notice, and voluntary departure
+ with notice (de-registration). Each of these is discussed in this
+ section.
+
+5.3.2.1. Eviction
+
+ At some point in the group's lifetime, it may be desirable to evict
+ one or more members from a group. From a key management viewpoint,
+ this involves revoking access to the group's protected data by
+ "disabling" the departing members' keys. This is accomplished with a
+ Rekey Event, which is discussed in more detail in Section 5.3.1.1.
+ If future access to the group is also to be denied, the members MUST
+ be added to a denied access control list, and the policy token's
+ authorization rules MUST be appropriately updated so that they will
+ exclude the expelled GM(s). After receipt of a new PT, GMs SHOULD
+ evaluate the trustworthiness of any recent application data
+ originating from the expelled GM(s).
+
+5.3.2.2. Voluntary Departure without Notice
+
+ If a member wishes to leave a group for which membership imposes no
+ cost or responsibility to that member, then the member MAY merely
+ delete local copies of group keys and cease group activities.
+
+5.3.2.3. De-Registration
+
+ If the membership in the group does impose cost or responsibility to
+ the departing member, then the member SHOULD de-register from the
+ group when that member wishes to leave. De-registration consists of
+ a three-message exchange between the GM and the member's GC/KS: the
+ Request_to_Depart, Departure_Response, and the Departure_Ack.
+ Compliant GSAKMP implementations for GMs SHOULD support the de-
+ registration messages. Compliant GSAKMP implementations for GC/KSes
+ MUST support the de-registration messages.
+
+5.3.2.3.1. Request to Depart
+
+ The Exchange Type for a Request_to_Depart Message is thirteen (13).
+ The components of a Request_to_Depart Message are shown in Table 8.
+
+ Any GM desiring to initiate the de-registration process MUST generate
+ and send an RTD message to notify the GC/KS of its intent. As
+ defined in the dissection of the RTD message, this message MUST
+ contain payloads to hold the following information: the GC/KS
+ identification and Notification of the desire to leave the group.
+
+
+
+Harney, et al. Standards Track [Page 41]
+
+RFC 4535 GSAKMP June 2006
+
+
+ When synchronization time is not available to the system as defined
+ by the Policy Token, a Nonce payload MUST be included for freshness,
+ and the Nonce_I value MUST be saved for later use. This message MUST
+ then be signed by the GM.
+
+ Table 8: Request_to_Depart (RTD) Message Definition
+
+ Message Name : Request_to_Depart (RTD)
+ Dissection : {HDR-GrpID, GC/KS_ID, [Nonce_I], Notif_Leave_Group,
+ [VendorID]} SigM, [Cert]
+ Payload Types : GSAKMP Header, Identification, [Nonce],
+ Notification, [Vendor ID], Signature,
+ [Certificate]
+
+ SigM : Signature of Group Member
+ Cert : Necessary Certificates, zero or more
+ {}SigX : Indicates fields used in Signature
+ [] : Indicate an optional data item
+
+ Upon receipt of the RTD message, the GC/KS MUST verify that the
+ message header is properly formed and confirm that this message is
+ for this group by checking the value of the GroupID. If the header
+ checks pass, then the identifier value in Identification payload is
+ compared to its own, the GC/KS's identity, to confirm that the GM
+ intended to converse with this GC/KS, the GC/KS who registered this
+ member into the group. Then the identity of the sender is extracted
+ from the Signature payload. This identity MUST be used to confirm
+ that this GM is a member of the group serviced by this GC/KS. Then
+ the GC/KS will confirm from the Notification payload that the GM is
+ requesting to leave the group. Then the GC/KS will verify the
+ signature on the message to ensure its authenticity. The GC/KS MUST
+ use verified and trusted authentication material from a known root.
+ If all checks pass and the message is successfully processed, then
+ the GC/KS MUST form a Departure_Response message as defined in
+ Section 5.3.2.3.2.
+
+ If the processing of the message fails, the de-registration session
+ MUST be terminated, and all state associated with this session is
+ removed. If the GC/KS is operating in Terse Mode, then no error
+ message is sent to the GM. If the GC/KS is operating in Verbose
+ Mode, then the GC/KS sends a Departure_Response Message with a
+ Notification Payload of type Request_to_Depart_Error.
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 42]
+
+RFC 4535 GSAKMP June 2006
+
+
+5.3.2.3.2. Departure_Response
+
+ The Exchange Type for a Departure_Response Message is fourteen (14).
+ The components of a Departure_Response Message are shown in Table 9.
+
+ In response to a properly formed and verified RTD message, the GC/KS
+ MUST create and send the DR message. As defined in the dissection of
+ the message, this message MUST contain payloads to hold the following
+ information: GM identification, Notification for acceptance of
+ departure, and signature information. If synchronization time is not
+ available, the Nonce payloads MUST be included in the message for
+ freshness.
+
+ Table 9: Departure_Response (DR) Message Definition
+
+ Message Name : Departure_Response (DR)
+ Dissection : {HDR-GrpID, Member_ID, [Nonce_R, Nonce_C],
+ Notification, [VendorID]} SigC, [Cert]
+ Payload Types : GSAKMP Header, Identification, [Nonce],
+ Notification, [Vendor ID], Signature,
+ [Certificate]
+
+ SigC : Signature of Group Member
+ Cert : Necessary Certificates, zero or more
+ {}SigX : Indicates fields used in Signature
+ [] : Indicate an optional data item
+
+ If present, the nonce values transmitted MUST be the GC/KS's
+ generated Nonce_R value and the combined Nonce_C value that was
+ generated by using the GC/KS's Nonce_R value and the Nonce_I value
+ received from the GM in the RTD. This Nonce_C value MUST be saved
+ relative to this departing GM's ID.
+
+ The GM MUST be able to process the Departure_Response message. The
+ following checks SHOULD be performed in the order presented.
+
+ The GM MUST verify that the message header is properly formed and
+ confirm that this message is for this group by checking the value of
+ the GroupID. If the header checks pass, the GM MUST confirm that
+ this message was intended for itself by comparing the Member ID in
+ the Identification payload to its identity. After identification
+ confirmation, the freshness values are checked. If using nonces, the
+ GM MUST use its saved Nonce_I value, extract the received GC/KS
+ Nonce_R value, compute the combined Nonce_C value, and compare it for
+ equality with the received Nonce_C value. If not using nonces, the
+ GM MUST check the timestamp in the signature payload to determine if
+ the message is new. After freshness is confirmed, confirmation of
+ the identity of the signer of the DR message is the GMs authorized
+
+
+
+Harney, et al. Standards Track [Page 43]
+
+RFC 4535 GSAKMP June 2006
+
+
+ GC/KS is performed. Then, the signature MUST be verified to ensure
+ its authenticity. The GM MUST use verified and trusted
+ authentication material from a known root. If the message signature
+ verifies, then the GM MUST verify that the Notification is of Type
+ Departure_Accepted or Request_to_Depart_Error.
+
+ If the processing is successful, and the Notification payload is of
+ type Departure_Accepted, the member MUST form the Departure_ACK
+ message as defined in Section 5.3.2.3.3. If the processing is
+ successful, and the Notification payload is of type
+ Request_to_Depart_Error, the member MUST remove all state associated
+ with the de-registration session. If the member still desires to
+ De-Register from the group, the member MUST restart the de-
+ registration process.
+
+ If the processing of the message fails, the de-registration session
+ MUST be terminated, and all state associated with this session is
+ removed. If the GM is operating in Terse Mode, then a Departure_Ack
+ Message with Notification Payload of type NACK is sent to the GC/KS.
+ If the GM is operating in Verbose Mode, then the GM sends a
+ Departure_Ack Message with a Notification Payload of the appropriate
+ failure type.
+
+5.3.2.3.3. Departure_ACK
+
+ The Exchange Type for a Departure_ACK Message is fifteen (15). The
+ components of the Departure_ACK Message are shown in Table 10:
+
+ Table 10: Departure_ACK (DA) Message Definition
+
+ Message Name : Departure_ACK (DA)
+ Dissection : {HDR-GrpID, [Nonce_C], Notif_Ack, [VendorID]}SigM
+ Payload Types : GSAKMP Header, [Nonce], Notification, [Vendor
+ ID], Signature
+ SigM : Signature of Group Member
+ {}SigX : Indicates fields used in Signature
+
+ In response to a properly processed Departure_Response message, the
+ GM MUST create and send the Departure_ACK message. As defined in the
+ dissection of the message, this message MUST contain payloads to hold
+ the following information: Notification payload of type
+ Acknowledgement (ACK) and signature information. If synchronization
+ time is not available, the Nonce payload MUST be present for
+ freshness, and the nonce value transmitted MUST be the GM's generated
+ Nonce_C value.
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 44]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Upon receipt of the Departure_ACK, the GC/KS MUST perform the
+ following checks. These checks SHOULD be performed in the order
+ presented.
+
+ In this procedure, the GC/KS MUST verify that the message header is
+ properly formed and confirm that this message is for this group by
+ checking the value of the GroupID. If the header checks pass, the
+ GC/KS MUST check the message for freshness. If using nonces, the
+ GC/KS MUST use its saved Nonce_C value and compare it to the received
+ Nonce_C value. If not using nonces, the GC/KS MUST check the
+ timestamp in the signature payload to determine if the message is
+ new. After freshness is confirmed, the signature MUST be verified to
+ ensure its authenticity. The GC/KS MUST use verified and trusted
+ authentication material from a known root. If the message signature
+ verifies, the GC/KS processes the Notification payload. If the
+ notification type is of type ACK, this is considered a successful
+ processing of this message.
+
+ If the processing of the message is successful, the GC/KS MUST remove
+ the member from the group. This MAY involve initiating a Rekey Event
+ for the group.
+
+ If the processing of the message fails or if no Departure_Ack is
+ received, the GC/KS MAY issue a LOA message.
+
+6. Security Suite
+
+ The Security Definition Suite 1 MUST be supported. Other security
+ suite definitions MAY be defined in other Internet specifications.
+
+6.1. Assumptions
+
+ All potential GMs will have enough information available to them to
+ use the correct Security Suite to join the group. This can be
+ accomplished by a well-known default suite, 'Security Suite 1', or by
+ announcing/posting another suite.
+
+6.2. Definition Suite 1
+
+ GSAKMP implementations MUST support the following suite of algorithms
+ and configurations. The following definition of Suite 1 borrows
+ heavily from IKE's Oakley group 2 definition and Oakley itself.
+
+ The GSAKMP Suite 1 definition gives all the algorithm and
+ cryptographic definitions required to process group establishment
+ messages. It is important to note that GSAKMP does not negotiate
+
+
+
+
+
+Harney, et al. Standards Track [Page 45]
+
+RFC 4535 GSAKMP June 2006
+
+
+ these cryptographic mechanisms. This definition is set by the Group
+ Owner via the Policy Token (passed during the GSAKMP exchange for
+ member verification purposes).
+
+ The GSAKMP Suite 1 definition is:
+
+ Key download and Policy Token encryption algorithm definition:
+ Algorithm: AES
+ Mode: CBC
+ Key Length: 128 bits
+
+ Policy Token digital signature algorithm is:
+ DSS-ASN1-DER
+ Hash algorithm is:
+ SHA-1
+
+ Nonce Hash algorithm is:
+ SHA-1
+
+ The Key Creation definition is:
+ Algorithm type is Diffie Hellman
+ MODP group definition
+ g: 2
+ p: "FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1"
+ "29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD"
+ "EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245"
+ "E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED"
+ "EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381"
+ "FFFFFFFF FFFFFFFF"
+
+ NOTE: The p and g values come from IKE [RFC2409], Section 6.2,
+ "Second Oakley Group", and p is 1024 bits long.
+
+
+ The GSAKMP message digital signature algorithm is:
+ DSS-SHA1-ASN1-DER
+
+ The digital signature ID type is:
+ ID-DN-STRING
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 46]
+
+RFC 4535 GSAKMP June 2006
+
+
+7. GSAKMP Payload Structure
+
+ A GSAKMP Message is composed of a GSAKMP Header (Section 7.1)
+ followed by at least one GSAKMP Payload. All GSAKMP Payloads are
+ composed of the Generic Payload Header (Section 7.2) followed by the
+ specific payload data. The message is chained by a preceding payload
+ defining its succeeding payload. Payloads are not required to be in
+ the exact order shown in the message dissection in Section 5,
+ provided that all required payloads are present. Unless it is
+ explicitly stated in a dissection that multiple payloads of a single
+ type may be present, no more than one payload of each type allowed by
+ the message may appear. The final payload in a message will point to
+ no succeeding payload.
+
+ All fields of type integer in the Header and Payload structure that
+ are larger than one octet MUST be converted into Network Byte Order
+ prior to data transmission.
+
+ Padding of fields MUST NOT be done as this leads to processing
+ errors.
+
+ When a message contains a Vendor ID payload, the processing of the
+ payloads of that message is modified as defined in Section 7.10.
+
+7.1. GSAKMP Header
+
+7.1.1. GSAKMP Header Structure
+
+ The GSAKMP Header fields are shown in Figure 3 and defined as:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! GroupID Type ! GroupID Length! Group ID Value ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ! Next Payload ! Version ! Exchange Type !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Sequence ID !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 3: GSAKMP Header Format
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 47]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Group Identification Type (1 octet) - Table 11 presents the group
+ identification types. This field is treated as an unsigned
+ value.
+
+ Table 11: Group Identification Types
+
+ Grp ID Type Value Description
+ _____________________________________________________________________
+
+ Reserved 0
+ UTF-8 1 Format defined in Section 7.1.1.1.1.
+ Octet String 2 This type MUST be implemented.
+ Format defined in Section 7.1.1.1.2.
+ IPv4 3 Format defined in Section 7.1.1.1.3.
+ IPv6 4 Format defined in Section 7.1.1.1.4.
+ Reserved to IANA 5 - 192
+ Private Use 193 - 255
+
+ Group Identification Length (1 octet) - Length of the Group
+ Identification Value field in octets. This value MUST NOT be
+ zero (0). This field is treated as an unsigned value.
+
+ Group Identification Value (variable length) - Indicates the
+ name/title of the group. All GroupID types should provide unique
+ naming across groups. GroupID types SHOULD provide this
+ capability by including a random element generated by the creator
+ (owner) of the group of at least eight (8) octets, providing
+ extremely low probability of collision in group names. The
+ GroupID value is static throughout the life of the group.
+
+ Next Payload (1 octet) - Indicates the type of the next payload in
+ the message. The format for each payload is defined in the
+ following sections. Table 12 presents the payload types. This
+ field is treated as an unsigned value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 48]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Table 12: Payload Types
+
+ Next_Payload_Type Value
+ ___________________________________
+
+ None 0
+ Policy Token 1
+ Key Download Packet 2
+ Rekey Event 3
+ Identification 4
+ Reserved 5
+ Certificate 6
+ Reserved 7
+ Signature 8
+ Notification 9
+ Vendor ID 10
+ Key Creation 11
+ Nonce 12
+ Reserved to IANA 13 - 192
+ Private Use 193 - 255
+
+ Version (1 octet) - Indicates the version of the GSAKMP protocol in
+ use. The current value is one (1). This field is treated as an
+ unsigned value.
+
+ Exchange Type (1 octet) - Indicates the type of exchange (also known
+ as the message type). Table 13 presents the exchange type
+ values. This field is treated as an unsigned value.
+
+ Table 13: Exchange Types
+
+ Exchange_Type Value
+ ________________________________________
+
+ Reserved 0 - 3
+ Key Download Ack/Failure 4
+ Rekey Event 5
+ Reserved 6 - 7
+ Request to Join 8
+ Key Download 9
+ Cookie Download 10
+ Request to Join Error 11
+ Lack of Ack 12
+ Request to Depart 13
+ Departure Response 14
+ Departure Ack 15
+ Reserved to IANA 16 - 192
+ Private Use 193 - 255
+
+
+
+Harney, et al. Standards Track [Page 49]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Sequence ID (4 octets) - The Sequence ID is used for replay
+ protection of group management messages. If the message is not a
+ group management message, this value MUST be set to zero (0).
+ The first value used by a (S-)GC/KS MUST be one (1). For each
+ distinct group management message that this (S-)GC/KS transmits,
+ this value MUST be incremented by one (1). Receivers of this
+ group management message MUST confirm that the value received is
+ greater than the value of the sequence ID received with the last
+ group management message from this (S-)GC/KS. Group Components
+ (e.g., GMs, S-GC/KSes) MUST terminate processing upon receipt of
+ an authenticated group management message containing a Sequence
+ ID of 0xFFFFFFFF. This field is treated as an unsigned integer
+ in network byte order.
+
+ Length (4 octets) - Length of total message (header + payloads) in
+ octets. This field is treated as an unsigned integer in network
+ byte order.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 50]
+
+RFC 4535 GSAKMP June 2006
+
+
+7.1.1.1. GroupID Structure
+
+ This section defines the formats for the defined GroupID types.
+
+7.1.1.1.1. UTF-8
+
+ The format for type UTF-8 [RFC3629] is shown in Figure 4.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Random Value ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! UTF-8 String ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 4: GroupID UTF-8 Format
+
+ Random Value (16 octets) - For the UTF-8 GroupID type, the Random
+ Value is represented as a string of exactly 16 hexadecimal digits
+ converted from its octet values in network-byte order. The
+ leading zero hexadecimal digits and the trailing zero hexadecimal
+ digits are always included in the string, rather than being
+ truncated.
+
+ UTF-8 String (variable length) - This field contains the human
+ readable portion of the GroupID in UTF-8 format. Its length is
+ calculated as the (GroupID Length - 16) for the Random Value
+ field. The minimum length for this field is one (1) octet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 51]
+
+RFC 4535 GSAKMP June 2006
+
+
+7.1.1.1.2. Octet String
+
+ The format for type Octet String is shown in Figure 5.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Random Value ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Octet String ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 5: GroupID Octet String Format
+
+ Random Value (8 octets) - The 8-octet unsigned random value in
+ network byte order format.
+
+ Octet String (variable length) - This field contains the Octet String
+ portion of the GroupID. Its length is calculated as the (GroupID
+ Length - 8) for the Random Value field. The minimum length for
+ this field is one (1) octet.
+
+7.1.1.1.3. IPv4 Group Identifier
+
+ The format for type IPv4 Group Identifier is shown in Figure 6.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Random Value ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! IPv4 Value !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 6: GroupID IPv4 Format
+
+ Random Value (8 octets) - The 8-octet unsigned random value in
+ network byte order format.
+
+ IPv4 Value (4 octets) - The IPv4 value in network byte order format.
+ This value MAY contain the multicast address of the group.
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 52]
+
+RFC 4535 GSAKMP June 2006
+
+
+7.1.1.1.4. IPv6 Group Identifier
+
+ The format for type IPv6 Group Identifier is shown in Figure 7.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Random Value ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! IPv6 Value ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 7: GroupID IPv6 Format
+
+ Random Value (8 octets) - The 8-octet unsigned random value in
+ network byte order format.
+
+ IPv6 Value (16 octets) - The IPv6 value in network byte order format.
+ This value MAY contain the multicast address of the group.
+
+7.1.2. GSAKMP Header Processing
+
+ When processing the GSAKMP Header, the following fields MUST be
+ checked for correct values:
+
+ 1. Group ID Type - The Group ID Type value MUST be checked to be a
+ valid group identification payload type as defined by Table 11.
+ If the value is not valid, then an error is logged. If in
+ Verbose Mode, an appropriate message containing notification
+ value Payload-Malformed will be sent.
+
+ 2. GroupID - The GroupID of the received message MUST be checked
+ against the valid GroupIDs of the Group Component. If no match
+ is found, then an error is logged; in addition, if in Verbose
+ Mode, an appropriate message containing notification value
+ Invalid-Group-ID will be sent.
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 53]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 3. Next Payload - The Next Payload value MUST be checked to be a
+ valid payload type as defined by Table 12. If the value is not
+ valid, then an error is logged. If in Verbose Mode, an
+ appropriate message containing notification value Invalid-
+ Payload-Type will be sent.
+
+ 4. Version - The GSAKMP version number MUST be checked that its
+ value is one (1). For other values, see below for processing.
+ The GSAKMP version number MUST be checked that it is consistent
+ with the group's policy as specified in its Policy Token. If the
+ version is not supported or authorized, then an error is logged.
+ If in Verbose Mode, an appropriate message containing
+ notification value Invalid-Version will be sent.
+
+ 5. Exchange Type - The Exchange Type MUST be checked to be a valid
+ exchange type as defined by Table 13 and MUST be of the type
+ expected to be received by the GSAKMP state machine. If the
+ exchange type is not valid, then an error is logged. If in
+ Verbose Mode, an appropriate message containing notification
+ value Invalid-Exchange-Type will be sent.
+
+ 6. Sequence ID - The Sequence ID value MUST be checked for
+ correctness. For negotiation messages, this value MUST be zero
+ (0). For group management messages, this value MUST be greater
+ than the last sequence ID received from this (S-)GC/KS. Receipt
+ of incorrect Sequence ID on group management messages MUST NOT
+ cause a reply message to be generated. Upon receipt of incorrect
+ Sequence ID on non-group management messages, an error is logged.
+ If in Verbose Mode, an appropriate message containing
+ notification value Invalid-Sequence-ID will be sent.
+
+ The length fields in the GSAKMP Header (Group ID Length and Length)
+ are used to help process the message. If any field is found to be
+ incorrect, then an error is logged. If in Verbose Mode, an
+ appropriate message containing notification value Payload-Malformed
+ will be sent.
+
+ In order to allow a GSAKMP version one (v1) implementation to
+ interoperate with future versions of the protocol, some ideas will be
+ discussed here to this effect.
+
+ A (S-)GC/KS that is operating in a multi-versioned group as defined
+ by the Policy Token can take many approaches on how to interact with
+ the GMs in this group for a rekey message.
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 54]
+
+RFC 4535 GSAKMP June 2006
+
+
+ One possible solution is for the (S-)GC/KS to send out multiple rekey
+ messages, one per version level that it supports. Then each GM would
+ only process the message that has the version at which it is
+ operating.
+
+ An alternative approach that all GM v1 implementations MUST support
+ is the embedding of a v1 message inside a version two (v2) message.
+ If a GM running at v1 receives a GSAKMP message that has a version
+ value greater than one (1), the GM will attempt to process the
+ information immediately after the Group Header as a Group Header for
+ v1 of the protocol. If this is in fact a v1 Group Header, then the
+ remainder of this v1 message will be processed in place. After
+ processing this v1 embedded message, the data following the v1
+ message should be the payload as identified by the Next Payload field
+ in the original header of the message and will be ignored by the v1
+ member. However, if the payload following the initial header is not
+ a v1 Group Header, then the GM will gracefully handle the
+ unrecognized message.
+
+7.2. Generic Payload Header
+
+7.2.1. Generic Payload Header Structure
+
+ Each GSAKMP payload defined in the following sections begins with a
+ generic header, shown in Figure 8, that provides a payload "chaining"
+ capability and clearly defines the boundaries of a payload. The
+ Generic Payload Header fields are defined as follows:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 8: Generic Payload Header
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+
+
+
+Harney, et al. Standards Track [Page 55]
+
+RFC 4535 GSAKMP June 2006
+
+
+7.2.2. Generic Payload Header Processing
+
+ When processing the Generic Payload Header, the following fields MUST
+ be checked for correct values:
+
+ 1. Next Payload - The Next Payload value MUST be checked to be a
+ valid payload type as defined by Table 12. If the payload type
+ is not valid, then an error is logged. If in Verbose Mode, an
+ appropriate message containing notification value Invalid-
+ Payload-Type will be sent.
+
+ 2. RESERVED - This field MUST contain the value zero (0). If the
+ value of this field is not zero (0), then an error is logged. If
+ in Verbose Mode, an appropriate message containing notification
+ value Payload-Malformed will be sent.
+
+ The length field in the Generic Payload Header is used to process the
+ remainder of the payload. If this field is found to be incorrect,
+ then an error is logged. If in Verbose Mode, an appropriate message
+ containing notification value Payload-Malformed will be sent.
+
+7.3. Policy Token Payload
+
+7.3.1. Policy Token Payload Structure
+
+ The Policy Token Payload contains authenticatable group-specific
+ information that describes the group security-relevant behaviors,
+ access control parameters, and security mechanisms. Figure 9 shows
+ the format of the payload.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Policy Token Type ! Policy Token Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 9: Policy Token Payload Format
+
+ The Policy Token Payload fields are defined as follows:
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+
+
+
+Harney, et al. Standards Track [Page 56]
+
+RFC 4535 GSAKMP June 2006
+
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+ Policy Token Type (2 octets) - Specifies the type of Policy Token
+ being used. Table 14 identifies the types of policy tokens.
+ This field is treated as an unsigned integer in network byte
+ order format.
+
+ Table 14: Policy Token Types
+
+ Policy_Token_Type Value Definition/Defined In
+ ____________________________________________________________________
+
+ Reserved 0
+ GSAKMP_ASN.1_PT_V1 1 All implementations of GSAKMP
+ MUST support this PT format.
+ Format specified in [RFC4534].
+ Reserved to IANA 2 - 49152
+ Private Use 49153 - 65535
+
+ Policy Token Data (variable length) - Contains Policy Token
+ information. The values for this field are token specific, and
+ the format is specified by the PT Type field.
+
+ If this payload is encrypted, only the Policy Token Data field is
+ encrypted.
+
+ The payload type for the Policy Token Payload is one (1).
+
+7.3.2. Policy Token Payload Processing
+
+ When processing the Policy Token Payload, the following fields MUST
+ be checked for correct values:
+
+ 1. Next Payload, RESERVED, Payload Length - These fields are
+ processed as defined in Section 7.2.2, "Generic Payload Header
+ Processing".
+
+ 2. Policy Token Type - The Policy Token Type value MUST be checked
+ to be a valid policy token type as defined by Table 14. If the
+ value is not valid, then an error is logged. If in Verbose Mode,
+ an appropriate message containing notification value Payload-
+ Malformed will be sent.
+
+
+
+
+
+Harney, et al. Standards Track [Page 57]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 3. Policy Token Data - This Policy Token Data MUST be processed
+ according to the Policy Token Type specified. The type will
+ define the format of the data.
+
+7.4. Key Download Payload
+
+ Refer to the terminology section for the different terms relating to
+ keys used within this section.
+
+7.4.1. Key Download Payload Structure
+
+ The Key Download Payload contains group keys (e.g., group keys,
+ initial rekey keys, etc.). These key download payloads can have
+ several security attributes applied to them based upon the security
+ policy of the group. Figure 10 shows the format of the payload.
+
+ The security policy of the group dictates that the key download
+ payload MUST be encrypted with a key encryption key (KEK). The
+ encryption mechanism used is specified in the Policy Token. The
+ group members MUST create the KEK using the key creation method
+ identified in the Key Creation Payload.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Number of Items ! Key Download Data Items ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 10: Key Download Payload Format
+
+ The Key Download Payload fields are defined as follows:
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 58]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Number of Items (2 octets) - Contains the total number of group
+ traffic protection keys and Rekey Arrays being passed in this
+ data block. This field is treated as an unsigned integer in
+ network byte order format.
+
+ Key Download Data Items (variable length) - Contains Key Download
+ information. The Key Download Data is a sequence of
+ Type/Length/Data of the Number of Items. The format for each
+ item is defined in Figure 11.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! KDD Item Type ! Key Download Data Item Length! ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ Data for Key Download Data Item (Key Datum/Rekey Array) ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 11: Key Download Data Item Format
+
+ For each Key Download Data Item, the data format is as follows:
+
+ Key Download Data (KDD) Item Type (1 octet) - Identifier for the
+ type of data contained in this Key Download Data Item. See
+ Table 15 for the possible values of this field. This field
+ is treated as an unsigned value.
+
+ Key Download Data Item Length (2 octets) - Length in octets of
+ the Data for the Key Download Data Item following this field.
+ This field is treated as an unsigned integer in network byte
+ order format.
+
+ Data for Key Download Data Item (variable length) - Contains Keys
+ and related information. The format of this field is
+ specific depending on the value of the Key Download Data Item
+ Type field. For KDD Item Type of GTPK, this field will
+ contain a Key Datum as defined in Section 7.4.1.1. For KDD
+ Item Type Rekey - LKH, this field will contain a Rekey Array
+ as defined in Section 7.4.1.2.
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 59]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Table 15: Key Download Data Item Types
+
+ Key Download Data Value Definition
+ Item Type
+ _________________________________________________________________
+
+ GTPK 0 This type MUST be implemented.
+ This type identifies that the
+ data contains group traffic
+ protection key information.
+ Rekey - LKH 1 Optional
+ Reserved to IANA 2 - 192
+ Private Use 193 - 255
+
+ The encryption of this payload only covers the data subsequent to the
+ Generic Payload header (Number of Items and Key Download Data Items
+ fields).
+
+ The payload type for the Key Download Packet is two (2).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 60]
+
+RFC 4535 GSAKMP June 2006
+
+
+7.4.1.1. Key Datum Structure
+
+ A Key Datum contains all the information for a key. Figure 12 shows
+ the format for this structure.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Key Type ! Key ID ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ! Key Handle ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ! Key Creation Date ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! ! Key Expiration Date ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ! ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ Key Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 12: Key Datum Format
+
+ Key Type (2 octets) - This is the cryptographic algorithm for which
+ this key data is to be used. This value is specified in the
+ Policy Token. See Table 16 for the possible values of this
+ field. This field is treated as an unsigned value.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 61]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Table 16: Cryptographic Key Types
+
+ Cryptographic_Key_Types Value Description/Defined In
+ ____________________________________________________________________
+
+ Reserved 0 - 2
+ 3DES_CBC64_192 3 See [RFC2451].
+ Reserved 4 - 11
+ AES_CBC_128 12 This type MUST be
+ supported. See [IKEv2].
+ AES_CTR 13 See [IKEv2].
+ Reserved to IANA 14 - 49152
+ Private Use 49153 - 65535
+
+ Key ID (4 octets) - This is the permanent ID of all versions of the
+ key. This value MAY be defined by the Policy Token. This field
+ is treated as an octet string.
+
+ Key Handle (4 octets) - This is the value to uniquely identify a
+ version (particular instance) of a key. This field is treated as
+ an octet string.
+
+ Key Creation Date (15 octets) - This is the time value of when this
+ key data was originally generated. This field contains the
+ timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year
+ (0000 - 9999), MM is the numerical value of the month (01 - 12),
+ DD is the day of the month (01 - 31), HH is the hour of the day
+ (00 - 23), MM is the minute within the hour (00 - 59), SS is the
+ seconds within the minute (00 - 59), and the letter Z indicates
+ that this is Zulu time. This format is loosely based on
+ [RFC3161].
+
+ Key Expiration Date (15 octets) - This is the time value of when this
+ key is no longer valid for use. This field contains the
+ timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year
+ (0000 - 9999), MM is the numerical value of the month (01 - 12),
+ DD is the day of the month (01 - 31), HH is the hour of the day
+ (00 - 23), MM is the minute within the hour (00 - 59), SS is the
+ seconds within the minute (00 - 59), and the letter Z indicates
+ that this is Zulu time. This format is loosely based on
+ [RFC3161].
+
+ Key Data (variable length) - This is the actual key data, which is
+ dependent on the Key Type algorithm for its format.
+
+ NOTE: The combination of the Key ID and the Key Handle MUST be unique
+ within the group. This combination will be used to uniquely identify
+ a key.
+
+
+
+Harney, et al. Standards Track [Page 62]
+
+RFC 4535 GSAKMP June 2006
+
+
+7.4.1.2. Rekey Array Structure
+
+ A Rekey Array contains the information for the set of KEKs that is
+ associated with a Group Member. Figure 13 shows the format for this
+ structure.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Rekey Version#! Member ID ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ! Number of KEK Keys ! ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ Key Datum(s) ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 13: Rekey Array Structure Format
+
+ Rekey Version (1 octet) - Contains the version of the Rekey protocol
+ in which the data is formatted. For Key Download Data Item Type
+ of Rekey - LKH, refer to Section A.2 for a description of this
+ value. This field is treated as an unsigned value.
+
+ Member ID (4 octets) - This is the Member ID of the Rekey sequence
+ contained in this Rekey Array. This field is treated as an octet
+ string. For Key Download Data Item Type of Rekey - LKH, refer to
+ Section A.2 for a description of this value.
+
+ Number of KEK Keys (2 octets) - This value is the number of distinct
+ KEK keys in this sequence. This value is treated as an unsigned
+ integer in network byte order format.
+
+ Key Datum(s) (variable length) - The sequence of KEKs in Key Datum
+ format. The format for each Key Datum in this sequence is
+ defined in section 7.4.1.1.
+
+ Key ID (for Key ID within the Rekey) - LKH space, refer to Section
+ A.2 for a description of this value.
+
+7.4.2. Key Download Payload Processing
+
+ Prior to processing its data, the payload contents MUST be decrypted.
+
+ When processing the Key Download Payload, the following fields MUST
+ be checked for correct values:
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 63]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 1. Next Payload, RESERVED, Payload Length - These fields are
+ processed as defined in Section 7.2.2, "Generic Payload Header
+ Processing".
+
+ 2. KDD Item Type - All KDD Item Type fields MUST be checked to be a
+ valid Key Download Data Item type as defined by Table 15. If the
+ value is not valid, then an error is logged. If in Verbose Mode,
+ an appropriate message containing notification value Payload-
+ Malformed will be sent.
+
+ 3. Key Type - All Key Type fields MUST be checked to be a valid
+ encryption type as defined by Table 16. If the value is not
+ valid, then an error is logged. If in Verbose Mode, an
+ appropriate message containing notification value Invalid-Key-
+ Information will be sent.
+
+ 4. Key Expiration Date - All Key Expiration Date fields MUST be
+ checked confirm that their values represent a future and not a
+ past time value. If the value is not valid, then an error is
+ logged. If in Verbose Mode, an appropriate message containing
+ notification value Invalid-Key-Information will be sent.
+
+ The length and counter fields in the payload are used to help process
+ the payload. If any field is found to be incorrect, then an error is
+ logged. If in Verbose Mode, an appropriate message containing
+ notification value Payload-Malformed will be sent.
+
+7.5. Rekey Event Payload
+
+ Refer to the terminology section for the different terms relating to
+ keys used within this section.
+
+7.5.1. Rekey Event Payload Structure
+
+ The Rekey Event Payload MAY contain multiple keys encrypted in
+ Wrapping KEKs. Figure 14 shows the format of the payload. If the
+ data to be contained within a Rekey Event Payload is too large for
+ the payload, the sequence can be split across multiple Rekey Event
+ Payloads at a Rekey Event Data boundary.
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 64]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! RekeyEvnt Type! Rekey Event Header ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ Rekey Event Data(s) ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 14: Rekey Event Payload Format
+
+ The Rekey Event Payload fields are defined as follows:
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+ Rekey Event Type (1 octet) - Specifies the type of Rekey Event being
+ used. Table 17 presents the types of Rekey events. This field
+ is treated as an unsigned value.
+
+ Rekey Event Header (variable length) - This is the header information
+ for the Rekey Event. The format for this is defined in Section
+ 7.5.1.1, "Rekey Event Header Structure".
+
+ Rekey Event Data(s) (variable length) - This is the rekey information
+ for the Rekey Event. The format for this is defined in Section
+ 7.5.1.2, "Rekey Event Data Structure".
+
+ The Rekey Event payload type is three (3).
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 65]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Table 17: Rekey Event Types
+
+ Rekey_Event_Type Value Definition/Defined In
+ _____________________________________________________________________
+
+ None 0 This type MUST be implemented.
+ In this case, the size of the Rekey
+ Event Data field will be zero bytes
+ long. The purpose of a Rekey Event
+ Payload with type None is when it is
+ necessary to send out a new token
+ with no rekey information. GSAKMP
+ rekey msg requires a Rekey Event
+ Payload, and in this instance it
+ would have rekey data of type None.
+ GSAKMP_LKH 1 The rekey data will be of
+ type LKH formatted according to
+ GSAKMP. The format for this field
+ is defined in Section 7.5.1.2.
+ Reserved to IANA 2 - 192
+ Private Use 193 - 255
+
+7.5.1.1. Rekey Event Header Structure
+
+ The format for the Rekey Event Header is shown in Figure 15.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Group ID Value ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ Group ID Value !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Time/Date Stamp ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ! RekeyEnt Type ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Algorithm Ver ! # of Rekey Event Data(s) !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 15: Rekey Event Header Format
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 66]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Group Identification Value (variable length) - Indicates the
+ name/title of the group to be rekeyed. This is the same format,
+ length, and value as the Group Identification Value in Section
+ 7.1, "GSAKMP Header".
+
+ Time/Date Stamp (15 octets) - This is the time value when the Rekey
+ Event Data was generated. This field contains the timestamp in
+ UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 -
+ 9999), MM is the numerical value of the month (01 - 12), DD is
+ the day of the month (01 - 31), HH is the hour of the day (00 -
+ 23), MM is the minute within the hour (00 - 59), SS is the
+ seconds within the minute (00 - 59), and the letter Z indicates
+ that this is Zulu time. This format is loosely based on
+ [RFC3161].
+
+ Rekey Event Type (1 octet) - This is the Rekey algorithm being used
+ for this group. The values for this field can be found in Table
+ 17. This field is treated as an unsigned value.
+
+ Algorithm Version (1 octet) - Indicates the version of the Rekey Type
+ being used. For Rekey Event Type of GSAKMP_LKH, refer to Section
+ A.2 for a description of this value. This field is treated as an
+ unsigned value.
+
+ # of Rekey Event Data(s) (2 octets) - The number of Rekey Event
+ Data(s) contained in the Rekey Data. This value is treated as an
+ unsigned integer in network byte order.
+
+7.5.1.2. Rekey Event Data Structure
+
+ As defined in the Rekey Event Header, # of Rekey Data(s) field,
+ multiple pieces of information are sent in a Rekey Event Data. Each
+ end user, will be interested in only one Rekey Event Data among all
+ of the information sent. Each Rekey Event Data will contain all the
+ Key Packages that a user requires. For each Rekey Event Data, the
+ data following the Wrapping fields is encrypted with the key
+ identified in the Wrapping Header. Figure 16 shows the format of
+ each Rekey Event Data.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 67]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Packet Length ! Wrapping KeyID ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ! Wrapping Key Handle ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ! # of Key Packages !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Key Packages(s) ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 16: Rekey Event Data Format
+
+ Packet Length (2 octets) - Length in octets of the Rekey Event Data,
+ which consists of the # of Key Packages and the Key Packages(s).
+ This value is treated as an unsigned integer in network byte
+ order.
+
+ Wrapping KeyID (4 octets) - This is the Key ID of the KEK that is
+ being used for encryption/decryption of the new (rekeyed) keys.
+ For Rekey Event Type of Rekey - LKH, refer to Section A.2 for a
+ description of this value.
+
+ Wrapping Key Handle (4 octets) - This is a Key Handle of the KEK that
+ is being used for encryption/decryption of the new (rekeyed)
+ keys. Refer to Section 7.4.1.1 for the values of this field.
+
+ # of Key Packages (2 octets) - The number of key packages contained
+ in this Rekey Event Data. This value is treated as an unsigned
+ integer in network byte order.
+
+ Key Package(s) (variable length) - The type/length/value format of a
+ Key Datum. The format for this is defined in Section 7.5.1.2.1.
+
+7.5.1.2.1. Key Package Structure
+
+ Each Key Package contains all the information about the key. Figure
+ 17 shows the format for a Key Package.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! KeyPkg Type ! Key Package Length ! Key Datum ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 17: Key Package Format
+
+
+
+
+Harney, et al. Standards Track [Page 68]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Key Package Type (1 octet) - The type of key in this key package.
+ Legal values for this field are defined in Table 15, Key Download
+ Data Types. This field is treated as an unsigned value.
+
+ Key Package Length (2 octets) - The length of the Key Datum. This
+ field is treated as an unsigned integer in network byte order
+ format.
+
+ Key Datum (variable length) - The actual data of the key. The format
+ for this field is defined in Section 7.4.1.1, "Key Datum
+ Structure".
+
+7.5.2. Rekey Event Payload Processing
+
+ When processing the Rekey Event Payload, the following fields MUST be
+ checked for correct values:
+
+ 1. Next Payload, RESERVED, Payload Length - These fields are
+ processed as defined in Section 7.2.2, "Generic Payload Header
+ Processing".
+
+ 2. Rekey Event Type field within "Rekey Event" payload header - The
+ Rekey Event Type MUST be checked to be a valid rekey event type
+ as defined by Table 17. If the Rekey Event Type is not valid,
+ then regardless of mode (e.g., Terse or Verbose) an error is
+ logged. No response error message is generated for receipt of a
+ Group Management Message.
+
+ 3. Group ID Value - The Group ID value of the Rekey Event Header
+ received message MUST be checked against the GroupID of the Group
+ Component. If no match is found, the payload is discarded, then
+ regardless of mode (e.g., Terse or Verbose) an error is logged.
+ No response error message is generated for receipt of a Group
+ Management Message.
+
+ 4. Date/Time Stamp - The Date/Time Stamp value of the Rekey Event
+ Header MAY be checked to determine if the Rekey Event generation
+ time is recent relative to network delay and processing times.
+ If the TimeStamp is judged not to be recent, an error is logged.
+ No response error message is generated for receipt of a Group
+ Management Message.
+
+ 5. Rekey Event Type field within the "Rekey Event Header" - The
+ Rekey Event Type of the Rekey Event Header received message MUST
+ be checked to be a valid rekey event type, as defined by Table
+ 17, and the same value of the Rekey Event Type earlier in this
+ payload. If the Rekey Event Type is not valid or not equal to
+ the previous value of the Rekey Event Type, then regardless of
+
+
+
+Harney, et al. Standards Track [Page 69]
+
+RFC 4535 GSAKMP June 2006
+
+
+ mode (e.g., Terse or Verbose) an error is logged. No response
+ error message is generated for receipt of a Group Management
+ Message.
+
+ 6. Algorithm Version - The Rekey Algorithm Version number MUST be
+ checked to ensure that the version indicated is supported. If it
+ is not supported, then regardless of mode (e.g., Terse or
+ Verbose) an error is logged. No response error message is
+ generated for receipt of a Group Management Message.
+
+ The length and counter fields are used to help process the message.
+ If any field is found to be incorrect, then termination processing
+ MUST be initiated.
+
+ A GM MUST process all the Rekey Event Datas as based on the rekey
+ method used there is a potential that multiple Rekey Event Datas are
+ for this GM. The Rekey Event Datas are processed in order until all
+ Rekey Event Datas are consumed.
+
+ 1. Wrapping KeyID - The Wrapping KeyID MUST be checked against the
+ list of stored KEKs that this GM holds. If a match is found,
+ then continue processing this Rekey Event Data. Otherwise, skip
+ to the next Rekey Event Data.
+
+ 2. Wrapping Handle - If a matching Wrapping KeyID was found, then
+ the Wrapping Handle MUST be checked against the handle of the KEK
+ for which the KeyID was a match. If the handles match, then the
+ GM will process the Key Packages associated with this Rekey Event
+ Data. Otherwise, skip to the next Rekey Event Data.
+
+ If a GM has found a matching Wrapping KeyID and Wrapping Handle, the
+ GM decrypts the remaining data in this Rekey Event Data according to
+ policy using the KEK defined by the Wrapping KeyID and Handle. After
+ decrypting the data, the GM extracts the # of Key Packages field to
+ help process the subsequent Key Packages. The Key Packages are
+ processed as follows:
+
+ 1. Key Package Type - The Key Package Type MUST be checked to be a
+ valid key package type as defined by Table 15. If the Key
+ Package Type is not valid, then regardless of mode (e.g., Terse
+ or Verbose) an error is logged. No response error message is
+ generated for receipt of a Group Management Message.
+
+ 2. Key Package Length - The Key Package Length is used to process
+ the subsequent Key Datum information.
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 70]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 3. Key Type - The Key Type MUST be checked to be a valid key type as
+ defined by Table 16. If the Key Package Type is not valid, then
+ regardless of mode (e.g., Terse or Verbose) an error is logged.
+ No response error message is generated for receipt of a Group
+ Management Message.
+
+ 4. Key ID - The Key ID MUST be checked against the set of Key IDs
+ that this user maintains for this Key Type. If no match is
+ found, then regardless of mode (e.g., Terse or Verbose) an error
+ is logged. No response error message is generated for receipt of
+ a Group Management Message.
+
+ 5. Key Handle - The Key Handle is extracted as is and is used to be
+ the new Key Handle for the Key currently associated with the Key
+ Package's Key ID.
+
+ 6. Key Creation Date - The Key Creation Date MUST be checked that it
+ is subsequent to the Key Creation Date for the currently held
+ key. If this date is prior to the currently held key, then
+ regardless of mode (e.g., Terse or Verbose) an error is logged.
+ No response error message is generated for receipt of a Group
+ Management Message.
+
+ 7. Key Expiration Date - The Key Expiration Date MUST be checked
+ that it is subsequent to the Key Creation Date just received and
+ that the time rules conform with policy. If the expiration date
+ is not subsequent to the creation date or does not conform with
+ policy, then regardless of mode (e.g., Terse or Verbose) an error
+ is logged. No response error message is generated for receipt of
+ a Group Management Message.
+
+ 8. Key Data - The Key Data is extracted based on the length
+ information in the key package.
+
+ If there were no errors when processing the Key Package, the key
+ represented by the KeyID will have all of its data updated based upon
+ the received information.
+
+7.6. Identification Payload
+
+7.6.1. Identification Payload Structure
+
+ The Identification Payload contains entity-specific data used to
+ exchange identification information. This information is used to
+ verify the identities of members. Figure 18 shows the format of the
+ Identification Payload.
+
+
+
+
+
+Harney, et al. Standards Track [Page 71]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! ID Classif ! ID Type ! Identification Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 18: Identification Payload Format
+
+ The Identification Payload fields are defined as follows:
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+ Identification (ID) Classification (1 octet) - Classifies the
+ ownership of the Identification Data. Table 18 identifies
+ possible values for this field. This field is treated as an
+ unsigned value.
+
+ Table 18: Identification Classification
+
+ ID_Classification Value
+ _______________________________
+
+ Sender 0
+ Receiver 1
+ Third Party 2
+ Reserved to IANA 3 - 192
+ Private Use 193 - 255
+
+ Identification (ID) Type (1 octet) - Specifies the type of
+ Identification being used. Table 19 identifies possible values
+ for this type. This field is treated as an unsigned value. All
+ defined types are OPTIONAL unless otherwise stated.
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 72]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Identification Data (variable length) - Contains identity
+ information. The values for this field are group specific, and
+ the format is specified by the ID Type field. The format for
+ this field is stated in conjunction with the type in Table 19.
+
+ The payload type for the Identification Payload is four (4).
+
+ Table 19: Identification Types
+
+ ID_Type Value PKIX Cert Description
+ Field Defined In
+ _____________________________________________________________________
+
+ Reserved 0
+ ID_IPV4_ADDR 1 SubjAltName See [IKEv2]
+ iPAddress Section 3.5.
+ ID_FQDN 2 SubjAltName See [IKEv2]
+ dNSName Section 3.5.
+ ID_RFC822_ADDR 3 SubjAltName See [IKEv2]
+ rfc822Name Section 3.5.
+ Reserved 4
+ ID_IPV6_ADDR 5 SubjAltName See [IKEv2]
+ iPAddress Section 3.5.
+ Reserved 6 - 8
+ ID_DER_ASN1_DN 9 Entire Subject, See [IKEv2]
+ bitwise Compare Section 3.5.
+ Reserved 10
+ ID_KEY_ID 11 N/A See [IKEv2]
+ Reserved 12 - 29 Section 3.5.
+ Unencoded Name 30 Subject The format for
+ (ID_U_NAME) this type is
+ defined in
+ Section 7.6.1.1.
+ ID_DN_STRING 31 Subject See [RFC4514].
+ This type MUST
+ be implemented.
+ Reserved to IANA 32 - 192
+ Private Use 193 - 255
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 73]
+
+RFC 4535 GSAKMP June 2006
+
+
+7.6.1.1. ID_U_NAME Structure
+
+ The format for type Unencoded Name (ID_U_NAME) is shown in Figure 19.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Serial Number ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! DN Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 19: Unencoded Name (ID-U-NAME) Format
+
+ Serial Number (20 octets) - The certificate serial number. This
+ field is treated as an unsigned integer in network byte order
+ format.
+
+ Length (4 octets) - Length in octets of the DN Data field. This
+ field is treated as an unsigned integer in network byte order
+ format.
+
+ DN Data (variable length) - The actual UTF-8 DN value (Subject field)
+ using the slash (/) character for field delimiters (e.g.,
+ "/C=US/ST=MD/L=Somewhere/O=ACME, Inc./OU=DIV1/CN=user1/
+ Email=user1@acme.com" without the surrounding quotes).
+
+7.6.2. Identification Payload Processing
+
+ When processing the Identification Payload, the following fields MUST
+ be checked for correct values:
+
+ 1. Next Payload, RESERVED, Payload Length - These fields are
+ processed as defined in Section 7.2.2, "Generic Payload Header
+ Processing".
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 74]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 2. Identification Classification - The Identification Classification
+ value MUST be checked to be a valid identification classification
+ type as defined by Table 18. If the value is not valid, then an
+ error is logged. If in Verbose Mode, an appropriate message
+ containing notification value Payload-Malformed will be sent.
+
+ 3. Identification Type - The Identification Type value MUST be
+ checked to be a valid identification type as defined by Table 19.
+ If the value is not valid, then an error is logged. If in
+ Verbose Mode, an appropriate message containing notification
+ value Payload-Malformed will be sent.
+
+ 4. Identification Data - This Identification Data MUST be processed
+ according to the identification type specified. The type will
+ define the format of the data. If the identification data is
+ being used to find a match and no match is found, then an error
+ is logged. If in Verbose Mode, an appropriate message containing
+ notification value Invalid-ID-Information will be sent.
+
+7.6.2.1. ID_U_NAME Processing
+
+ When processing the Identification Data of type ID_U_NAME, the
+ following fields MUST be checked for correct values:
+
+ 1. Serial Number - The serial number MUST be a greater than or equal
+ to one (1) to be a valid serial number from a conforming CA
+ [RFC3280]. If the value is not valid, then an error is logged.
+ If in Verbose Mode, an appropriate message containing
+ notification value Payload-Malformed will be sent.
+
+ 2. DN Data - The DN data is processed as a UTF-8 string.
+
+ 3. The CA MUST be a valid trusted policy creation authority as
+ defined by the Policy Token.
+
+ These 2 pieces of information, Serial Number and DN Data, in
+ conjunction, will then be used for party identification. These
+ values are also used to help identify the certificate when necessary.
+
+7.7. Certificate Payload
+
+7.7.1. Certificate Payload Structure
+
+ The Certificate Payload provides a means to transport certificates or
+ other certificate-related information via GSAKMP and can appear in
+ any GSAKMP message. Certificate payloads SHOULD be included in an
+ exchange whenever an appropriate directory service (e.g., LDAP
+ [RFC4523]) is not available to distribute certificates. Multiple
+
+
+
+Harney, et al. Standards Track [Page 75]
+
+RFC 4535 GSAKMP June 2006
+
+
+ certificate payloads MAY be sent to enable verification of
+ certificate chains. Conversely, zero (0) certificate payloads may be
+ sent, and the receiving GSAKMP MUST rely on some other mechanism to
+ retrieve certificates for verification purposes. Figure 20 shows the
+ format of the Certificate Payload.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Cert Type ! Certificate Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 20: Certificate Payload Format
+
+ The Certificate Payload fields are defined as follows:
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+ Certificate Type (2 octets) - This field indicates the type of
+ certificate or certificate-related information contained in the
+ Certificate Data field. Table 20 presents the types of
+ certificate payloads. This field is treated as an unsigned
+ integer in network byte order format.
+
+ Certificate Data (variable length) - Actual encoding of certificate
+ data. The type of certificate is indicated by the Certificate
+ Type/Encoding field.
+
+ The payload type for the Certificate Payload is six (6).
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 76]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Table 20: Certificate Payload Types
+
+ Certificate_Type Value Description/
+ Defined In
+ _____________________________________________________________________
+
+ None 0
+ Reserved 1 - 3
+ X.509v3 Certificate 4 This type MUST be
+ -- Signature implemented.
+ -- DER Encoding Contains a DER
+ encoded X.509
+ certificate.
+ Reserved 5 - 6
+ Certificate Revocation List 7 Contains a BER
+ (CRL) encoded X.509 CRL.
+ Reserved 8 - 9
+ X.509 Certificate 10 See [IKEv2], Sec 3.6.
+ -- Attribute
+ Raw RSA Key 11 See [IKEv2], Sec 3.6.
+ Hash and URL of X.509 12 See [IKEv2], Sec 3.6.
+ Certificate
+ Hash and URL of X.509 13 See [IKEv2], Sec 3.6.
+ bundle
+ Reserved to IANA 14 -- 49152
+ Private Use 49153 -- 65535
+
+7.7.2. Certificate Payload Processing
+
+ When processing the Certificate Payload, the following fields MUST be
+ checked for correct values:
+
+ 1. Next Payload, RESERVED, Payload Length - These fields are
+ processed as defined in Section 7.2.2, "Generic Payload Header
+ Processing".
+
+ 2. Certificate Type - The Certificate Type value MUST be checked to
+ be a valid certificate type as defined by Table 20. If the value
+ is not valid, then an error is logged. If in Verbose Mode, an
+ appropriate message containing notification value Cert-Type-
+ Unsupported will be sent.
+
+ 3. Certificate Data - This Certificate Data MUST be processed
+ according to the certificate type specified. The type will
+ define the format of the data. Receipt of a certificate of the
+ trusted policy creation authority in a Certificate payload causes
+
+
+
+
+
+Harney, et al. Standards Track [Page 77]
+
+RFC 4535 GSAKMP June 2006
+
+
+ the payload to be discarded. This received certificate MUST NOT
+ be used to verify the message. The certificate of the trusted
+ policy creation authority MUST be retrieved by other means.
+
+7.8. Signature Payload
+
+7.8.1. Signature Payload Structure
+
+ The Signature Payload contains data generated by the digital
+ signature function. The digital signature, as defined by the
+ dissection of each message, covers the message from the GSAKMP
+ Message Header through the Signature Payload, up to but not
+ including the Signature Data Length. Figure 21 shows the format
+ of the Signature Payload.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Signature Type ! Sig ID Type ! ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ Signature Timestamp ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ! Signer ID Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Signer ID Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Signature Length ! Signature Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 21: Signature Payload Format
+
+ The Signature Payload fields are defined as follows:
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+
+
+Harney, et al. Standards Track [Page 78]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+ Signature Type (2 octets) - Indicates the type of signature. Table
+ 21 presents the allowable signature types. This field is treated
+ as an unsigned integer in network byte order format.
+
+ Table 21: Signature Types
+
+ Signature Type Value Description/
+ Defined In
+ _____________________________________________________________________
+
+ DSS/SHA1 with ASN.1/DER encoding 0 This type MUST
+ (DSS-SHA1-ASN1-DER) be supported.
+ RSA1024-MD5 1 See [RFC3447].
+ ECDSA-P384-SHA3 2 See [FIPS186-2].
+ Reserved to IANA 3 - 41952
+ Private Use 41953 - 65536
+
+ Signature ID Type (1 octet) - Indicates the format for the Signature
+ ID Data. These values are the same as those defined for the
+ Identification Payload Identification types, which can be found
+ in Table 19. This field is treated as an unsigned value.
+
+ Signature Timestamp (15 octets) - This is the time value when the
+ digital signature was applied. This field contains the timestamp
+ in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 -
+ 9999), MM is the numerical value of the month (01 - 12), DD is
+ the day of the month (01 - 31), HH is the hour of the day (00 -
+ 23), MM is the minute within the hour (00 - 59), SS is the
+ seconds within the minute (00 - 59), and the letter Z indicates
+ that this is Zulu time. This format is loosely based on
+ [RFC3161].
+
+ Signer ID Length (2 octets) - Length in octets of the Signer's ID.
+ This field is treated as an unsigned integer in network byte
+ order format.
+
+ Signer ID Data (variable length) - Data identifying the Signer's ID
+ (e.g., DN). The format for this field is based on the Signature
+ ID Type field and is shown where that type is defined. The
+ contents of this field MUST be checked against the Policy Token
+ to determine the authority and access of the Signer within the
+ context of the group.
+
+
+
+
+
+Harney, et al. Standards Track [Page 79]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Signature Length (2 octets) - Length in octets of the Signature Data.
+ This field is treated as an unsigned integer in network byte
+ order format.
+
+ Signature Data (variable length) - Data that results from applying
+ the digital signature function to the GSAKMP message and/or
+ payload.
+
+ The payload type for the Signature Payload is eight (8).
+
+7.8.2. Signature Payload Processing
+
+ When processing the Signature Payload, the following fields MUST be
+ checked for correct values:
+
+ 1. Next Payload, RESERVED, Payload Length - These fields are
+ processed as defined in Section 7.2.2, "Generic Payload Header
+ Processing".
+
+ 2. Signature Type - The Signature Type value MUST be checked to be a
+ valid signature type as defined by Table 21. If the value is not
+ valid, then an error is logged. If in Verbose Mode, an
+ appropriate message containing notification value Payload-
+ Malformed will be sent.
+
+ 3. Signature ID Type - The Signature ID Type value MUST be checked
+ to be a valid signature ID type as defined by Table 19. If the
+ value is not valid, then an error is logged. If in Verbose Mode,
+ an appropriate message containing notification value Payload-
+ Malformed will be sent.
+
+ 4. Signature Timestamp - This field MAY be checked to determine if
+ the transaction signing time is fresh relative to expected
+ network delays. Such a check is appropriate for systems in which
+ archived sequences of events are desired.
+
+ NOTE: The maximum acceptable age of a signature timestamp
+ relative to the local system clock is a locally configured
+ parameter that can be tuned by its GSAKMP management interface.
+
+ 5. Signature ID Data - This field will be used to identify the
+ sending party. This information MUST then be used to confirm
+ that the correct party sent this information. This field is also
+ used to retrieve the appropriate public key of the certificate to
+ verify the message.
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 80]
+
+RFC 4535 GSAKMP June 2006
+
+
+ 6. Signature Data - This value MUST be compared to the recomputed
+ signature to verify the message. Information on how to verify
+ certificates used to ascertain the validity of the signature can
+ be found in [RFC3280]. Only after the certificate identified by
+ the Signature ID Data is verified can the signature be computed
+ to compare to the signature data for signature verification. A
+ potential error that can occur during signature verification is
+ Authentication-Failed. Potential errors that can occur while
+ processing certificates for signature verification are: Invalid-
+ Certificate, Invalid-Cert-Authority, Cert-Type-Unsupported, and
+ Certificate-Unavailable.
+
+ The length fields in the Signature Payload are used to process the
+ remainder of the payload. If any field is found to be incorrect,
+ then termination processing MUST be initiated.
+
+7.9. Notification Payload
+
+7.9.1. Notification Payload Structure
+
+ The Notification Payload can contain both GSAKMP and group-specific
+ data and is used to transmit informational data, such as error
+ conditions, to a GSAKMP peer. It is possible to send multiple
+ independent Notification payloads in a single GSAKMP message. Figure
+ 22 shows the format of the Notification Payload.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Notification Type ! Notification Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 22: Notification Payload Format
+
+ The Notification Payload fields are defined as follows:
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 81]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+ Notification Type (2 octets) - Specifies the type of notification
+ message. Table 22 presents the Notify Payload Types. This field
+ is treated as an unsigned integer in network byte order format.
+
+ Notification Data (variable length) - Informational or error data
+ transmitted in addition to the Notify Payload Type. Values for
+ this field are Domain of Interpretation (DOI) specific.
+
+ The payload type for the Notification Payload is nine (9).
+
+ Table 22: Notification Types
+
+ Notification Type Value
+ __________________________________________________________
+
+ None 0
+ Invalid-Payload-Type 1
+ Reserved 2 - 3
+ Invalid-Version 4
+ Invalid-Group-ID 5
+ Invalid-Sequence-ID 6
+ Payload-Malformed 7
+ Invalid-Key-Information 8
+ Invalid-ID-Information 9
+ Reserved 10 - 11
+ Cert-Type-Unsupported 12
+ Invalid-Cert-Authority 13
+ Authentication-Failed 14
+ Reserved 15 - 16
+ Certificate-Unavailable 17
+ Reserved 18
+ Unauthorized-Request 19
+ Reserved 20 - 22
+ Acknowledgement 23
+ Reserved 24 - 25
+ Nack 26
+ Cookie-Required 27
+ Cookie 28
+ Mechanism Choices 29
+ Leave Group 30
+ Departure Accepted 31
+ Request to Depart Error 32
+ Invalid Exchange Type 33
+ IPv4 Value 34
+
+
+
+Harney, et al. Standards Track [Page 82]
+
+RFC 4535 GSAKMP June 2006
+
+
+ IPv6 Value 35
+ Prohibited by Group Policy 36
+ Prohibited by Locally Configured Policy 37
+ Reserved to IANA 38 - 49152
+ Private Use 49153 -- 65535
+
+7.9.1.1. Notification Data - Acknowledgement (ACK) Payload Type
+
+ The data portion of the Notification payload of type ACK either
+ serves as confirmation of correct receipt of the Key Download message
+ or, when needed, provides other receipt information when included in
+ a signed message. Figure 23 shows the format of the Notification
+ Data - Acknowledge Payload Type.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Ack Type ! Acknowledgement Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 23: Notification Data - Acknowledge Payload Type Format
+
+ The Notification Data - Acknowledgement Payload Type data fields are
+ defined as follows:
+
+ Ack Type (1 octet) - Specifies the type of acknowledgement. Table 23
+ presents the Notify Acknowledgement Payload Types. This field is
+ treated as an unsigned value.
+
+ Table 23: Acknowledgement Types
+
+ ACK_Type Value Definition
+ _____________________________________________________
+
+ Simple 0 Data portion null.
+ Reserved to IANA 1 - 192
+ Private Use 193 - 255
+
+7.9.1.2. Notification Data - Cookie_Required and Cookie Payload Type
+
+ The data portion of the Notification payload of types Cookie_Required
+ and Cookie contain the Cookie value. The value for this field will
+ have been computed by the responder GC/KS and sent to the GM. The GM
+ will take the value received and copy it into the Notification
+ payload Notification Data field of type Cookie that is transmitted in
+ the "Request to Join with Cookie Info" back to the GC/KS. The cookie
+ value MUST NOT be modified.
+
+
+
+
+Harney, et al. Standards Track [Page 83]
+
+RFC 4535 GSAKMP June 2006
+
+
+ The format for this is already described in the discussion on cookies
+ in Section 5.2.2.
+
+7.9.1.3. Notification Data - Mechanism Choices Payload Type
+
+ The data portion of the Notification payload of type Mechanism
+ Choices contains the mechanisms the GM is requesting to use for the
+ negotiation with the GC/KS. This information will be supplied by the
+ GM in a RTJ message. Figure 24 shows the format of the Notification
+ Data - Mechanism Choices Payload Type. Multiple type|length|data
+ choices are strung together in one notification payload to allow a
+ user to transmit all relevant information within one Notification
+ Payload. The length of the payload will control the parsing of the
+ Notification Data Mechanism Choices field.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Mech Type ! Mechanism Choice Data !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+..
+
+ Figure 24: Notification Data - Mechanism Choices Payload Type Format
+
+ The Notification Data - Mechanism Choices Payload Type data fields
+ are defined as follows:
+
+ Mechanism Type (1 octet) - Specifies the type of mechanism. Table 24
+ presents the Notify Mechanism Choices Mechanism Types. This
+ field is treated as an unsigned value.
+
+ Table 24: Mechanism Types
+
+ Mechanism_Type Value Mechanism Choice
+ Data Value Table Reference
+ ___________________________________________________________________
+
+ Key Creation Algorithm 0 Table 26
+ Encryption Algorithm 1 Table 16
+ Nonce Hash Algorithm 2 Table 25
+ Reserved to IANA 3 - 192
+ Private Use 193 - 255
+
+ Mechanism Choice Data (2 octets) - The data value for the mechanism
+ type being selected. The values are specific to each Mechanism
+ Type defined. All tables necessary to define the values that are
+ not defined elsewhere (in this specification or others) are
+ defined here. This field is treated as an unsigned integer in
+ network byte order format.
+
+
+
+Harney, et al. Standards Track [Page 84]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Table 25: Nonce Hash Types
+
+ Nonce_Hash_Type Value Description
+ __________________________________________________________________
+
+ Reserved 0
+ SHA-1 1 This type MUST be supported.
+ Reserved to IANA 2 - 49152
+ Private Use 49153 - 65535
+
+7.9.1.4. Notification Data - IPv4 and IPv6 Value Payload Types
+
+ The data portion of the Notification payload of type IPv4 and IPv6
+ value contains the appropriate IP value in network byte order. This
+ value will be set by the creator of the message for consumption by
+ the receiver of the message.
+
+7.9.2. Notification Payload Processing
+
+ When processing the Notification Payload, the following fields MUST
+ be checked for correct values:
+
+ 1. Next Payload, RESERVED, Payload Length - These fields are
+ processed as defined in Section 7.2.2, "Generic Payload Header
+ Processing".
+
+ 2. Notification Type - The Notification type value MUST be checked
+ to be a notification type as defined by Table 22. If the value
+ is not valid, then an error is logged. If in Verbose Mode, an
+ appropriate message containing notification value Payload-
+ Malformed will be sent.
+
+ 3. Notification Data - This Notification Data MUST be processed
+ according to the notification type specified. The type will
+ define the format of the data. When processing this data, any
+ type field MUST be checked against the appropriate table for
+ correct values. If the contents of the Notification Data are not
+ valid, then an error is logged. If in Verbose Mode, an
+ appropriate message containing notification value Payload-
+ Malformed will be sent.
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 85]
+
+RFC 4535 GSAKMP June 2006
+
+
+7.10. Vendor ID Payload
+
+7.10.1. Vendor ID Payload Structure
+
+ The Vendor ID Payload contains a vendor-defined constant. The
+ constant is used by vendors to identify and recognize remote
+ instances of their implementations. This mechanism allows a
+ vendor to experiment with new features while maintaining
+ backwards compatibility. Figure 25 shows the format of the
+ payload.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Vendor ID (VID) ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 25: Vendor ID Payload Format
+
+ A Vendor ID payload MAY announce that the sender is capable of
+ accepting certain extensions to the protocol, or it MAY simply
+ identify the implementation as an aid in debugging. A Vendor ID
+ payload MUST NOT change the interpretation of any information defined
+ in this specification. Multiple Vendor ID payloads MAY be sent. An
+ implementation is NOT REQUIRED to send any Vendor ID payload at all.
+
+ A Vendor ID payload may be sent as part of any message. Receipt of a
+ familiar Vendor ID payload allows an implementation to make use of
+ Private Use numbers described throughout this specification --
+ private payloads, private exchanges, private notifications, etc.
+ This implies that all the processing rules defined for all the
+ payloads are now modified to recognize all values defined by this
+ Vendor ID for all fields of all payloads. Unfamiliar Vendor IDs MUST
+ be ignored.
+
+ Writers of Internet-Drafts who wish to extend this protocol MUST
+ define a Vendor ID payload to announce the ability to implement the
+ extension in the Internet-Draft. It is expected that Internet-Drafts
+ that gain acceptance and are standardized will be given assigned
+ values out of the Reserved to IANA range, and the requirement to use
+ a Vendor ID payload will go away.
+
+ The Vendor ID payload fields are defined as follows:
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 86]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+ Vendor ID (variable length) - The Vendor ID value. The minimum
+ length for this field is four (4) octets. It is the
+ responsibility of the person choosing the Vendor ID to assure its
+ uniqueness in spite of the absence of any central registry for
+ IDs. Good practice is to include a company name, a person name,
+ or similar type data. A message digest of a long unique string
+ is preferable to the long unique string itself.
+
+ The payload type for the Vendor ID Payload is ten (10).
+
+7.10.2. Vendor ID Payload Processing
+
+ When processing the Vendor ID Payload, the following fields MUST be
+ checked for correct values:
+
+ 1. Next Payload, RESERVED, Payload Length - These fields are
+ processed as defined in Section 7.2.2, "Generic Payload Header
+ Processing".
+
+ 2. Vendor ID - The Vendor ID Data MUST be processed to determine if
+ the Vendor ID value is recognized by the implementation. If the
+ Vendor ID value is not recognized, then regardless of mode (e.g.,
+ Terse or Verbose) this information is logged. Processing of the
+ message MUST continue regardless of recognition of this value.
+
+ It is recommended that implementations that want to use Vendor-ID-
+ specific information attempt to process the Vendor ID payloads of an
+ incoming message prior to the remainder of the message processing.
+ This will allow the implementation to recognize that when processing
+ other payloads it can use the larger set of values for payload fields
+ (Private Use values, etc.) as defined by the recognized Vendor IDs.
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 87]
+
+RFC 4535 GSAKMP June 2006
+
+
+7.11. Key Creation Payload
+
+7.11.1. Key Creation Payload Structure
+
+ The Key Creation Payload contains information used to create key
+ encryption keys. The security attributes for this payload are
+ provided in the Policy Token. Figure 26 shows the format of the
+ payload.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Key Creation Type ! Key Creation Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 26: Key Creation Payload Format
+
+ The Key Creation Payload fields are defined as follows:
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+ Key Creation Type (2 octets) - Specifies the type of Key Creation
+ being used. Table 26 identifies the types of key creation
+ information. This field is treated as an unsigned integer in
+ network byte order format.
+
+ Key Creation Data (variable length) - Contains Key Creation
+ information. The values for this field are group specific, and
+ the format is specified by the key creation type field.
+
+ The payload type for the Key Creation Packet is eleven (11).
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 88]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Table 26: Types of Key Creation Information
+
+ Key Creation Type Value Definition/Defined In
+ _____________________________________________________________________
+
+ Reserved 0 - 1
+ Diffie-Hellman 2 This type MUST be supported.
+ 1024-bit MODP Group Defined in [IKEv2] B.2.
+ Truncated If the output of the process
+ is longer than needed for
+ the defined mechanism, use
+ the first X low order bits
+ and truncate the remainder.
+ Reserved 3 - 13
+ Diffie-Hellman 14 Defined in [RFC3526].
+ 2048-bit MODP Group If the output of the process
+ Truncated is longer than needed for
+ the defined mechanism, use
+ the first X low order bits
+ and truncate the remainder.
+ Reserved to IANA 15 - 49152
+ Private Use 49153 - 65535
+
+7.11.2. Key Creation Payload Processing
+
+ The specifics of the Key Creation Payload are defined in Section
+ 7.11.
+
+ When processing the Key Creation Payload, the following fields MUST
+ be checked for correct values:
+
+ 1. Next Payload, RESERVED, Payload Length - These fields are
+ processed as defined in Section 7.2.2, "Generic Payload Header
+ Processing".
+
+ 2. Key Creation Type - The Key Creation Type value MUST be checked
+ to be a valid key creation type as defined by Table 26. If the
+ value is not valid, then an error is logged. If in Verbose Mode,
+ an appropriate message containing notification value Payload-
+ Malformed will be sent.
+
+ 3. Key Creation Data - This Key Creation Data MUST be processed
+ according to the key creation type specified to generate the KEK
+ to protect the information to be sent in the appropriate message.
+ The type will define the format of the data.
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 89]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Implementations that want to derive other keys from the initial Key
+ Creation keying material (for example, DH Secret keying material)
+ MUST define a Key Creation Type other than one of those shown in
+ Table 26. The new Key Creation Type must specify that derivation's
+ algorithm, for which the KEK MAY be one of the keys derived.
+
+7.12. Nonce Payload
+
+7.12.1. Nonce Payload Structure
+
+ The Nonce Payload contains random data used to guarantee freshness
+ during an exchange and protect against replay attacks. Figure 27
+ shows the format of the Nonce Payload.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Next Payload ! RESERVED ! Payload Length !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! Nonce Type ! Nonce Data ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 27: Nonce Payload Format
+
+ The Nonce Payload fields are defined as follows:
+
+ Next Payload (1 octet) - Identifier for the payload type of the next
+ payload in the message. If the current payload is the last in
+ the message, then this field will be 0. This field provides the
+ "chaining" capability. Table 12 identifies the payload types.
+ This field is treated as an unsigned value.
+
+ RESERVED (1 octet) - Unused, set to 0.
+
+ Payload Length (2 octets) - Length in octets of the current payload,
+ including the generic payload header. This field is treated as
+ an unsigned integer in network byte order format.
+
+ Nonce Type (1 octet) - Specifies the type of nonce being used. Table
+ 27 identifies the types of nonces. This field is treated as an
+ unsigned value.
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 90]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Table 27: Nonce Types
+
+ Nonce_Type Value Definition
+ _____________________________________________________________________
+
+ None 0
+ Initiator (Nonce_I) 1
+ Responder (Nonce_R) 2
+ Combined (Nonce_C) 3 Hash (Append
+ (Initiator_Value,Responder_Value))
+ The hash type comes from the
+ Policy (e.g., Security Suite
+ Definition of Policy Token).
+ Reserved to IANA 4 - 192
+ Private Use 192 - 255
+
+ Nonce Data (variable length) - Contains the nonce information. The
+ values for this field are group specific, and the format is
+ specified by the Nonce Type field. If no group-specific
+ information is provided, the minimum length for this field is 4
+ bytes.
+
+ The payload type for the Nonce Payload is twelve (12).
+
+7.12.2. Nonce Payload Processing
+
+ When processing the Nonce Payload, the following fields MUST be
+ checked for correct values:
+
+ 1. Next Payload, RESERVED, Payload Length - These fields are
+ processed as defined in Section 7.2.2, "Generic Payload Header
+ Processing".
+
+ 2. Nonce Type - The Nonce Type value MUST be checked to be a valid
+ nonce type as defined by Table 27. If the value is not valid,
+ then an error is logged. If in Verbose Mode, an appropriate
+ message containing notification value Payload-Malformed will be
+ sent.
+
+ 3. Nonce Data - This is the nonce data and it must be checked
+ according to its content. The size of this field is defined in
+ Section 7.12, "Nonce Payload". Refer to Section 5.2, "Group
+ Establishment", for interpretation of this field.
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 91]
+
+RFC 4535 GSAKMP June 2006
+
+
+8. GSAKMP State Diagram
+
+ Figure 28 presents the states encountered in the use of this
+ protocol. Table 28 defines the states. Table 29 defines the
+ transitions.
+
+ !-----------------> ( )
+ ! !-------------> ( Idle ) <------------------!
+ ! ! ( ) !
+ ! ! ! ! !
+ ! ! ! ! !
+ ! ! (1a) (1) !
+ ! ! ! ! !
+ ! ! ! ! !
+ ! ! V V !
+ ! !---(5a)--- (Wait for ) (Wait for ) ----(5)-----!
+ ! (Group ) (GC/KS Event) <---
+ ! (Membership) ^ ! \ \
+ ! ! ! ! \ \
+ ! ! ! ! \--(2)---\
+ ! (2a) (4)(3)
+ ! ! ! !
+ ! ! ! !
+ ! V ! V
+ !-------(4a)--- (Wait for ) (Wait for )
+ (Group ) (Response )
+ (Membership) (from Key )
+ /--> (Event ) (Download )
+ / /
+ / /
+ /--(3a)---/
+
+
+ Figure 28: GSAKMP State Diagram
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 92]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Table 28: GSAKMP States
+ ______________________________________________________________________
+
+ Idle : GSAKMP Application waiting for input
+ ______________________________________________________________________
+
+ Wait for GC/KS Event : GC/KS up and running, waiting for events
+ ______________________________________________________________________
+
+ Wait for Response : GC/KS has sent Key Download,
+ from Key Download : waiting for response from GM
+ ______________________________________________________________________
+
+ Wait for Group : GM in process of joining group
+ Membership :
+ ______________________________________________________________________
+
+ Wait for Group : GM has group key, waiting for
+ Membership Event : group management messages.
+ ______________________________________________________________________
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 93]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Table 29: State Transition Events
+ ____________________________________________________________________
+
+ Transition 1 : Create group command
+ ______________:_____________________________________________________
+ :
+ Transition 2 : Receive bad RTJ
+ : Receive valid command to change group membership
+ : Send Compromise message x times
+ : Member Deregistration
+ ______________:_____________________________________________________
+ :
+ Transition 3 : Receive valid RTJ
+ ______________:_____________________________________________________
+ :
+ Transition 4 : Timeout
+ : Receive Ack
+ : Receive Nack
+ ______________:_____________________________________________________
+ :
+ Transition 5 : Delete group command
+ ______________:_____________________________________________________
+ :
+ Transition 1a : Join group command
+ ______________:_____________________________________________________
+ :
+ Transition 2a : Send Ack
+ ______________:_____________________________________________________
+ :
+ Transition 3a : Receipt of group management messages
+ ______________:_____________________________________________________
+ :
+ Transition 4a : Delete group command
+ : Deregistration command
+ ______________:_____________________________________________________
+ :
+ Transition 5a : Time out
+ : Msg failure
+ : errors
+ :
+ ____________________________________________________________________
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 94]
+
+RFC 4535 GSAKMP June 2006
+
+
+9. IANA Considerations
+
+9.1. IANA Port Number Assignment
+
+ IANA has provided GSAKMP port number 3761 in both the UDP and TCP
+ spaces. All implementations MUST use this port assignment in the
+ appropriate manner.
+
+9.2. Initial IANA Registry Contents
+
+ The following registry entries have been created:
+
+ GSAKMP Group Identification Types (Section 7.1.1)
+ GSAKMP Payload Types (Section 7.1.1)
+ GSAKMP Exchange Types (Section 7.1.1)
+ GSAKMP Policy Token Types (Section 7.3.1)
+ GSAKMP Key Download Data Item Types (Section 7.4.1)
+ GSAKMP Cryptographic Key Types (Section 7.4.1.1)
+ GSAKMP Rekey Event Types (Section 7.5.1)
+ GSAKMP Identification Classification (Section 7.6.1)
+ GSAKMP Identification Types (Section 7.6.1)
+ GSAKMP Certificate Types (Section 7.7.1)
+ GSAKMP Signature Types (Section 7.8.1)
+ GSAKMP Notification Types (Section 7.9.1)
+ GSAKMP Acknowledgement Types (Section 7.9.1.1)
+ GSAKMP Mechanism Types (Section 7.9.1.3)
+ GSAKMP Nonce Hash Types (Section 7.9.1.3)
+ GSAKMP Key Creation Types (Section 7.11.1)
+ GSAKMP Nonce Types (Section 7.12.1)
+
+ Changes and additions to the following registries are by IETF
+ Standards Action:
+
+ GSAKMP Group Identification Types
+ GSAKMP Payload Types
+ GSAKMP Exchange Types
+ GSAKMP Policy Token Types
+ GSAKMP Key Download Data Item Types
+ GSAKMP Rekey Event Types
+ GSAKMP Identification Classification
+ GSAKMP Notification Types
+ GSAKMP Acknowledgement Types
+ GSAKMP Mechanism Types
+ GSAKMP Nonce Types
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 95]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Changes and additions to the following registries are by Expert
+ Review:
+
+ GSAKMP Cryptographic Key Types
+ GSAKMP Identification Types
+ GSAKMP Certificate Types
+ GSAKMP Signature Types
+ GSAKMP Nonce Hash Types
+ GSAKMP Key Creation Types
+
+10. Acknowledgements
+
+ This document is the collaborative effort of many individuals. If
+ there were no limit to the number of authors that could appear on an
+ RFC, the following, in alphabetical order, would have been listed:
+ Haitham S. Cruickshank of University of Surrey, Sunil Iyengar of
+ University Of Surrey Gavin Kenny of LogicaCMG, Patrick McDaniel of
+ AT&T Labs Research, and Angela Schuett of NSA.
+
+ The following individuals deserve recognition and thanks for their
+ contributions, which have greatly improved this protocol: Eric Harder
+ is an author to the Tunneled-GSAKMP, whose concepts are found in
+ GSAKMP as well. Rod Fleischer, also a Tunneled-GSAKMP author, and
+ Peter Lough were both instrumental in coding a prototype of the
+ GSAKMP software and helped define many areas of the protocol that
+ were vague at best. Andrew McFarland and Gregory Bergren provided
+ critical analysis of early versions of the specification. Ran
+ Canetti analyzed the security of the protocol and provided denial of
+ service suggestions leading to optional "cookie protection".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 96]
+
+RFC 4535 GSAKMP June 2006
+
+
+11. References
+
+11.1. Normative References
+
+ [DH77] Diffie, W., and M. Hellman, "New Directions in
+ Cryptography", IEEE Transactions on Information Theory,
+ June 1977.
+
+ [FIPS186-2] NIST, "Digital Signature Standard", FIPS PUB 186-2,
+ National Institute of Standards and Technology, U.S.
+ Department of Commerce, January 2000.
+
+ [FIPS196] "Entity Authentication Using Public Key Cryptography,"
+ Federal Information Processing Standards Publication 196,
+ NIST, February 1997.
+
+ [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
+ RFC 4306, December 2005.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
+ (IKE)", RFC 2409, November 1998.
+
+ [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
+ 2412, November 1998.
+
+ [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for
+ Multicast: Issues and Architectures", RFC 2627, June
+ 1999.
+
+ [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
+ X.509 Public Key Infrastructure Certificate and
+ Certificate Revocation List (CRL) Profile", RFC 3280,
+ April 2002.
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 2003.
+
+ [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol
+ (LDAP): String Representation of Distinguished Names",
+ RFC 4514, June 2006.
+
+ [RFC4534] Colegrove, A. and H. Harney, "Group Security Policy Token
+ v1", RFC 4534, June 2006.
+
+
+
+
+
+Harney, et al. Standards Track [Page 97]
+
+RFC 4535 GSAKMP June 2006
+
+
+11.2. Informative References
+
+ [BMS] Balenson, D., McGrew, D., and A. Sherman, "Key Management
+ for Large Dynamic Groups: One-Way Function Trees and
+ Amortized Initialization", Work in Progress, February
+ 1999.
+
+ [HCM] H. Harney, A. Colegrove, P. McDaniel, "Principles of
+ Policy in Secure Groups", Proceedings of Network and
+ Distributed Systems Security 2001 Internet Society, San
+ Diego, CA, February 2001.
+
+ [HHMCD01] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A.,
+ and P. Dinsmore, "Group Security Policy Token:
+ Definition and Payloads", Work in Progress, August 2003.
+
+ [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management
+ Protocol (GKMP) Specification", RFC 2093, July 1997.
+
+ [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management
+ Protocol (GKMP) Architecture", RFC 2094, July 1997.
+
+ [RFC2408] Maughan D., Schertler M., Schneider M., and Turner J.,
+ "Internet Security Association and Key Management
+ Protocol (ISAKMP)", RFC 2408, Proposed Standard, November
+ 1998
+
+ [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
+ Algorithms", RFC 2451, November 1998.
+
+ [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key
+ Management Protocol", RFC 2522, March 1999.
+
+ [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol
+ (LDAP) Schema Definitions for X.509 Certificates", RFC
+ 4523, June 2006.
+
+ [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
+ Announcement Protocol", RFC 2974, October 2000.
+
+ [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
+ "Internet X.509 Public Key Infrastructure Time-Stamp
+ Protocol (TSP)", RFC 3161, August 2001.
+
+ [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+ A., Peterson, J., Sparks, R., Handley, M., and E.
+ Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+ June 2002.
+
+
+
+Harney, et al. Standards Track [Page 98]
+
+RFC 4535 GSAKMP June 2006
+
+
+ [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
+ Standards (PKCS) #1: RSA Cryptography Specifications
+ Version 2.1", RFC 3447, February 2003.
+
+ [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP)
+ Diffie-Hellman groups for Internet Key Exchange (IKE)",
+ RFC 3526, May 2003.
+
+ [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
+ Architecture", RFC 3740, March 2004.
+
+ [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+ "Randomness Requirements for Security", BCP 106, RFC
+ 4086, June 2005.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 99]
+
+RFC 4535 GSAKMP June 2006
+
+
+Appendix A. LKH Information
+
+ This appendix will give an overview of LKH, define the values for
+ fields within GSAKMP messages that are specific to LKH, and give an
+ example of a Rekey Event Message using the LKH scheme.
+
+A.1. LKH Overview
+
+ LKH provides a topology for handling key distribution for a group
+ rekey. It rekeys a group based upon a tree structure and subgroup
+ keys. In the LKH tree shown in Figure 29, members are represented by
+ the leaf nodes on the tree, while intermediate tree nodes represent
+ abstract key groups. A member will possess multiple keys: the group
+ traffic protection key (GTPK), subgroup keys for every node on its
+ path to the root of the tree, and a personal key. For example, the
+ member labeled as #3 will have the GTPK, Key A, Key D, and Key 3.
+
+ root
+ / \
+ / \
+ A B
+ / \ / \
+ / \ / \
+ C D E F
+ / \ / \ / \ / \
+ / \ / \ / \ / \
+ 1 2 3 4 5 6 7 8
+
+
+ Figure 29: LKH Tree
+
+ This keying topology provides for a rapid rekey to all but a
+ compromised member of the group. If Member 3 were compromised, the
+ new GTPK (GTPK') would need to be distributed to the group under a
+ key not possessed by Member 3. Additionally, new Keys A and D (Key
+ A' and Key D') would also need to be securely distributed to the
+ other members of those subtrees. Encrypting the GTPK' with Key B
+ would securely distribute that key to Members 5, 6, 7, and 8. Key C
+ can be used to encrypt both the GTPK' and Key A' for Members 1 and 2.
+ Member 3's nearest neighbor, Member 4, can obtain GTPK', Key D', and
+ Key A' encrypted under its personal key, Key 4. At the end of this
+ process, the group is securely rekeyed with Member 3 fully excluded.
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 100]
+
+RFC 4535 GSAKMP June 2006
+
+
+A.2. LKH and GSAKMP
+
+ When using LKH with GSAKMP, the following issues require attention:
+
+ 1. Rekey Version # - The Rekey Version # in the Rekey Array of the
+ Key Download Payload MUST contain the value one (1).
+
+ 2. Algorithm Version - The Algorithm Version in the Rekey Event
+ Payload MUST contain the value one (1).
+
+ 3. Degree of Tree - The LKH tree used can be of any degree; it need
+ not be binary.
+
+ 4. Node Identification - Each node in the tree is treated as a KEK.
+ A KEK is just a special key. As the rule stated for all keys in
+ GSAKMP, the set of the KeyID and the KeyHandle MUST be unique. A
+ suggestion on how to do this will be given in this section.
+
+ 5. Wrapping KeyID and Handle - This is the KeyID and Handle of the
+ LKH node used to wrap/encrypt the data in a Rekey Event Data.
+
+ For the following discussion, refer to Figure 30.
+
+ Key:
+ o: a node in the LKH tree
+ N: this line contains the KeyID node number
+ L: this line contains the MemberID number for all leaves ONLY
+
+ LEVEL
+ ----
+ root o
+ N: / 1 \
+ / \
+ 1 o o
+ N: / 2 \ / 3 \
+ / \ / \
+ 2 o o o o
+ N: /4\ /5\ /6\ /7\
+ / \ / \ / \ / \
+ 3 o o o o o o o o
+ N: 8 9 10 11 12 13 14 15
+ L: 1 2 3 4 5 6 7 8
+
+ Figure 30: GSAKMP LKH Tree
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 101]
+
+RFC 4535 GSAKMP June 2006
+
+
+ To guarantee uniqueness of KeyID, the Rekey Controller SHOULD build a
+ virtual tree and label the KeyID of each node, doing a breadth-first
+ search of a fully populated tree regardless of whether or not the
+ tree is actually full. For simplicity of this example, the root of
+ the tree was given KeyID value of one (1). These KeyID values will
+ be static throughout the life of this tree. Additionally, the rekey
+ arrays distributed to GMs requires a MemberID value associated with
+ them to be distributed with the KeyDownload Payload. These MemberID
+ values MUST be unique. Therefore, the set associated with each leaf
+ node (the nodes from that leaf back to the root) are given a
+ MemberID. In this example, the leftmost leaf node is given MemberID
+ value of one (1). These 2 sets of values, the KeyIDs (represented on
+ lines N) and the MemberIDs (represented on line L), will give
+ sufficient information in the KeyDownload and RekeyEvent Payloads to
+ disseminate information. The KeyHandle associated with these keys is
+ regenerated each time the key is replaced in the tree due to
+ compromise.
+
+A.3. LKH Examples
+
+ Definition of values:
+ 0xLLLL - length value
+ 0xHHHHHHH# - handle value
+ YYYYMMDDHHMMSSZ - time value
+
+A.3.1. LKH Key Download Example
+
+ This section will give an example of the data for the Key Download
+ payload. The GM will be given MemberID 1 and its associated keys.
+ The data shown will be subsequent to the Generic Payload Header.
+
+ | GTPK | MemberID 1 | KeyID 2 | KeyID 4 | KeyID 8
+
+ Number of Items - 0x0002
+ Item #1:
+ Key Download Data Item Type - 0x00 (GTPK)
+ Key Download Data Item Length - 0xLLLL
+ Key Type - 0x03 (3DES`CBC64`192)
+ Key ID - KEY1
+ Key Handle - 0xHHHHHHH0
+ Key Creation Date - YYYYMMDDHHMMSSZ
+ Key Expiration Date - YYYYMMDDHHMMSSZ
+ Key Data - variable, based on key definition
+ Item #2:
+ Key Download Data Item Type - 0x01 (Rekey - LKH)
+ Key Download Data Item Length - 0xLLLL
+ Rekey Version Number - 0x01
+ Member ID - 0x00000001
+
+
+
+Harney, et al. Standards Track [Page 102]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Number of KEK Keys - 0x0003
+ KEK #1:
+ Key Type - 0x03 (3DES`CBC64`192)
+ Key ID - 0x00000002
+ Key Handle - 0xHHHHHHH2
+ Key Creation Date - YYYYMMDDHHMMSSZ
+ Key Expiration Date - YYYYMMDDHHMMSSZ
+ Key Data - variable, based on key definition
+ KEK #2:
+ Key Type - 0x03 (3DES`CBC64`192)
+ Key ID - 0x00000004
+ Key Handle - 0xHHHHHHH4
+ Key Creation Date - YYYYMMDDHHMMSSZ
+ Key Expiration Date - YYYYMMDDHHMMSSZ
+ Key Data - variable, based on key definition
+ KEK #3:
+ Key Type - 0x03 (3DES`CBC64`192)
+ Key ID - 0x00000008
+ Key Handle - 0xHHHHHHH8
+ Key Creation Date - YYYYMMDDHHMMSSZ
+ Key Expiration Date - YYYYMMDDHHMMSSZ
+ Key Data - variable, based on key definition
+
+A.3.2. LKH Rekey Event Example
+
+ This section will give an example of the data for the Rekey Event
+ payload. The GM with MemberID 6 will be keyed out of the group. The
+ data shown will be subsequent to the Generic Payload Header.
+
+ | Rekey Event Type | GroupID | Date/Time | Rekey Type |
+ Algorithm Ver | # of Packets |
+ { (GTPK)2, (GTPK, 3', 6')12, (GTPK, 3')7 }
+
+ This data shows that three packets are being transmitted. Read each
+ packet as:
+
+ a) GTPK wrapped in LKH KeyID 2
+ b) GTPK, LKH KeyIDs 3' & 6', all wrapped in LKH KeyID 12
+ c) GTPK and LKH KeyID 3', all wrapped in LKH KeyID 7
+
+ NOTE: Although in this example multiple keys are encrypted under one
+ key, alternative pairings are legal (e.g., (GTPK)2, (GTPK)3', (3')6',
+ (3')7', (6')12).
+
+ We will show the format for all header data and packet (b).
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 103]
+
+RFC 4535 GSAKMP June 2006
+
+
+ Rekey Event Type - 0x01 (GSAKMP`LKH)
+ GroupID - 0xAABBCCDD
+ 0x12345678
+ Time/Date Stamp - YYYYMMDDHHMMSSZ
+ Rekey Event Type - 0x01 (GSAKMP`LKH)
+ Algorithm Vers - 0x01
+ # of RkyEvt Pkts - 0x0003
+ For Packet (b):
+ Packet Length - 0xLLLL
+ Wrapping KeyID - 0x000C
+ Wrapping Key Handle - 0xHHHHHHHD
+ # of Key Packages - 0x0003
+ Key Package 1:
+ Key Pkg Type - 0x00 (GTPK)
+ Pack Length - 0xLLLL
+ Key Type - 0x03 (3DES`CBC64`192)
+ Key ID - KEY1
+ Key Handle - 0xHHHHHHH0
+ Key Creation Date - YYYYMMDDHHMMSSZ
+ Key Expiration Date - YYYYMMDDHHMMSSZ
+ Key Data - variable, based on key definition
+ Key Package 2:
+ Key Pkg Type - 0x01 (Rekey - LKH)
+ Pack Length - 0xLLLL
+ Key Type - 0x03 (3DES`CBC64`192)
+ Key ID - 0x00000003
+ Key Handle - 0xHHHHHHH3
+ Key Creation Date - YYYYMMDDHHMMSSZ
+ Key Expiration Date - YYYYMMDDHHMMSSZ
+ Key Data - variable, based on key definition
+ Key Package 3:
+ Key Pkg Type - 0x01 (Rekey - LKH)
+ Pack Length - 0xLLLL
+ Key Type - 0x03 (3DES`CBC64`192)
+ Key ID - 0x00000006
+ Key Handle - 0xHHHHHHH6
+ Key Creation Date - YYYYMMDDHHMMSSZ
+ Key Expiration Date - YYYYMMDDHHMMSSZ
+ Key Data - variable, based on key definition
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 104]
+
+RFC 4535 GSAKMP June 2006
+
+
+Authors' Addresses
+
+ Hugh Harney (point-of-contact)
+ SPARTA, Inc.
+ 7110 Samuel Morse Drive
+ Columbia, MD 21046
+
+ Phone: (443) 430-8032
+ Fax: (443) 430-8181
+ EMail: hh@sparta.com
+
+
+ Uri Meth
+ SPARTA, Inc.
+ 7110 Samuel Morse Drive
+ Columbia, MD 21046
+
+ Phone: (443) 430-8058
+ Fax: (443) 430-8207
+ EMail: umeth@sparta.com
+
+
+ Andrea Colegrove
+ SPARTA, Inc.
+ 7110 Samuel Morse Drive
+ Columbia, MD 21046
+
+ Phone: (443) 430-8014
+ Fax: (443) 430-8163
+ EMail: acc@sparta.com
+
+
+ George Gross
+ IdentAware Security
+ 82 Old Mountain Road
+ Lebanon, NJ 08833
+
+ Phone: (908) 268-1629
+ EMail: gmgross@identaware.com
+
+
+
+
+
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 105]
+
+RFC 4535 GSAKMP June 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Harney, et al. Standards Track [Page 106]
+