From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc4535.txt | 5939 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 5939 insertions(+)
 create mode 100644 doc/rfc/rfc4535.txt

(limited to 'doc/rfc/rfc4535.txt')

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]
+
-- 
cgit v1.2.3