RFC 4535
GSAKMP: Group Secure Association Key Management Protocol
Pages: 106
Proposed Standard
Proposed Standard
Part 4 of 4 – Pages 75 to 106
7.7. Certificate Payload
7.7.1. Certificate Payload Structure
The Certificate Payload provides a means to transport certificates or other certificate-related information via GSAKMP and can appear in any GSAKMP message. Certificate payloads SHOULD be included in an exchange whenever an appropriate directory service (e.g., LDAP [RFC4523]) is not available to distribute certificates. Multiple
certificate payloads MAY be sent to enable verification of certificate chains. Conversely, zero (0) certificate payloads may be sent, and the receiving GSAKMP MUST rely on some other mechanism to retrieve certificates for verification purposes. Figure 20 shows the format of the Certificate Payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Cert Type ! Certificate Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: Certificate Payload Format The Certificate Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format. Certificate Type (2 octets) - This field indicates the type of certificate or certificate-related information contained in the Certificate Data field. Table 20 presents the types of certificate payloads. This field is treated as an unsigned integer in network byte order format. Certificate Data (variable length) - Actual encoding of certificate data. The type of certificate is indicated by the Certificate Type/Encoding field. The payload type for the Certificate Payload is six (6).
Table 20: Certificate Payload Types
Certificate_Type Value Description/
Defined In
_____________________________________________________________________
None 0
Reserved 1 - 3
X.509v3 Certificate 4 This type MUST be
-- Signature implemented.
-- DER Encoding Contains a DER
encoded X.509
certificate.
Reserved 5 - 6
Certificate Revocation List 7 Contains a BER
(CRL) encoded X.509 CRL.
Reserved 8 - 9
X.509 Certificate 10 See [IKEv2], Sec 3.6.
-- Attribute
Raw RSA Key 11 See [IKEv2], Sec 3.6.
Hash and URL of X.509 12 See [IKEv2], Sec 3.6.
Certificate
Hash and URL of X.509 13 See [IKEv2], Sec 3.6.
bundle
Reserved to IANA 14 -- 49152
Private Use 49153 -- 65535
7.7.2. Certificate Payload Processing
When processing the Certificate Payload, the following fields MUST be
checked for correct values:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
2. Certificate Type - The Certificate Type value MUST be checked to
be a valid certificate type as defined by Table 20. If the value
is not valid, then an error is logged. If in Verbose Mode, an
appropriate message containing notification value Cert-Type-
Unsupported will be sent.
3. Certificate Data - This Certificate Data MUST be processed
according to the certificate type specified. The type will
define the format of the data. Receipt of a certificate of the
trusted policy creation authority in a Certificate payload causes
the payload to be discarded. This received certificate MUST NOT
be used to verify the message. The certificate of the trusted
policy creation authority MUST be retrieved by other means.
7.8. Signature Payload
7.8.1. Signature Payload Structure
The Signature Payload contains data generated by the digital
signature function. The digital signature, as defined by the
dissection of each message, covers the message from the GSAKMP
Message Header through the Signature Payload, up to but not
including the Signature Data Length. Figure 21 shows the format
of the Signature Payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature Type ! Sig ID Type ! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Signature Timestamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! Signer ID Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signer ID Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Signature Length ! Signature Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 21: Signature Payload Format
The Signature Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next
payload in the message. If the current payload is the last in
the message, then this field will be 0. This field provides the
"chaining" capability. Table 12 identifies the payload types.
This field is treated as an unsigned value.
RESERVED (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload,
including the generic payload header. This field is treated as
an unsigned integer in network byte order format.
Signature Type (2 octets) - Indicates the type of signature. Table
21 presents the allowable signature types. This field is treated
as an unsigned integer in network byte order format.
Table 21: Signature Types
Signature Type Value Description/
Defined In
_____________________________________________________________________
DSS/SHA1 with ASN.1/DER encoding 0 This type MUST
(DSS-SHA1-ASN1-DER) be supported.
RSA1024-MD5 1 See [RFC3447].
ECDSA-P384-SHA3 2 See [FIPS186-2].
Reserved to IANA 3 - 41952
Private Use 41953 - 65536
Signature ID Type (1 octet) - Indicates the format for the Signature
ID Data. These values are the same as those defined for the
Identification Payload Identification types, which can be found
in Table 19. This field is treated as an unsigned value.
Signature Timestamp (15 octets) - This is the time value when the
digital signature was applied. This field contains the timestamp
in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 -
9999), MM is the numerical value of the month (01 - 12), DD is
the day of the month (01 - 31), HH is the hour of the day (00 -
23), MM is the minute within the hour (00 - 59), SS is the
seconds within the minute (00 - 59), and the letter Z indicates
that this is Zulu time. This format is loosely based on
[RFC3161].
Signer ID Length (2 octets) - Length in octets of the Signer's ID.
This field is treated as an unsigned integer in network byte
order format.
Signer ID Data (variable length) - Data identifying the Signer's ID
(e.g., DN). The format for this field is based on the Signature
ID Type field and is shown where that type is defined. The
contents of this field MUST be checked against the Policy Token
to determine the authority and access of the Signer within the
context of the group.
Signature Length (2 octets) - Length in octets of the Signature Data.
This field is treated as an unsigned integer in network byte
order format.
Signature Data (variable length) - Data that results from applying
the digital signature function to the GSAKMP message and/or
payload.
The payload type for the Signature Payload is eight (8).
7.8.2. Signature Payload Processing
When processing the Signature Payload, the following fields MUST be
checked for correct values:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
2. Signature Type - The Signature Type value MUST be checked to be a
valid signature type as defined by Table 21. If the value is not
valid, then an error is logged. If in Verbose Mode, an
appropriate message containing notification value Payload-
Malformed will be sent.
3. Signature ID Type - The Signature ID Type value MUST be checked
to be a valid signature ID type as defined by Table 19. If the
value is not valid, then an error is logged. If in Verbose Mode,
an appropriate message containing notification value Payload-
Malformed will be sent.
4. Signature Timestamp - This field MAY be checked to determine if
the transaction signing time is fresh relative to expected
network delays. Such a check is appropriate for systems in which
archived sequences of events are desired.
NOTE: The maximum acceptable age of a signature timestamp
relative to the local system clock is a locally configured
parameter that can be tuned by its GSAKMP management interface.
5. Signature ID Data - This field will be used to identify the
sending party. This information MUST then be used to confirm
that the correct party sent this information. This field is also
used to retrieve the appropriate public key of the certificate to
verify the message.
6. Signature Data - This value MUST be compared to the recomputed
signature to verify the message. Information on how to verify
certificates used to ascertain the validity of the signature can
be found in [RFC3280]. Only after the certificate identified by
the Signature ID Data is verified can the signature be computed
to compare to the signature data for signature verification. A
potential error that can occur during signature verification is
Authentication-Failed. Potential errors that can occur while
processing certificates for signature verification are: Invalid-
Certificate, Invalid-Cert-Authority, Cert-Type-Unsupported, and
Certificate-Unavailable.
The length fields in the Signature Payload are used to process the
remainder of the payload. If any field is found to be incorrect,
then termination processing MUST be initiated.
7.9. Notification Payload
7.9.1. Notification Payload Structure
The Notification Payload can contain both GSAKMP and group-specific
data and is used to transmit informational data, such as error
conditions, to a GSAKMP peer. It is possible to send multiple
independent Notification payloads in a single GSAKMP message. Figure
22 shows the format of the Notification Payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Notification Type ! Notification Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 22: Notification Payload Format
The Notification Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next
payload in the message. If the current payload is the last in
the message, then this field will be 0. This field provides the
"chaining" capability. Table 12 identifies the payload types.
This field is treated as an unsigned value.
RESERVED (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload,
including the generic payload header. This field is treated as
an unsigned integer in network byte order format.
Notification Type (2 octets) - Specifies the type of notification
message. Table 22 presents the Notify Payload Types. This field
is treated as an unsigned integer in network byte order format.
Notification Data (variable length) - Informational or error data
transmitted in addition to the Notify Payload Type. Values for
this field are Domain of Interpretation (DOI) specific.
The payload type for the Notification Payload is nine (9).
Table 22: Notification Types
Notification Type Value
__________________________________________________________
None 0
Invalid-Payload-Type 1
Reserved 2 - 3
Invalid-Version 4
Invalid-Group-ID 5
Invalid-Sequence-ID 6
Payload-Malformed 7
Invalid-Key-Information 8
Invalid-ID-Information 9
Reserved 10 - 11
Cert-Type-Unsupported 12
Invalid-Cert-Authority 13
Authentication-Failed 14
Reserved 15 - 16
Certificate-Unavailable 17
Reserved 18
Unauthorized-Request 19
Reserved 20 - 22
Acknowledgement 23
Reserved 24 - 25
Nack 26
Cookie-Required 27
Cookie 28
Mechanism Choices 29
Leave Group 30
Departure Accepted 31
Request to Depart Error 32
Invalid Exchange Type 33
IPv4 Value 34
IPv6 Value 35 Prohibited by Group Policy 36 Prohibited by Locally Configured Policy 37 Reserved to IANA 38 - 49152 Private Use 49153 -- 655357.9.1.1. Notification Data - Acknowledgement (ACK) Payload Type
The data portion of the Notification payload of type ACK either serves as confirmation of correct receipt of the Key Download message or, when needed, provides other receipt information when included in a signed message. Figure 23 shows the format of the Notification Data - Acknowledge Payload Type. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Ack Type ! Acknowledgement Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 23: Notification Data - Acknowledge Payload Type Format The Notification Data - Acknowledgement Payload Type data fields are defined as follows: Ack Type (1 octet) - Specifies the type of acknowledgement. Table 23 presents the Notify Acknowledgement Payload Types. This field is treated as an unsigned value. Table 23: Acknowledgement Types ACK_Type Value Definition _____________________________________________________ Simple 0 Data portion null. Reserved to IANA 1 - 192 Private Use 193 - 2557.9.1.2. Notification Data - Cookie_Required and Cookie Payload Type
The data portion of the Notification payload of types Cookie_Required and Cookie contain the Cookie value. The value for this field will have been computed by the responder GC/KS and sent to the GM. The GM will take the value received and copy it into the Notification payload Notification Data field of type Cookie that is transmitted in the "Request to Join with Cookie Info" back to the GC/KS. The cookie value MUST NOT be modified.
The format for this is already described in the discussion on cookies in Section 5.2.2.7.9.1.3. Notification Data - Mechanism Choices Payload Type
The data portion of the Notification payload of type Mechanism Choices contains the mechanisms the GM is requesting to use for the negotiation with the GC/KS. This information will be supplied by the GM in a RTJ message. Figure 24 shows the format of the Notification Data - Mechanism Choices Payload Type. Multiple type|length|data choices are strung together in one notification payload to allow a user to transmit all relevant information within one Notification Payload. The length of the payload will control the parsing of the Notification Data Mechanism Choices field. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Mech Type ! Mechanism Choice Data ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+.. Figure 24: Notification Data - Mechanism Choices Payload Type Format The Notification Data - Mechanism Choices Payload Type data fields are defined as follows: Mechanism Type (1 octet) - Specifies the type of mechanism. Table 24 presents the Notify Mechanism Choices Mechanism Types. This field is treated as an unsigned value. Table 24: Mechanism Types Mechanism_Type Value Mechanism Choice Data Value Table Reference ___________________________________________________________________ Key Creation Algorithm 0 Table 26 Encryption Algorithm 1 Table 16 Nonce Hash Algorithm 2 Table 25 Reserved to IANA 3 - 192 Private Use 193 - 255 Mechanism Choice Data (2 octets) - The data value for the mechanism type being selected. The values are specific to each Mechanism Type defined. All tables necessary to define the values that are not defined elsewhere (in this specification or others) are defined here. This field is treated as an unsigned integer in network byte order format.
Table 25: Nonce Hash Types
Nonce_Hash_Type Value Description
__________________________________________________________________
Reserved 0
SHA-1 1 This type MUST be supported.
Reserved to IANA 2 - 49152
Private Use 49153 - 65535
7.9.1.4. Notification Data - IPv4 and IPv6 Value Payload Types
The data portion of the Notification payload of type IPv4 and IPv6
value contains the appropriate IP value in network byte order. This
value will be set by the creator of the message for consumption by
the receiver of the message.
7.9.2. Notification Payload Processing
When processing the Notification Payload, the following fields MUST
be checked for correct values:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
2. Notification Type - The Notification type value MUST be checked
to be a notification type as defined by Table 22. If the value
is not valid, then an error is logged. If in Verbose Mode, an
appropriate message containing notification value Payload-
Malformed will be sent.
3. Notification Data - This Notification Data MUST be processed
according to the notification type specified. The type will
define the format of the data. When processing this data, any
type field MUST be checked against the appropriate table for
correct values. If the contents of the Notification Data are not
valid, then an error is logged. If in Verbose Mode, an
appropriate message containing notification value Payload-
Malformed will be sent.
7.10. Vendor ID Payload
7.10.1. Vendor ID Payload Structure
The Vendor ID Payload contains a vendor-defined constant. The constant is used by vendors to identify and recognize remote instances of their implementations. This mechanism allows a vendor to experiment with new features while maintaining backwards compatibility. Figure 25 shows the format of the payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Vendor ID (VID) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 25: Vendor ID Payload Format A Vendor ID payload MAY announce that the sender is capable of accepting certain extensions to the protocol, or it MAY simply identify the implementation as an aid in debugging. A Vendor ID payload MUST NOT change the interpretation of any information defined in this specification. Multiple Vendor ID payloads MAY be sent. An implementation is NOT REQUIRED to send any Vendor ID payload at all. A Vendor ID payload may be sent as part of any message. Receipt of a familiar Vendor ID payload allows an implementation to make use of Private Use numbers described throughout this specification -- private payloads, private exchanges, private notifications, etc. This implies that all the processing rules defined for all the payloads are now modified to recognize all values defined by this Vendor ID for all fields of all payloads. Unfamiliar Vendor IDs MUST be ignored. Writers of Internet-Drafts who wish to extend this protocol MUST define a Vendor ID payload to announce the ability to implement the extension in the Internet-Draft. It is expected that Internet-Drafts that gain acceptance and are standardized will be given assigned values out of the Reserved to IANA range, and the requirement to use a Vendor ID payload will go away. The Vendor ID payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next
payload in the message. If the current payload is the last in
the message, then this field will be 0. This field provides the
"chaining" capability. Table 12 identifies the payload types.
This field is treated as an unsigned value.
RESERVED (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload,
including the generic payload header. This field is treated as
an unsigned integer in network byte order format.
Vendor ID (variable length) - The Vendor ID value. The minimum
length for this field is four (4) octets. It is the
responsibility of the person choosing the Vendor ID to assure its
uniqueness in spite of the absence of any central registry for
IDs. Good practice is to include a company name, a person name,
or similar type data. A message digest of a long unique string
is preferable to the long unique string itself.
The payload type for the Vendor ID Payload is ten (10).
7.10.2. Vendor ID Payload Processing
When processing the Vendor ID Payload, the following fields MUST be
checked for correct values:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
2. Vendor ID - The Vendor ID Data MUST be processed to determine if
the Vendor ID value is recognized by the implementation. If the
Vendor ID value is not recognized, then regardless of mode (e.g.,
Terse or Verbose) this information is logged. Processing of the
message MUST continue regardless of recognition of this value.
It is recommended that implementations that want to use Vendor-ID-
specific information attempt to process the Vendor ID payloads of an
incoming message prior to the remainder of the message processing.
This will allow the implementation to recognize that when processing
other payloads it can use the larger set of values for payload fields
(Private Use values, etc.) as defined by the recognized Vendor IDs.
7.11. Key Creation Payload
7.11.1. Key Creation Payload Structure
The Key Creation Payload contains information used to create key encryption keys. The security attributes for this payload are provided in the Policy Token. Figure 26 shows the format of the payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key Creation Type ! Key Creation Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 26: Key Creation Payload Format The Key Creation Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format. Key Creation Type (2 octets) - Specifies the type of Key Creation being used. Table 26 identifies the types of key creation information. This field is treated as an unsigned integer in network byte order format. Key Creation Data (variable length) - Contains Key Creation information. The values for this field are group specific, and the format is specified by the key creation type field. The payload type for the Key Creation Packet is eleven (11).
Table 26: Types of Key Creation Information
Key Creation Type Value Definition/Defined In
_____________________________________________________________________
Reserved 0 - 1
Diffie-Hellman 2 This type MUST be supported.
1024-bit MODP Group Defined in [IKEv2] B.2.
Truncated If the output of the process
is longer than needed for
the defined mechanism, use
the first X low order bits
and truncate the remainder.
Reserved 3 - 13
Diffie-Hellman 14 Defined in [RFC3526].
2048-bit MODP Group If the output of the process
Truncated is longer than needed for
the defined mechanism, use
the first X low order bits
and truncate the remainder.
Reserved to IANA 15 - 49152
Private Use 49153 - 65535
7.11.2. Key Creation Payload Processing
The specifics of the Key Creation Payload are defined in Section
7.11.
When processing the Key Creation Payload, the following fields MUST
be checked for correct values:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
2. Key Creation Type - The Key Creation Type value MUST be checked
to be a valid key creation type as defined by Table 26. If the
value is not valid, then an error is logged. If in Verbose Mode,
an appropriate message containing notification value Payload-
Malformed will be sent.
3. Key Creation Data - This Key Creation Data MUST be processed
according to the key creation type specified to generate the KEK
to protect the information to be sent in the appropriate message.
The type will define the format of the data.
Implementations that want to derive other keys from the initial Key Creation keying material (for example, DH Secret keying material) MUST define a Key Creation Type other than one of those shown in Table 26. The new Key Creation Type must specify that derivation's algorithm, for which the KEK MAY be one of the keys derived.7.12. Nonce Payload
7.12.1. Nonce Payload Structure
The Nonce Payload contains random data used to guarantee freshness during an exchange and protect against replay attacks. Figure 27 shows the format of the Nonce Payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Nonce Type ! Nonce Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 27: Nonce Payload Format The Nonce Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format. Nonce Type (1 octet) - Specifies the type of nonce being used. Table 27 identifies the types of nonces. This field is treated as an unsigned value.
Table 27: Nonce Types
Nonce_Type Value Definition
_____________________________________________________________________
None 0
Initiator (Nonce_I) 1
Responder (Nonce_R) 2
Combined (Nonce_C) 3 Hash (Append
(Initiator_Value,Responder_Value))
The hash type comes from the
Policy (e.g., Security Suite
Definition of Policy Token).
Reserved to IANA 4 - 192
Private Use 192 - 255
Nonce Data (variable length) - Contains the nonce information. The
values for this field are group specific, and the format is
specified by the Nonce Type field. If no group-specific
information is provided, the minimum length for this field is 4
bytes.
The payload type for the Nonce Payload is twelve (12).
7.12.2. Nonce Payload Processing
When processing the Nonce Payload, the following fields MUST be
checked for correct values:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
2. Nonce Type - The Nonce Type value MUST be checked to be a valid
nonce type as defined by Table 27. If the value is not valid,
then an error is logged. If in Verbose Mode, an appropriate
message containing notification value Payload-Malformed will be
sent.
3. Nonce Data - This is the nonce data and it must be checked
according to its content. The size of this field is defined in
Section 7.12, "Nonce Payload". Refer to Section 5.2, "Group
Establishment", for interpretation of this field.
8. GSAKMP State Diagram
Figure 28 presents the states encountered in the use of this protocol. Table 28 defines the states. Table 29 defines the transitions. !-----------------> ( ) ! !-------------> ( Idle ) <------------------! ! ! ( ) ! ! ! ! ! ! ! ! ! ! ! ! ! (1a) (1) ! ! ! ! ! ! ! ! ! ! ! ! ! V V ! ! !---(5a)--- (Wait for ) (Wait for ) ----(5)-----! ! (Group ) (GC/KS Event) <--- ! (Membership) ^ ! \ \ ! ! ! ! \ \ ! ! ! ! \--(2)---\ ! (2a) (4)(3) ! ! ! ! ! ! ! ! ! V ! V !-------(4a)--- (Wait for ) (Wait for ) (Group ) (Response ) (Membership) (from Key ) /--> (Event ) (Download ) / / / / /--(3a)---/ Figure 28: GSAKMP State Diagram
Table 28: GSAKMP States
______________________________________________________________________
Idle : GSAKMP Application waiting for input
______________________________________________________________________
Wait for GC/KS Event : GC/KS up and running, waiting for events
______________________________________________________________________
Wait for Response : GC/KS has sent Key Download,
from Key Download : waiting for response from GM
______________________________________________________________________
Wait for Group : GM in process of joining group
Membership :
______________________________________________________________________
Wait for Group : GM has group key, waiting for
Membership Event : group management messages.
______________________________________________________________________
Table 29: State Transition Events
____________________________________________________________________
Transition 1 : Create group command
______________:_____________________________________________________
:
Transition 2 : Receive bad RTJ
: Receive valid command to change group membership
: Send Compromise message x times
: Member Deregistration
______________:_____________________________________________________
:
Transition 3 : Receive valid RTJ
______________:_____________________________________________________
:
Transition 4 : Timeout
: Receive Ack
: Receive Nack
______________:_____________________________________________________
:
Transition 5 : Delete group command
______________:_____________________________________________________
:
Transition 1a : Join group command
______________:_____________________________________________________
:
Transition 2a : Send Ack
______________:_____________________________________________________
:
Transition 3a : Receipt of group management messages
______________:_____________________________________________________
:
Transition 4a : Delete group command
: Deregistration command
______________:_____________________________________________________
:
Transition 5a : Time out
: Msg failure
: errors
:
____________________________________________________________________
9. IANA Considerations
9.1. IANA Port Number Assignment
IANA has provided GSAKMP port number 3761 in both the UDP and TCP spaces. All implementations MUST use this port assignment in the appropriate manner.9.2. Initial IANA Registry Contents
The following registry entries have been created: GSAKMP Group Identification Types (Section 7.1.1) GSAKMP Payload Types (Section 7.1.1) GSAKMP Exchange Types (Section 7.1.1) GSAKMP Policy Token Types (Section 7.3.1) GSAKMP Key Download Data Item Types (Section 7.4.1) GSAKMP Cryptographic Key Types (Section 7.4.1.1) GSAKMP Rekey Event Types (Section 7.5.1) GSAKMP Identification Classification (Section 7.6.1) GSAKMP Identification Types (Section 7.6.1) GSAKMP Certificate Types (Section 7.7.1) GSAKMP Signature Types (Section 7.8.1) GSAKMP Notification Types (Section 7.9.1) GSAKMP Acknowledgement Types (Section 7.9.1.1) GSAKMP Mechanism Types (Section 7.9.1.3) GSAKMP Nonce Hash Types (Section 7.9.1.3) GSAKMP Key Creation Types (Section 7.11.1) GSAKMP Nonce Types (Section 7.12.1) Changes and additions to the following registries are by IETF Standards Action: GSAKMP Group Identification Types GSAKMP Payload Types GSAKMP Exchange Types GSAKMP Policy Token Types GSAKMP Key Download Data Item Types GSAKMP Rekey Event Types GSAKMP Identification Classification GSAKMP Notification Types GSAKMP Acknowledgement Types GSAKMP Mechanism Types GSAKMP Nonce Types
Changes and additions to the following registries are by Expert Review: GSAKMP Cryptographic Key Types GSAKMP Identification Types GSAKMP Certificate Types GSAKMP Signature Types GSAKMP Nonce Hash Types GSAKMP Key Creation Types10. Acknowledgements
This document is the collaborative effort of many individuals. If there were no limit to the number of authors that could appear on an RFC, the following, in alphabetical order, would have been listed: Haitham S. Cruickshank of University of Surrey, Sunil Iyengar of University Of Surrey Gavin Kenny of LogicaCMG, Patrick McDaniel of AT&T Labs Research, and Angela Schuett of NSA. The following individuals deserve recognition and thanks for their contributions, which have greatly improved this protocol: Eric Harder is an author to the Tunneled-GSAKMP, whose concepts are found in GSAKMP as well. Rod Fleischer, also a Tunneled-GSAKMP author, and Peter Lough were both instrumental in coding a prototype of the GSAKMP software and helped define many areas of the protocol that were vague at best. Andrew McFarland and Gregory Bergren provided critical analysis of early versions of the specification. Ran Canetti analyzed the security of the protocol and provided denial of service suggestions leading to optional "cookie protection".
11. References
11.1. Normative References
[DH77] Diffie, W., and M. Hellman, "New Directions in Cryptography", IEEE Transactions on Information Theory, June 1977. [FIPS186-2] NIST, "Digital Signature Standard", FIPS PUB 186-2, National Institute of Standards and Technology, U.S. Department of Commerce, January 2000. [FIPS196] "Entity Authentication Using Public Key Cryptography," Federal Information Processing Standards Publication 196, NIST, February 1997. [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC 2412, November 1998. [RFC2627] Wallner, D., Harder, E., and R. Agee, "Key Management for Multicast: Issues and Architectures", RFC 2627, June 1999. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006. [RFC4534] Colegrove, A. and H. Harney, "Group Security Policy Token v1", RFC 4534, June 2006.
11.2. Informative References
[BMS] Balenson, D., McGrew, D., and A. Sherman, "Key Management for Large Dynamic Groups: One-Way Function Trees and Amortized Initialization", Work in Progress, February 1999. [HCM] H. Harney, A. Colegrove, P. McDaniel, "Principles of Policy in Secure Groups", Proceedings of Network and Distributed Systems Security 2001 Internet Society, San Diego, CA, February 2001. [HHMCD01] Hardjono, T., Harney, H., McDaniel, P., Colegrove, A., and P. Dinsmore, "Group Security Policy Token: Definition and Payloads", Work in Progress, August 2003. [RFC2093] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997. [RFC2094] Harney, H. and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997. [RFC2408] Maughan D., Schertler M., Schneider M., and Turner J., "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, Proposed Standard, November 1998 [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms", RFC 2451, November 1998. [RFC2522] Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522, March 1999. [RFC4523] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Schema Definitions for X.509 Certificates", RFC 4523, June 2006. [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, August 2001. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security Architecture", RFC 3740, March 2004. [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
Appendix A. LKH Information
This appendix will give an overview of LKH, define the values for fields within GSAKMP messages that are specific to LKH, and give an example of a Rekey Event Message using the LKH scheme.A.1. LKH Overview
LKH provides a topology for handling key distribution for a group rekey. It rekeys a group based upon a tree structure and subgroup keys. In the LKH tree shown in Figure 29, members are represented by the leaf nodes on the tree, while intermediate tree nodes represent abstract key groups. A member will possess multiple keys: the group traffic protection key (GTPK), subgroup keys for every node on its path to the root of the tree, and a personal key. For example, the member labeled as #3 will have the GTPK, Key A, Key D, and Key 3. root / \ / \ A B / \ / \ / \ / \ C D E F / \ / \ / \ / \ / \ / \ / \ / \ 1 2 3 4 5 6 7 8 Figure 29: LKH Tree This keying topology provides for a rapid rekey to all but a compromised member of the group. If Member 3 were compromised, the new GTPK (GTPK') would need to be distributed to the group under a key not possessed by Member 3. Additionally, new Keys A and D (Key A' and Key D') would also need to be securely distributed to the other members of those subtrees. Encrypting the GTPK' with Key B would securely distribute that key to Members 5, 6, 7, and 8. Key C can be used to encrypt both the GTPK' and Key A' for Members 1 and 2. Member 3's nearest neighbor, Member 4, can obtain GTPK', Key D', and Key A' encrypted under its personal key, Key 4. At the end of this process, the group is securely rekeyed with Member 3 fully excluded.
A.2. LKH and GSAKMP
When using LKH with GSAKMP, the following issues require attention: 1. Rekey Version # - The Rekey Version # in the Rekey Array of the Key Download Payload MUST contain the value one (1). 2. Algorithm Version - The Algorithm Version in the Rekey Event Payload MUST contain the value one (1). 3. Degree of Tree - The LKH tree used can be of any degree; it need not be binary. 4. Node Identification - Each node in the tree is treated as a KEK. A KEK is just a special key. As the rule stated for all keys in GSAKMP, the set of the KeyID and the KeyHandle MUST be unique. A suggestion on how to do this will be given in this section. 5. Wrapping KeyID and Handle - This is the KeyID and Handle of the LKH node used to wrap/encrypt the data in a Rekey Event Data. For the following discussion, refer to Figure 30. Key: o: a node in the LKH tree N: this line contains the KeyID node number L: this line contains the MemberID number for all leaves ONLY LEVEL ---- root o N: / 1 \ / \ 1 o o N: / 2 \ / 3 \ / \ / \ 2 o o o o N: /4\ /5\ /6\ /7\ / \ / \ / \ / \ 3 o o o o o o o o N: 8 9 10 11 12 13 14 15 L: 1 2 3 4 5 6 7 8 Figure 30: GSAKMP LKH Tree
To guarantee uniqueness of KeyID, the Rekey Controller SHOULD build a virtual tree and label the KeyID of each node, doing a breadth-first search of a fully populated tree regardless of whether or not the tree is actually full. For simplicity of this example, the root of the tree was given KeyID value of one (1). These KeyID values will be static throughout the life of this tree. Additionally, the rekey arrays distributed to GMs requires a MemberID value associated with them to be distributed with the KeyDownload Payload. These MemberID values MUST be unique. Therefore, the set associated with each leaf node (the nodes from that leaf back to the root) are given a MemberID. In this example, the leftmost leaf node is given MemberID value of one (1). These 2 sets of values, the KeyIDs (represented on lines N) and the MemberIDs (represented on line L), will give sufficient information in the KeyDownload and RekeyEvent Payloads to disseminate information. The KeyHandle associated with these keys is regenerated each time the key is replaced in the tree due to compromise.A.3. LKH Examples
Definition of values: 0xLLLL - length value 0xHHHHHHH# - handle value YYYYMMDDHHMMSSZ - time valueA.3.1. LKH Key Download Example
This section will give an example of the data for the Key Download payload. The GM will be given MemberID 1 and its associated keys. The data shown will be subsequent to the Generic Payload Header. | GTPK | MemberID 1 | KeyID 2 | KeyID 4 | KeyID 8 Number of Items - 0x0002 Item #1: Key Download Data Item Type - 0x00 (GTPK) Key Download Data Item Length - 0xLLLL Key Type - 0x03 (3DES`CBC64`192) Key ID - KEY1 Key Handle - 0xHHHHHHH0 Key Creation Date - YYYYMMDDHHMMSSZ Key Expiration Date - YYYYMMDDHHMMSSZ Key Data - variable, based on key definition Item #2: Key Download Data Item Type - 0x01 (Rekey - LKH) Key Download Data Item Length - 0xLLLL Rekey Version Number - 0x01 Member ID - 0x00000001
Number of KEK Keys - 0x0003
KEK #1:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000002
Key Handle - 0xHHHHHHH2
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
KEK #2:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000004
Key Handle - 0xHHHHHHH4
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
KEK #3:
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000008
Key Handle - 0xHHHHHHH8
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
A.3.2. LKH Rekey Event Example
This section will give an example of the data for the Rekey Event
payload. The GM with MemberID 6 will be keyed out of the group. The
data shown will be subsequent to the Generic Payload Header.
| Rekey Event Type | GroupID | Date/Time | Rekey Type |
Algorithm Ver | # of Packets |
{ (GTPK)2, (GTPK, 3', 6')12, (GTPK, 3')7 }
This data shows that three packets are being transmitted. Read each
packet as:
a) GTPK wrapped in LKH KeyID 2
b) GTPK, LKH KeyIDs 3' & 6', all wrapped in LKH KeyID 12
c) GTPK and LKH KeyID 3', all wrapped in LKH KeyID 7
NOTE: Although in this example multiple keys are encrypted under one
key, alternative pairings are legal (e.g., (GTPK)2, (GTPK)3', (3')6',
(3')7', (6')12).
We will show the format for all header data and packet (b).
Rekey Event Type - 0x01 (GSAKMP`LKH)
GroupID - 0xAABBCCDD
0x12345678
Time/Date Stamp - YYYYMMDDHHMMSSZ
Rekey Event Type - 0x01 (GSAKMP`LKH)
Algorithm Vers - 0x01
# of RkyEvt Pkts - 0x0003
For Packet (b):
Packet Length - 0xLLLL
Wrapping KeyID - 0x000C
Wrapping Key Handle - 0xHHHHHHHD
# of Key Packages - 0x0003
Key Package 1:
Key Pkg Type - 0x00 (GTPK)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - KEY1
Key Handle - 0xHHHHHHH0
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Key Package 2:
Key Pkg Type - 0x01 (Rekey - LKH)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000003
Key Handle - 0xHHHHHHH3
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Key Package 3:
Key Pkg Type - 0x01 (Rekey - LKH)
Pack Length - 0xLLLL
Key Type - 0x03 (3DES`CBC64`192)
Key ID - 0x00000006
Key Handle - 0xHHHHHHH6
Key Creation Date - YYYYMMDDHHMMSSZ
Key Expiration Date - YYYYMMDDHHMMSSZ
Key Data - variable, based on key definition
Authors' Addresses
Hugh Harney (point-of-contact) SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 Phone: (443) 430-8032 Fax: (443) 430-8181 EMail: hh@sparta.com Uri Meth SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 Phone: (443) 430-8058 Fax: (443) 430-8207 EMail: umeth@sparta.com Andrea Colegrove SPARTA, Inc. 7110 Samuel Morse Drive Columbia, MD 21046 Phone: (443) 430-8014 Fax: (443) 430-8163 EMail: acc@sparta.com George Gross IdentAware Security 82 Old Mountain Road Lebanon, NJ 08833 Phone: (908) 268-1629 EMail: gmgross@identaware.com
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).