During ISAKMP Phase I and II messages, various information must be shared within the payloads (see Exhibit 9-15). For certain payloads, such as a Transform payload, the attributes are contained within an attribute payload that acts as the data portion of the carrier payload. An example is a Transform payload; it begins with the generic header and contains certain transform information, such as ID and number. The actual Exhibit 9-12. Notification payload.
0
Protocol ID SPI Size Notify Message Type SPI
Notification Data DOI
31
detailed transform information contained in the data portion of the payload is format-ted into an attribute payload. Attribute payloads are based on a format that allows flexibility in the representation of information.
The attribute format (AF) bit is used to identify the following information contained within the payload. The data necessary to be shared among peers may require two of three fields to appropriately convey the attribute. The three attributes are:
1. Type
Each requires a Type value to properly manage the data contained. The Length is used if the value has a variable length that needs to be identified. The Value is the information defined by one or both of the two previous attributes.
There are some types of information that have a fixed length and therefore do not need a length bit. If the length is known and the length bit is absent, the value can be contained where the length bit would normally reside. This is to reduce the length of the payload, and increase efficiency and performance.
If the AF bit is set to 0, the length is included and the value is transmitted in its own field. If the AF bit is 1, the length is not required and the Length field is populated with the value, reducing the payload by 4 bytes.
Phase I Attributes. In IKE Phase I operations, there are specific transform attributes for defining the protection of IKE exchanges, as opposed to Phase II attributes that are used for the creation of IPSec SAs. IKE requires various information, ranging from the encryption algorithms to the type of authentication for the protection of IKE messages.
The attributes are defined in the IKE RFC and not the IPSec DOI, or ISAKMP RFC, as one might expect. The following is a list of IKE attributes and their types.
Encryption Algorithm 1
Life Duration 12
PRF 13
Key Length 14
Field Size 15
Group Order 16
Attribute type 1, encryption, has six defined values for use within IKE messages. The encryption algorithm defined will be used to protect various Phase I messages, Phase II (Quick Mode) messages, and any other messages within IKE requiring protection.
DES-CBC 1
IDEA-CBC 2
Blowfish-CBC 3
RC5-R16-B64-CBC 4
3DES-CBC 5
CAST-CBC 6
Values 7 to 65000 are reserved for IANA’s use, and values 65001 to 65535 are for private use among mutually consenting parties.
Attribute type 2, hash algorithm, defines the message authentication algorithm to be utilized for all IKE exchanges.
MD5 1
SHA 2
Tiger 3
Values 4 to 65000 are reserved for IANA’s use, and values 65001 to 65535 are for private use among mutually consenting parties.
Note: From this point on, the remaining values are typically reserved for IANA use and the last 534 are for private use.
Authentication, a type 3 attribute, is used to convey the authentication type to be used within IKE. This is extremely important in that it communicates to the peer in what format to respond and the structure of the messages to follow:
Pre-shared key 1
DSS signatures 2
RSA signatures 3
Encryption with RSA 4
Revised encryption with RSA 5
Group description, type 4, is to identify the Diffie-Hellman group to employ:
Default 768-bit MODP group 1 Alternate 1024-bit MODP group 2 EC2N group on GP[2^155] 3 EC2N group on GP[2^185] 4
The following types, 5 through 10, are available to convey extended Diffie-Hellman parameters, if desired. For example, group type can be defined in support of the group being used. Group types are:
MODP (modular exponentiation group) 1 ECP (elliptic curve group over GF[P]) 2 EC2N (elliptic curve group over GF[2^N]) 3
In many cases, if the peers wish to define specific parameters of the Diffie-Hellman group to be utilized, New Group Mode exchange can be used. The values shared can be conveyed in an attribute payload protected by the IKE SA created in Phase I, and not exposed in the clear as it would normally be in an SA proposal/transform chain.
Life type, type 11, provides two simple values; and type 12, life duration, is the amount that represents the valued specified in life type:
seconds 1
kilobytes 2
Type 13, pseudo random function, is currently not used. IPSec and ISAKMP do not have a defined PRF, and the HMAC portion of the message authentication process is used as a PRF for IPSec and ISAKMP operations.
Key length is used to define a key length for an encryption algorithm that supports variable keys. This option is not used for encryption algorithms that have predefined key lengths.
The field size is for the Diffie-Hellman group. The group order defines the order of the elliptical curve group.
Phase II Attributes. IKE Phase II messages, such as Quick Mode, are used to define IPSec SAs and therefore have specific attributes for their creation within IKE. Within Phase II operations, there are SA payloads that contain proposals and transform sets for the creation of IPSec SAs that require different identifiers than those available to IKE Phase I and the creation of an IKE SA. A proposal will exist for each security protocol configured, and have associated transform payloads. In the proposal payload, the IPSec security protocol will be identified, and in the transform payload, the transform type will be defined.
An example is ESP with DES encryption and MD5 authentication in an IPSec VPN.
The proposal will have the protocol ID set to IPSEC-ESP, a transform ID of ESP-DES, and an attribute payload that can define the remaining details of the SA, such as the HMAC-MD5 for message authentication. There are nine values available for use in Phase II messages for the creation of an IPSec SA.
SA Life Type 1
SA Life Type and Duration are identical to Phase I Life Type and Duration for ISAKMP messages. These attributes define the time allotted for the created SA. At the expiration of the SA, all data associated with the SA must be discarded.
Note: The creation of key material for IPSec SAs is based on the key material created during Phase I of IKE if PFS is not configured. If PFS is employed, a new Diffie-Hellman exchange is activated in Quick Mode (Phase II) and allows the peers to share new Diffie-Hellman public values, resulting in new key material without using material from Phase I (SKEYID_d and _a). Once the new key material is created (KEYMAT) for IPSec, the resulting keys used for operations within IPSec will be discarded when the SA expires. In the event a new SA is created for continuing communications, it is afforded new keys created from the material previously agreed upon. Therefore, subsequent IPSec SAs that do not require a Quick Mode exchange that includes a Diffie-Hellman public value, as in the case a new SA is created to replace one that will expire shortly, do not maintain PFS between them.
The group description is to provide an opportunity to Phase II for the creation of a new Diffie-Hellman relationship. Perfect forward secrecy can be obtained by sharing new Diffie-Hellman parameters.
Encapsulation mode is where the security protocol is configured to operate in transport mode or tunnel mode.
Tunnel 1
Transport 2
The authentication is to for defining the message authentication protocol:
HMAC-MD5 1 HMAC-SHA 2
DES-MAC 3
KPDK 4
The next three available types, 6, 7, and 8, do not currently have values associated with them and are always set to 0 for IPSec implementations.
Finally, compress private algorithm is a custom algorithm that can be agreed upon by the participants. The first three octets will be the IEEE-assigned company ID, followed by the vendor-specific data.