[RFCs/IDs] [Plain Text] [From draft-ietf-msec-gsakmp-sec]
PROPOSED STANDARD
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 D