RFC 4535
GSAKMP: Group Secure Association Key Management Protocol
Pages: 106
Proposed Standard
Proposed Standard
Part 3 of 4 – Pages 45 to 75
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
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
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
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.
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
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.
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.
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.
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.
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.
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.
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.
RESERVED (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload,
including the generic payload header. This field is treated as
an unsigned integer in network byte order format.
Policy Token Type (2 octets) - Specifies the type of Policy Token
being used. Table 14 identifies the types of policy tokens.
This field is treated as an unsigned integer in network byte
order format.
Table 14: Policy Token Types
Policy_Token_Type Value Definition/Defined In
____________________________________________________________________
Reserved 0
GSAKMP_ASN.1_PT_V1 1 All implementations of GSAKMP
MUST support this PT format.
Format specified in [RFC4534].
Reserved to IANA 2 - 49152
Private Use 49153 - 65535
Policy Token Data (variable length) - Contains Policy Token
information. The values for this field are token specific, and
the format is specified by the PT Type field.
If this payload is encrypted, only the Policy Token Data field is
encrypted.
The payload type for the Policy Token Payload is one (1).
7.3.2. Policy Token Payload Processing
When processing the Policy Token Payload, the following fields MUST
be checked for correct values:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
2. Policy Token Type - The Policy Token Type value MUST be checked
to be a valid policy token type as defined by Table 14. If the
value is not valid, then an error is logged. If in Verbose Mode,
an appropriate message containing notification value Payload-
Malformed will be sent.
3. Policy Token Data - This Policy Token Data MUST be processed
according to the Policy Token Type specified. The type will
define the format of the data.
7.4. Key Download Payload
Refer to the terminology section for the different terms relating to
keys used within this section.
7.4.1. Key Download Payload Structure
The Key Download Payload contains group keys (e.g., group keys,
initial rekey keys, etc.). These key download payloads can have
several security attributes applied to them based upon the security
policy of the group. Figure 10 shows the format of the payload.
The security policy of the group dictates that the key download
payload MUST be encrypted with a key encryption key (KEK). The
encryption mechanism used is specified in the Policy Token. The
group members MUST create the KEK using the key creation method
identified in the Key Creation Payload.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Next Payload ! RESERVED ! Payload Length !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Number of Items ! Key Download Data Items ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Key Download Payload Format
The Key Download Payload fields are defined as follows:
Next Payload (1 octet) - Identifier for the payload type of the next
payload in the message. If the current payload is the last in
the message, then this field will be 0. This field provides the
"chaining" capability. Table 12 identifies the payload types.
This field is treated as an unsigned value.
RESERVED (1 octet) - Unused, set to 0.
Payload Length (2 octets) - Length in octets of the current payload,
including the generic payload header. This field is treated as
an unsigned integer in network byte order format.
Number of Items (2 octets) - Contains the total number of group
traffic protection keys and Rekey Arrays being passed in this
data block. This field is treated as an unsigned integer in
network byte order format.
Key Download Data Items (variable length) - Contains Key Download
information. The Key Download Data is a sequence of
Type/Length/Data of the Number of Items. The format for each
item is defined in Figure 11.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! KDD Item Type ! Key Download Data Item Length! ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Data for Key Download Data Item (Key Datum/Rekey Array) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Key Download Data Item Format
For each Key Download Data Item, the data format is as follows:
Key Download Data (KDD) Item Type (1 octet) - Identifier for the
type of data contained in this Key Download Data Item. See
Table 15 for the possible values of this field. This field
is treated as an unsigned value.
Key Download Data Item Length (2 octets) - Length in octets of
the Data for the Key Download Data Item following this field.
This field is treated as an unsigned integer in network byte
order format.
Data for Key Download Data Item (variable length) - Contains Keys
and related information. The format of this field is
specific depending on the value of the Key Download Data Item
Type field. For KDD Item Type of GTPK, this field will
contain a Key Datum as defined in Section 7.4.1.1. For KDD
Item Type Rekey - LKH, this field will contain a Rekey Array
as defined in Section 7.4.1.2.
Table 15: Key Download Data Item Types
Key Download Data Value Definition
Item Type
_________________________________________________________________
GTPK 0 This type MUST be implemented.
This type identifies that the
data contains group traffic
protection key information.
Rekey - LKH 1 Optional
Reserved to IANA 2 - 192
Private Use 193 - 255
The encryption of this payload only covers the data subsequent to the
Generic Payload header (Number of Items and Key Download Data Items
fields).
The payload type for the Key Download Packet is two (2).
7.4.1.1. Key Datum Structure
A Key Datum contains all the information for a key. Figure 12 shows the format for this structure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key Type ! Key ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! Key Handle ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! Key Creation Date ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! Key Expiration Date ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Key Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Key Datum Format Key Type (2 octets) - This is the cryptographic algorithm for which this key data is to be used. This value is specified in the Policy Token. See Table 16 for the possible values of this field. This field is treated as an unsigned value.
Table 16: Cryptographic Key Types
Cryptographic_Key_Types Value Description/Defined In
____________________________________________________________________
Reserved 0 - 2
3DES_CBC64_192 3 See [RFC2451].
Reserved 4 - 11
AES_CBC_128 12 This type MUST be
supported. See [IKEv2].
AES_CTR 13 See [IKEv2].
Reserved to IANA 14 - 49152
Private Use 49153 - 65535
Key ID (4 octets) - This is the permanent ID of all versions of the
key. This value MAY be defined by the Policy Token. This field
is treated as an octet string.
Key Handle (4 octets) - This is the value to uniquely identify a
version (particular instance) of a key. This field is treated as
an octet string.
Key Creation Date (15 octets) - This is the time value of when this
key data was originally generated. This field contains the
timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year
(0000 - 9999), MM is the numerical value of the month (01 - 12),
DD is the day of the month (01 - 31), HH is the hour of the day
(00 - 23), MM is the minute within the hour (00 - 59), SS is the
seconds within the minute (00 - 59), and the letter Z indicates
that this is Zulu time. This format is loosely based on
[RFC3161].
Key Expiration Date (15 octets) - This is the time value of when this
key is no longer valid for use. This field contains the
timestamp in UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year
(0000 - 9999), MM is the numerical value of the month (01 - 12),
DD is the day of the month (01 - 31), HH is the hour of the day
(00 - 23), MM is the minute within the hour (00 - 59), SS is the
seconds within the minute (00 - 59), and the letter Z indicates
that this is Zulu time. This format is loosely based on
[RFC3161].
Key Data (variable length) - This is the actual key data, which is
dependent on the Key Type algorithm for its format.
NOTE: The combination of the Key ID and the Key Handle MUST be unique
within the group. This combination will be used to uniquely identify
a key.
7.4.1.2. Rekey Array Structure
A Rekey Array contains the information for the set of KEKs that is associated with a Group Member. Figure 13 shows the format for this structure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Rekey Version#! Member ID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! Number of KEK Keys ! ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Key Datum(s) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Rekey Array Structure Format Rekey Version (1 octet) - Contains the version of the Rekey protocol in which the data is formatted. For Key Download Data Item Type of Rekey - LKH, refer to Section A.2 for a description of this value. This field is treated as an unsigned value. Member ID (4 octets) - This is the Member ID of the Rekey sequence contained in this Rekey Array. This field is treated as an octet string. For Key Download Data Item Type of Rekey - LKH, refer to Section A.2 for a description of this value. Number of KEK Keys (2 octets) - This value is the number of distinct KEK keys in this sequence. This value is treated as an unsigned integer in network byte order format. Key Datum(s) (variable length) - The sequence of KEKs in Key Datum format. The format for each Key Datum in this sequence is defined in section 7.4.1.1. Key ID (for Key ID within the Rekey) - LKH space, refer to Section A.2 for a description of this value.7.4.2. Key Download Payload Processing
Prior to processing its data, the payload contents MUST be decrypted. When processing the Key Download Payload, the following fields MUST be checked for correct values:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
2. KDD Item Type - All KDD Item Type fields MUST be checked to be a
valid Key Download Data Item type as defined by Table 15. If the
value is not valid, then an error is logged. If in Verbose Mode,
an appropriate message containing notification value Payload-
Malformed will be sent.
3. Key Type - All Key Type fields MUST be checked to be a valid
encryption type as defined by Table 16. If the value is not
valid, then an error is logged. If in Verbose Mode, an
appropriate message containing notification value Invalid-Key-
Information will be sent.
4. Key Expiration Date - All Key Expiration Date fields MUST be
checked confirm that their values represent a future and not a
past time value. If the value is not valid, then an error is
logged. If in Verbose Mode, an appropriate message containing
notification value Invalid-Key-Information will be sent.
The length and counter fields in the payload are used to help process
the payload. If any field is found to be incorrect, then an error is
logged. If in Verbose Mode, an appropriate message containing
notification value Payload-Malformed will be sent.
7.5. Rekey Event Payload
Refer to the terminology section for the different terms relating to
keys used within this section.
7.5.1. Rekey Event Payload Structure
The Rekey Event Payload MAY contain multiple keys encrypted in
Wrapping KEKs. Figure 14 shows the format of the payload. If the
data to be contained within a Rekey Event Payload is too large for
the payload, the sequence can be split across multiple Rekey Event
Payloads at a Rekey Event Data boundary.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! RekeyEvnt Type! Rekey Event Header ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Rekey Event Data(s) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Rekey Event Payload Format The Rekey Event Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format. Rekey Event Type (1 octet) - Specifies the type of Rekey Event being used. Table 17 presents the types of Rekey events. This field is treated as an unsigned value. Rekey Event Header (variable length) - This is the header information for the Rekey Event. The format for this is defined in Section 7.5.1.1, "Rekey Event Header Structure". Rekey Event Data(s) (variable length) - This is the rekey information for the Rekey Event. The format for this is defined in Section 7.5.1.2, "Rekey Event Data Structure". The Rekey Event payload type is three (3).
Table 17: Rekey Event Types
Rekey_Event_Type Value Definition/Defined In
_____________________________________________________________________
None 0 This type MUST be implemented.
In this case, the size of the Rekey
Event Data field will be zero bytes
long. The purpose of a Rekey Event
Payload with type None is when it is
necessary to send out a new token
with no rekey information. GSAKMP
rekey msg requires a Rekey Event
Payload, and in this instance it
would have rekey data of type None.
GSAKMP_LKH 1 The rekey data will be of
type LKH formatted according to
GSAKMP. The format for this field
is defined in Section 7.5.1.2.
Reserved to IANA 2 - 192
Private Use 193 - 255
7.5.1.1. Rekey Event Header Structure
The format for the Rekey Event Header is shown in Figure 15.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Group ID Value ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Group ID Value !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Time/Date Stamp ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ! RekeyEnt Type ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Algorithm Ver ! # of Rekey Event Data(s) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: Rekey Event Header Format
Group Identification Value (variable length) - Indicates the
name/title of the group to be rekeyed. This is the same format,
length, and value as the Group Identification Value in Section
7.1, "GSAKMP Header".
Time/Date Stamp (15 octets) - This is the time value when the Rekey
Event Data was generated. This field contains the timestamp in
UTF-8 format YYYYMMDDHHMMSSZ, where YYYY is the year (0000 -
9999), MM is the numerical value of the month (01 - 12), DD is
the day of the month (01 - 31), HH is the hour of the day (00 -
23), MM is the minute within the hour (00 - 59), SS is the
seconds within the minute (00 - 59), and the letter Z indicates
that this is Zulu time. This format is loosely based on
[RFC3161].
Rekey Event Type (1 octet) - This is the Rekey algorithm being used
for this group. The values for this field can be found in Table
17. This field is treated as an unsigned value.
Algorithm Version (1 octet) - Indicates the version of the Rekey Type
being used. For Rekey Event Type of GSAKMP_LKH, refer to Section
A.2 for a description of this value. This field is treated as an
unsigned value.
# of Rekey Event Data(s) (2 octets) - The number of Rekey Event
Data(s) contained in the Rekey Data. This value is treated as an
unsigned integer in network byte order.
7.5.1.2. Rekey Event Data Structure
As defined in the Rekey Event Header, # of Rekey Data(s) field,
multiple pieces of information are sent in a Rekey Event Data. Each
end user, will be interested in only one Rekey Event Data among all
of the information sent. Each Rekey Event Data will contain all the
Key Packages that a user requires. For each Rekey Event Data, the
data following the Wrapping fields is encrypted with the key
identified in the Wrapping Header. Figure 16 shows the format of
each Rekey Event Data.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Packet Length ! Wrapping KeyID ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! Wrapping Key Handle ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! # of Key Packages ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Key Packages(s) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 16: Rekey Event Data Format Packet Length (2 octets) - Length in octets of the Rekey Event Data, which consists of the # of Key Packages and the Key Packages(s). This value is treated as an unsigned integer in network byte order. Wrapping KeyID (4 octets) - This is the Key ID of the KEK that is being used for encryption/decryption of the new (rekeyed) keys. For Rekey Event Type of Rekey - LKH, refer to Section A.2 for a description of this value. Wrapping Key Handle (4 octets) - This is a Key Handle of the KEK that is being used for encryption/decryption of the new (rekeyed) keys. Refer to Section 7.4.1.1 for the values of this field. # of Key Packages (2 octets) - The number of key packages contained in this Rekey Event Data. This value is treated as an unsigned integer in network byte order. Key Package(s) (variable length) - The type/length/value format of a Key Datum. The format for this is defined in Section 7.5.1.2.1.7.5.1.2.1. Key Package Structure
Each Key Package contains all the information about the key. Figure 17 shows the format for a Key Package. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! KeyPkg Type ! Key Package Length ! Key Datum ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: Key Package Format
Key Package Type (1 octet) - The type of key in this key package.
Legal values for this field are defined in Table 15, Key Download
Data Types. This field is treated as an unsigned value.
Key Package Length (2 octets) - The length of the Key Datum. This
field is treated as an unsigned integer in network byte order
format.
Key Datum (variable length) - The actual data of the key. The format
for this field is defined in Section 7.4.1.1, "Key Datum
Structure".
7.5.2. Rekey Event Payload Processing
When processing the Rekey Event Payload, the following fields MUST be
checked for correct values:
1. Next Payload, RESERVED, Payload Length - These fields are
processed as defined in Section 7.2.2, "Generic Payload Header
Processing".
2. Rekey Event Type field within "Rekey Event" payload header - The
Rekey Event Type MUST be checked to be a valid rekey event type
as defined by Table 17. If the Rekey Event Type is not valid,
then regardless of mode (e.g., Terse or Verbose) an error is
logged. No response error message is generated for receipt of a
Group Management Message.
3. Group ID Value - The Group ID value of the Rekey Event Header
received message MUST be checked against the GroupID of the Group
Component. If no match is found, the payload is discarded, then
regardless of mode (e.g., Terse or Verbose) an error is logged.
No response error message is generated for receipt of a Group
Management Message.
4. Date/Time Stamp - The Date/Time Stamp value of the Rekey Event
Header MAY be checked to determine if the Rekey Event generation
time is recent relative to network delay and processing times.
If the TimeStamp is judged not to be recent, an error is logged.
No response error message is generated for receipt of a Group
Management Message.
5. Rekey Event Type field within the "Rekey Event Header" - The
Rekey Event Type of the Rekey Event Header received message MUST
be checked to be a valid rekey event type, as defined by Table
17, and the same value of the Rekey Event Type earlier in this
payload. If the Rekey Event Type is not valid or not equal to
the previous value of the Rekey Event Type, then regardless of
mode (e.g., Terse or Verbose) an error is logged. No response
error message is generated for receipt of a Group Management
Message.
6. Algorithm Version - The Rekey Algorithm Version number MUST be
checked to ensure that the version indicated is supported. If it
is not supported, then regardless of mode (e.g., Terse or
Verbose) an error is logged. No response error message is
generated for receipt of a Group Management Message.
The length and counter fields are used to help process the message.
If any field is found to be incorrect, then termination processing
MUST be initiated.
A GM MUST process all the Rekey Event Datas as based on the rekey
method used there is a potential that multiple Rekey Event Datas are
for this GM. The Rekey Event Datas are processed in order until all
Rekey Event Datas are consumed.
1. Wrapping KeyID - The Wrapping KeyID MUST be checked against the
list of stored KEKs that this GM holds. If a match is found,
then continue processing this Rekey Event Data. Otherwise, skip
to the next Rekey Event Data.
2. Wrapping Handle - If a matching Wrapping KeyID was found, then
the Wrapping Handle MUST be checked against the handle of the KEK
for which the KeyID was a match. If the handles match, then the
GM will process the Key Packages associated with this Rekey Event
Data. Otherwise, skip to the next Rekey Event Data.
If a GM has found a matching Wrapping KeyID and Wrapping Handle, the
GM decrypts the remaining data in this Rekey Event Data according to
policy using the KEK defined by the Wrapping KeyID and Handle. After
decrypting the data, the GM extracts the # of Key Packages field to
help process the subsequent Key Packages. The Key Packages are
processed as follows:
1. Key Package Type - The Key Package Type MUST be checked to be a
valid key package type as defined by Table 15. If the Key
Package Type is not valid, then regardless of mode (e.g., Terse
or Verbose) an error is logged. No response error message is
generated for receipt of a Group Management Message.
2. Key Package Length - The Key Package Length is used to process
the subsequent Key Datum information.
3. Key Type - The Key Type MUST be checked to be a valid key type as
defined by Table 16. If the Key Package Type is not valid, then
regardless of mode (e.g., Terse or Verbose) an error is logged.
No response error message is generated for receipt of a Group
Management Message.
4. Key ID - The Key ID MUST be checked against the set of Key IDs
that this user maintains for this Key Type. If no match is
found, then regardless of mode (e.g., Terse or Verbose) an error
is logged. No response error message is generated for receipt of
a Group Management Message.
5. Key Handle - The Key Handle is extracted as is and is used to be
the new Key Handle for the Key currently associated with the Key
Package's Key ID.
6. Key Creation Date - The Key Creation Date MUST be checked that it
is subsequent to the Key Creation Date for the currently held
key. If this date is prior to the currently held key, then
regardless of mode (e.g., Terse or Verbose) an error is logged.
No response error message is generated for receipt of a Group
Management Message.
7. Key Expiration Date - The Key Expiration Date MUST be checked
that it is subsequent to the Key Creation Date just received and
that the time rules conform with policy. If the expiration date
is not subsequent to the creation date or does not conform with
policy, then regardless of mode (e.g., Terse or Verbose) an error
is logged. No response error message is generated for receipt of
a Group Management Message.
8. Key Data - The Key Data is extracted based on the length
information in the key package.
If there were no errors when processing the Key Package, the key
represented by the KeyID will have all of its data updated based upon
the received information.
7.6. Identification Payload
7.6.1. Identification Payload Structure
The Identification Payload contains entity-specific data used to
exchange identification information. This information is used to
verify the identities of members. Figure 18 shows the format of the
Identification Payload.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload ! RESERVED ! Payload Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ID Classif ! ID Type ! Identification Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: Identification Payload Format The Identification Payload fields are defined as follows: Next Payload (1 octet) - Identifier for the payload type of the next payload in the message. If the current payload is the last in the message, then this field will be 0. This field provides the "chaining" capability. Table 12 identifies the payload types. This field is treated as an unsigned value. RESERVED (1 octet) - Unused, set to 0. Payload Length (2 octets) - Length in octets of the current payload, including the generic payload header. This field is treated as an unsigned integer in network byte order format. Identification (ID) Classification (1 octet) - Classifies the ownership of the Identification Data. Table 18 identifies possible values for this field. This field is treated as an unsigned value. Table 18: Identification Classification ID_Classification Value _______________________________ Sender 0 Receiver 1 Third Party 2 Reserved to IANA 3 - 192 Private Use 193 - 255 Identification (ID) Type (1 octet) - Specifies the type of Identification being used. Table 19 identifies possible values for this type. This field is treated as an unsigned value. All defined types are OPTIONAL unless otherwise stated.
Identification Data (variable length) - Contains identity
information. The values for this field are group specific, and
the format is specified by the ID Type field. The format for
this field is stated in conjunction with the type in Table 19.
The payload type for the Identification Payload is four (4).
Table 19: Identification Types
ID_Type Value PKIX Cert Description
Field Defined In
_____________________________________________________________________
Reserved 0
ID_IPV4_ADDR 1 SubjAltName See [IKEv2]
iPAddress Section 3.5.
ID_FQDN 2 SubjAltName See [IKEv2]
dNSName Section 3.5.
ID_RFC822_ADDR 3 SubjAltName See [IKEv2]
rfc822Name Section 3.5.
Reserved 4
ID_IPV6_ADDR 5 SubjAltName See [IKEv2]
iPAddress Section 3.5.
Reserved 6 - 8
ID_DER_ASN1_DN 9 Entire Subject, See [IKEv2]
bitwise Compare Section 3.5.
Reserved 10
ID_KEY_ID 11 N/A See [IKEv2]
Reserved 12 - 29 Section 3.5.
Unencoded Name 30 Subject The format for
(ID_U_NAME) this type is
defined in
Section 7.6.1.1.
ID_DN_STRING 31 Subject See [RFC4514].
This type MUST
be implemented.
Reserved to IANA 32 - 192
Private Use 193 - 255
7.6.1.1. ID_U_NAME Structure
The format for type Unencoded Name (ID_U_NAME) is shown in Figure 19. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Serial Number ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Length ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! DN Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: Unencoded Name (ID-U-NAME) Format Serial Number (20 octets) - The certificate serial number. This field is treated as an unsigned integer in network byte order format. Length (4 octets) - Length in octets of the DN Data field. This field is treated as an unsigned integer in network byte order format. DN Data (variable length) - The actual UTF-8 DN value (Subject field) using the slash (/) character for field delimiters (e.g., "/C=US/ST=MD/L=Somewhere/O=ACME, Inc./OU=DIV1/CN=user1/ Email=user1@acme.com" without the surrounding quotes).7.6.2. Identification Payload Processing
When processing the Identification Payload, the following fields MUST be checked for correct values: 1. Next Payload, RESERVED, Payload Length - These fields are processed as defined in Section 7.2.2, "Generic Payload Header Processing".
2. Identification Classification - The Identification Classification
value MUST be checked to be a valid identification classification
type as defined by Table 18. If the value is not valid, then an
error is logged. If in Verbose Mode, an appropriate message
containing notification value Payload-Malformed will be sent.
3. Identification Type - The Identification Type value MUST be
checked to be a valid identification type as defined by Table 19.
If the value is not valid, then an error is logged. If in
Verbose Mode, an appropriate message containing notification
value Payload-Malformed will be sent.
4. Identification Data - This Identification Data MUST be processed
according to the identification type specified. The type will
define the format of the data. If the identification data is
being used to find a match and no match is found, then an error
is logged. If in Verbose Mode, an appropriate message containing
notification value Invalid-ID-Information will be sent.
7.6.2.1. ID_U_NAME Processing
When processing the Identification Data of type ID_U_NAME, the
following fields MUST be checked for correct values:
1. Serial Number - The serial number MUST be a greater than or equal
to one (1) to be a valid serial number from a conforming CA
[RFC3280]. If the value is not valid, then an error is logged.
If in Verbose Mode, an appropriate message containing
notification value Payload-Malformed will be sent.
2. DN Data - The DN data is processed as a UTF-8 string.
3. The CA MUST be a valid trusted policy creation authority as
defined by the Policy Token.
These 2 pieces of information, Serial Number and DN Data, in
conjunction, will then be used for party identification. These
values are also used to help identify the certificate when necessary.
(page 75 continued on part 4)