RFC 2408
Internet Security Association and Key Management Protocol (ISAKMP)
4 ISAKMP Exchanges ISAKMP supplies the basic syntax of a message exchange. The basic building blocks for ISAKMP messages are the payload types described in section 3. This section describes the procedures for SA
establishment and SA modification, followed by a default set of exchanges that MAY be used for initial interoperability. Other exchanges will be defined depending on the DOI and key exchange. [IPDOI] and [IKE] are examples of how this is achieved. Appendix B explains the procedures for accomplishing these additions. 4.1 ISAKMP Exchange Types ISAKMP allows the creation of exchanges for the establishment of Security Associations and keying material. There are currently five default Exchange Types defined for ISAKMP. Sections 4.4 through 4.8 describe these exchanges. Exchanges define the content and ordering of ISAKMP messages during communications between peers. Most exchanges will include all the basic payload types - SA, KE, ID, SIG - and may include others. The primary difference between exchange types is the ordering of the messages and the payload ordering within each message. While the ordering of payloads within messages is not mandated, for processing efficiency it is RECOMMENDED that the Security Association payload be the first payload within an exchange. Processing of each payload within an exchange is described in section 5. Sections 4.4 through 4.8 provide a default set of ISAKMP exchanges. These exchanges provide different security protection for the exchange itself and information exchanged. The diagrams in each of the following sections show the message ordering for each exchange type as well as the payloads included in each message, and provide basic notes describing what has happened after each message exchange. None of the examples include any "optional payloads", like certificate and certificate request. Additionally, none of the examples include an initial exchange of ISAKMP Headers (containing initiator and responder cookies) which would provide protection against clogging (see section 2.5.3). The defined exchanges are not meant to satisfy all DOI and key exchange protocol requirements. If the defined exchanges meet the DOI requirements, then they can be used as outlined. If the defined exchanges do not meet the security requirements defined by the DOI, then the DOI MUST specify new exchange type(s) and the valid sequences of payloads that make up a successful exchange, and how to build and interpret those payloads. All ISAKMP implementations MUST implement the Informational Exchange and SHOULD implement the other four exchanges. However, this is dependent on the definition of the DOI and associated key exchange protocols.
As discussed above, these exchange types can be used in either phase of negotiation. However, they may provide different security properties in each of the phases. With each of these exchanges, the combination of cookies and SPI fields identifies whether this exchange is being used in the first or second phase of a negotiation. 4.1.1 Notation The following notation is used to describe the ISAKMP exchange types, shown in the next section, with the message formats and associated payloads: HDR is an ISAKMP header whose exchange type defines the payload orderings SA is an SA negotiation payload with one or more Proposal and Transform payloads. An initiator MAY provide multiple proposals for negotiation; a responder MUST reply with only one. KE is the key exchange payload. IDx is the identity payload for "x". x can be: "ii" or "ir" for the ISAKMP initiator and responder, respectively, or x can be: "ui", "ur" (when the ISAKMP daemon is a proxy negotiator), for the user initiator and responder, respectively. HASH is the hash payload. SIG is the signature payload. The data to sign is exchange-specific. AUTH is a generic authentication mechanism, such as HASH or SIG. NONCE is the nonce payload. '*' signifies payload encryption after the ISAKMP header. This encryption MUST begin immediately after the ISAKMP header and all payloads following the ISAKMP header MUST be encrypted. => signifies "initiator to responder" communication <= signifies "responder to initiator" communication 4.2 Security Association Establishment The Security Association, Proposal, and Transform payloads are used to build ISAKMP messages for the negotiation and establishment of SAs. An SA establishment message consists of a single SA payload followed by at least one, and possibly many, Proposal payloads and at least one, and possibly many, Transform payloads associated with each Proposal payload. Because these payloads are considered together, the SA payload will point to any following payloads and not to the Proposal payload included with the SA payload. The SA Payload contains the DOI and Situation for the proposed SA. Each Proposal payload contains a Security Parameter Index (SPI) and ensures that the SPI is associated with the Protocol-Id in accordance with the Internet Security Architecture [SEC-ARCH]. Proposal payloads may or may not have the same SPI, as this is implementation dependent. Each
Transform Payload contains the specific security mechanisms to be used for the designated protocol. It is expected that the Proposal and Transform payloads will be used only during SA establishment negotiation. The creation of payloads for security association negotiation and establishment described here in this section are applicable for all ISAKMP exchanges described later in sections 4.4 through 4.8. The examples shown in 4.2.1 contain only the SA, Proposal, and Transform payloads and do not contain other payloads that might exist for a given ISAKMP exchange. The Proposal payload provides the initiating entity with the capability to present to the responding entity the security protocols and associated security mechanisms for use with the security association being negotiated. If the SA establishment negotiation is for a combined protection suite consisting of multiple protocols, then there MUST be multiple Proposal payloads each with the same Proposal number. These proposals MUST be considered as a unit and MUST NOT be separated by a proposal with a different proposal number. The use of the same Proposal number in multiple Proposal payloads provides a logical AND operation, i.e. Protocol 1 AND Protocol 2. The first example below shows an ESP AND AH protection suite. If the SA establishment negotiation is for different protection suites, then there MUST be multiple Proposal payloads each with a monotonically increasing Proposal number. The different proposals MUST be presented in the initiator's preference order. The use of different Proposal numbers in multiple Proposal payloads provides a logical OR operation, i.e. Proposal 1 OR Proposal 2, where each proposal may have more than one protocol. The second example below shows either an AH AND ESP protection suite OR just an ESP protection suite. Note that the Next Payload field of the Proposal payload points to another Proposal payload (if it exists). The existence of a Proposal payload implies the existence of one or more Transform payloads. The Transform payload provides the initiating entity with the capability to present to the responding entity multiple mechanisms, or transforms, for a given protocol. The Proposal payload identifies a Protocol for which services and mechanisms are being negotiated. The Transform payload allows the initiating entity to present several possible supported transforms for that proposed protocol. There may be several transforms associated with a specific Proposal payload each identified in a separate Transform payload. The multiple transforms MUST be presented with monotonically increasing numbers in the initiator's preference order. The receiving entity MUST select a single transform for each protocol in a proposal or reject the entire proposal. The use of the Transform number in multiple Transform payloads provides a second level OR operation, i.e. Transform 1 OR Transform 2 OR Transform 3. Example 1 below shows two possible transforms for ESP and a single transform for AH. Example 2 below
shows one transform for AH AND one transform for ESP OR two transforms for ESP alone. Note that the Next Payload field of the Transform payload points to another Transform payload or 0. The Proposal payload delineates the different proposals. When responding to a Security Association payload, the responder MUST send a Security Association payload with the selected proposal, which may consist of multiple Proposal payloads and their associated Transform payloads. Each of the Proposal payloads MUST contain a single Transform payload associated with the Protocol. The responder SHOULD retain the Proposal # field in the Proposal payload and the Transform # field in each Transform payload of the selected Proposal. Retention of Proposal and Transform numbers should speed the initiator's protocol processing by negating the need to compare the respondor's selection with every offered option. These values enable the initiator to perform the comparison directly and quickly. The initiator MUST verify that the Security Association payload received from the responder matches one of the proposals sent initially. 4.2.1 Security Association Establishment Examples This example shows a Proposal for a combined protection suite with two different protocols. The first protocol is presented with two transforms supported by the proposer. The second protocol is presented with a single transform. An example for this proposal might be: Protocol 1 is ESP with Transform 1 as 3DES and Transform 2 as DES AND Protocol 2 is AH with Transform 1 as SHA. The responder MUST select from the two transforms proposed for ESP. The resulting protection suite will be either (1) 3DES AND SHA OR (2) DES AND SHA, depending on which ESP transform was selected by the responder. Note this example is shown using the Base Exchange. 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 /+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Nonce ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SA Pay ! Domain of Interpretation (DOI) ! \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! Situation ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Proposal ! RESERVED ! Payload Length ! / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Prop 1 ! Proposal # = 1! Protocol-Id ! SPI Size !# of Trans. = 2! Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ \ ! SPI (variable) ! >+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This second example shows a Proposal for two different protection
suites. The SA Payload was omitted for space reasons. The first
protection suite is presented with one transform for the first
protocol and one transform for the second protocol. The second
protection suite is presented with two transforms for a single
protocol. An example for this proposal might be: Proposal 1 with
Protocol 1 as AH with Transform 1 as MD5 AND Protocol 2 as ESP with
Transform 1 as 3DES. This is followed by Proposal 2 with Protocol 1
as ESP with Transform 1 as DES and Transform 2 as 3DES. The responder
MUST select from the two different proposals. If the second Proposal
is selected, the responder MUST select from the two transforms for
ESP. The resulting protection suite will be either (1) MD5 AND 3DES
OR the selection between (2) DES OR (3) 3DES.
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
/+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Proposal ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 1 ! Proposal # = 1! Protocol ID ! SPI Size !# of Trans. = 1!
Prot 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prop 2 ! Proposal # = 2! Protocol ID ! SPI Size !# of Trans. = 2!
Prot 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SPI (variable) !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = Transform! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 1 ! Transform # 1 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ ! NP = 0 ! RESERVED ! Payload Length !
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Tran 2 ! Transform # 2 ! Transform ID ! RESERVED2 !
\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ ! SA Attributes !
\+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3 Security Association Modification
Security Association modification within ISAKMP is accomplished by
creating a new SA and initiating communications using that new SA.
Deletion of the old SA can be done anytime after the new SA is
established. Deletion of the old SA is dependent on local security
policy. Modification of SAs by using a "Create New SA followed by
Delete Old SA" method is done to avoid potential vulnerabilities in
synchronizing modification of existing SA attributes. The procedure
for creating new SAs is outlined in section 4.2. The procedure for
deleting SAs is outlined in section 5.15.
Modification of an ISAKMP SA (phase 1 negotiation) follows the same procedure as creation of an ISAKMP SA. There is no relationship between the two SAs and the initiator and responder cookie pairs SHOULD be different, as outlined in section 2.5.3. Modification of a Protocol SA (phase 2 negotiation) follows the same procedure as creation of a Protocol SA. The creation of a new SA is protected by the existing ISAKMP SA. There is no relationship between the two Protocol SAs. A protocol implementation SHOULD begin using the newly created SA for outbound traffic and SHOULD continue to support incoming traffic on the old SA until it is deleted or until traffic is received under the protection of the newly created SA. As stated previously in this section, deletion of an old SA is then dependent on local security policy. 4.4 Base Exchange The Base Exchange is designed to allow the Key Exchange and Authentication related information to be transmitted together. Combining the Key Exchange and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity protection. Identity protection is not provided because identities are exchanged before a common shared secret has been established and, therefore, encryption of the identities is not possible. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Base Exchange. BASE EXCHANGE # Initiator Direction Responder NOTE (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation (2) <= HDR; SA; NONCE Basic SA agreed upon (3) HDR; KE; => IDii; AUTH Key Generated (by responder) Initiator Identity Verified by Responder (4) <= HDR; KE; IDir; AUTH Responder Identity Verified by Initiator Key Generated (by initiator) SA established
In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Again, random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange. In the third (3) and fourth (4) messages, the initiator and responder, respectively, exchange keying material used to arrive at a common shared secret and identification information. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. 4.5 Identity Protection Exchange The Identity Protection Exchange is designed to separate the Key Exchange information from the Identity and Authentication related information. Separating the Key Exchange from the Identity and Authentication related information provides protection of the communicating identities at the expense of two additional messages. Identities are exchanged under the protection of a previously established common shared secret. The following diagram shows the messages with the possible payloads sent in each message and notes for an example of the Identity Protection Exchange.
IDENTITY PROTECTION EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR; SA => Begin ISAKMP-SA or
Proxy negotiation
(2) <= HDR; SA
Basic SA agreed upon
(3) HDR; KE; NONCE =>
(4) <= HDR; KE; NONCE
Key Generated (by
Initiator and
Responder)
(5) HDR*; IDii; AUTH =>
Initiator Identity
Verified by
Responder
(6) <= HDR*; IDir; AUTH
Responder Identity
Verified by
Initiator
SA established
In the first message (1), the initiator generates a proposal it
considers adequate to protect traffic for the given situation. The
Security Association, Proposal, and Transform payloads are included
in the Security Association payload (for notation purposes).
In the second message (2), the responder indicates the protection
suite it has accepted with the Security Association, Proposal, and
Transform payloads. Local security policy dictates the action of the
responder if no proposed protection suite is accepted. One possible
action is the transmission of a Notify payload as part of an
Informational Exchange.
In the third (3) and fourth (4) messages, the initiator and
responder, respectively, exchange keying material used to arrive at a
common shared secret and random information which is used to
guarantee liveness and protect against replay attacks. Random
information provided by both parties SHOULD be used by the
authentication mechanism to provide shared proof of participation in
the exchange. Local security policy dictates the action if an error
occurs during these messages. One possible action is the
transmission of a Notify payload as part of an Informational
Exchange.
In the fifth (5) and sixth (6) messages, the initiator and responder,
respectively, exchange identification information and the results of
the agreed upon authentication function. This information is
transmitted under the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. 4.6 Authentication Only Exchange The Authentication Only Exchange is designed to allow only Authentication related information to be transmitted. The benefit of this exchange is the ability to perform only authentication without the computational expense of computing keys. Using this exchange during negotiation, none of the transmitted information will be encrypted. However, the information may be encrypted in other places. For example, if encryption is negotiated during the first phase of a negotiation and the authentication only exchange is used in the second phase of a negotiation, then the authentication only exchange will be encrypted by the ISAKMP SAs negotiated in the first phase. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Authentication Only Exchange. AUTHENTICATION ONLY EXCHANGE # Initiator Direction Responder NOTE (1) HDR; SA; NONCE => Begin ISAKMP-SA or Proxy negotiation (2) <= HDR; SA; NONCE; IDir; AUTH Basic SA agreed upon Responder Identity Verified by Initiator (3) HDR; IDii; AUTH => Initiator Identity Verified by Responder SA established In the first message (1), the initiator generates a proposal it considers adequate to protect traffic for the given situation. The Security Association, Proposal, and Transform payloads are included in the Security Association payload (for notation purposes). Random information which is used to guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. In the second message (2), the responder indicates the protection suite it has accepted with the Security Association, Proposal, and Transform payloads. Again, random information which is used to
guarantee liveness and protect against replay attacks is also transmitted. Random information provided by both parties SHOULD be used by the authentication mechanism to provide shared proof of participation in the exchange. Additionally, the responder transmits identification information. All of this information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action of the responder if no proposed protection suite is accepted. One possible action is the transmission of a Notify payload as part of an Informational Exchange. In the third message (3), the initiator transmits identification information. This information is transmitted under the protection of the agreed upon authentication function. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. 4.7 Aggressive Exchange The Aggressive Exchange is designed to allow the Security Association, Key Exchange and Authentication related payloads to be transmitted together. Combining the Security Association, Key Exchange, and Authentication-related information into one message reduces the number of round-trips at the expense of not providing identity protection. Identity protection is not provided because identities are exchanged before a common shared secret has been established and, therefore, encryption of the identities is not possible. Additionally, the Aggressive Exchange is attempting to establish all security relevant information in a single exchange. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Aggressive Exchange.
AGGRESSIVE EXCHANGE
# Initiator Direction Responder NOTE
(1) HDR; SA; KE; => Begin ISAKMP-SA or
Proxy negotiation
NONCE; IDii and Key Exchange
(2) <= HDR; SA; KE;
NONCE; IDir; AUTH
Initiator Identity
Verified by Responder
Key Generated
Basic SA agreed upon
(3) HDR*; AUTH =>
Responder Identity
Verified by Initiator
SA established
In the first message (1), the initiator generates a proposal it
considers adequate to protect traffic for the given situation. The
Security Association, Proposal, and Transform payloads are included
in the Security Association payload (for notation purposes). There
can be only one Proposal and one Transform offered (i.e. no choices)
in order for the aggressive exchange to work. Keying material used
to arrive at a common shared secret and random information which is
used to guarantee liveness and protect against replay attacks are
also transmitted. Random information provided by both parties SHOULD
be used by the authentication mechanism to provide shared proof of
participation in the exchange. Additionally, the initiator transmits
identification information.
In the second message (2), the responder indicates the protection
suite it has accepted with the Security Association, Proposal, and
Transform payloads. Keying material used to arrive at a common
shared secret and random information which is used to guarantee
liveness and protect against replay attacks is also transmitted.
Random information provided by both parties SHOULD be used by the
authentication mechanism to provide shared proof of participation in
the exchange. Additionally, the responder transmits identification
information. All of this information is transmitted under the
protection of the agreed upon authentication function. Local
security policy dictates the action of the responder if no proposed
protection suite is accepted. One possible action is the
transmission of a Notify payload as part of an Informational
Exchange.
In the third (3) message, the initiator transmits the results of the agreed upon authentication function. This information is transmitted under the protection of the common shared secret. Local security policy dictates the action if an error occurs during these messages. One possible action is the transmission of a Notify payload as part of an Informational Exchange. 4.8 Informational Exchange The Informational Exchange is designed as a one-way transmittal of information that can be used for security association management. The following diagram shows the messages with possible payloads sent in each message and notes for an example of the Informational Exchange. INFORMATIONAL EXCHANGE # Initiator Direction Responder NOTE (1) HDR*; N/D => Error Notification or Deletion In the first message (1), the initiator or responder transmits an ISAKMP Notify or Delete payload. If the Informational Exchange occurs prior to the exchange of keying meterial during an ISAKMP Phase 1 negotiation, there will be no protection provided for the Informational Exchange. Once keying material has been exchanged or an ISAKMP SA has been established, the Informational Exchange MUST be transmitted under the protection provided by the keying material or the ISAKMP SA. All exchanges are similar in that with the beginning of any exchange, cryptographic synchronization MUST occur. The Informational Exchange is an exchange and not an ISAKMP message. Thus, the generation of an Message ID (MID) for an Informational Exchange SHOULD be independent of IVs of other on-going communication. This will ensure cryptographic synchronization is maintained for existing communications and the Informational Exchange will be processed correctly. The only exception to this is when the Commit Bit of the ISAKMP Header is set. When the Commit Bit is set, the Message ID field of the Informational Exchange MUST contain the Message ID of the original ISAKMP Phase 2 SA negotiation, rather than a new Message ID (MID). This is done to ensure that the Informational Exchange with the CONNECTED Notify Message can be associated with the correct Phase 2 SA. For a description of the Commit Bit, see section 3.1.
5 ISAKMP Payload Processing Section 3 describes the ISAKMP payloads. These payloads are used in the exchanges described in section 4 and can be used in exchanges defined for a specific DOI. This section describes the processing for each of the payloads. This section suggests the logging of events to a system audit file. This action is controlled by a system security policy and is, therefore, only a suggested action. 5.1 General Message Processing Every ISAKMP message has basic processing applied to insure protocol reliability, and to minimize threats, such as denial of service and replay attacks. All processing SHOULD include packet length checks to insure the packet received is at least as long as the length given in the ISAKMP Header. If the ISAKMP message length and the value in the Payload Length field of the ISAKMP Header are not the same, then the ISAKMP message MUST be rejected. The receiving entity (initiator or responder) MUST do the following: 1. The event, UNEQUAL PAYLOAD LENGTHS, MAY be logged in the appropriate system audit file. 2. An Informational Exchange with a Notification payload containing the UNEQUAL-PAYLOAD-LENGTHS message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. When transmitting an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following: 1. Set a timer and initialize a retry counter. NOTE: Implementations MUST NOT use a fixed timer. Instead, transmission timer values should be adjusted dynamically based on measured round trip times. In addition, successive retransmissions of the same packet should be separated by increasingly longer time intervals (e.g., exponential backoff). 2. If the timer expires, the ISAKMP message is resent and the retry counter is decremented. 3. If the retry counter reaches zero (0), the event, RETRY LIMIT REACHED, MAY be logged in the appropriate system audit file. 4. The ISAKMP protocol machine clears all states and returns to IDLE.
5.2 ISAKMP Header Processing When creating an ISAKMP message, the transmitting entity (initiator or responder) MUST do the following: 1. Create the respective cookie. See section 2.5.3 for details. 2. Determine the relevant security characteristics of the session (i.e. DOI and situation). 3. Construct an ISAKMP Header with fields as described in section 3.1. 4. Construct other ISAKMP payloads, depending on the exchange type. 5. Transmit the message to the destination host as described in section5.1. When an ISAKMP message is received, the receiving entity (initiator or responder) MUST do the following: 1. Verify the Initiator and Responder "cookies". If the cookie validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID COOKIE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-COOKIE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Check the Next Payload field to confirm it is valid. If the Next Payload field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-PAYLOAD-TYPE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Check the Major and Minor Version fields to confirm they are correct (see section 3.1). If the Version field validation fails, the message is discarded and the following actions are
taken:
(a) The event, INVALID ISAKMP VERSION, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-MAJOR-VERSION or INVALID-MINOR-
VERSION message type MAY be sent to the transmitting entity.
This action is dictated by a system security policy.
4. Check the Exchange Type field to confirm it is valid. If the
Exchange Type field validation fails, the message is discarded
and the following actions are taken:
(a) The event, INVALID EXCHANGE TYPE, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-EXCHANGE-TYPE message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
5. Check the Flags field to ensure it contains correct values. If
the Flags field validation fails, the message is discarded and
the following actions are taken:
(a) The event, INVALID FLAGS, MAY be logged in the appropriate
systemaudit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-FLAGS message type MAY be sent to the
transmitting entity. This action is dictated by a system
security policy.
6. Check the Message ID field to ensure it contains correct values.
If the Message ID validation fails, the message is discarded and
the following actions are taken:
(a) The event, INVALID MESSAGE ID, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-MESSAGE-ID message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
7. Processing of the ISAKMP message continues using the value in the
Next Payload field.
5.3 Generic Payload Header Processing When creating any of the ISAKMP Payloads described in sections 3.4 through 3.15 a Generic Payload Header is placed at the beginning of these payloads. When creating the Generic Payload Header, the transmitting entity (initiator or responder) MUST do the following: 1. Place the value of the Next Payload in the Next Payload field. These values are described in section 3.1. 2. Place the value zero (0) in the RESERVED field. 3. Place the length (in octets) of the payload in the Payload Length field. 4. Construct the payloads as defined in the remainder of this section. When any of the ISAKMP Payloads are received, the receiving entity (initiator or responder) MUST do the following: 1. Check the Next Payload field to confirm it is valid. If the Next Payload field validation fails, the message is discarded and the following actions are taken: (a) The event, INVALID NEXT PAYLOAD, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-PAYLOAD-TYPE message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Verify the RESERVED field contains the value zero. If the value in the RESERVED field is not zero, the message is discarded and the following actions are taken: (a) The event, INVALID RESERVED FIELD, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Process the remaining payloads as defined by the Next Payload field.
5.4 Security Association Payload Processing When creating a Security Association Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Domain of Interpretation for which this negotiation is being performed. 2. Determine the situation within the determined DOI for which this negotiation is being performed. 3. Determine the proposal(s) and transform(s) within the situation. These are described, respectively, in sections 3.5 and 3.6. 4. Construct a Security Association payload. 5. Transmit the message to the receiving entity as described in section 5.1. When a Security Association payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Domain of Interpretation (DOI) is supported. If the DOI determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID DOI, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the DOI-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Determine if the given situation can be protected. If the Situation determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID SITUATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the SITUATION-NOT-SUPPORTED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 3. Process the remaining payloads (i.e. Proposal, Transform) of the Security Association Payload. If the Security Association
Proposal (as described in sections 5.5 and 5.6) is not accepted,
then the following actions are taken:
(a) The event, INVALID PROPOSAL, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the NO-PROPOSAL-CHOSEN message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
5.5 Proposal Payload Processing
When creating a Proposal Payload, the transmitting entity (initiator
or responder) MUST do the following:
1. Determine the Protocol for this proposal.
2. Determine the number of proposals to be offered for this protocol
and the number of transforms for each proposal. Transforms are
described in section 3.6.
3. Generate a unique pseudo-random SPI.
4. Construct a Proposal payload.
When a Proposal payload is received, the receiving entity (initiator
or responder) MUST do the following:
1. Determine if the Protocol is supported. If the Protocol-ID field
is invalid, the payload is discarded and the following actions
are taken:
(a) The event, INVALID PROTOCOL, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-PROTOCOL-ID message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
2. Determine if the SPI is valid. If the SPI is invalid, the
payload is discarded and the following actions are taken:
(a) The event, INVALID SPI, MAY be logged in the appropriate
system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-SPI message type MAY be sent to the
transmitting entity. This action is dictated by a system
security policy.
3. Ensure the Proposals are presented according to the details given
in section 3.5 and 4.2. If the proposals are not formed
correctly, the following actions are taken:
(a) Possible events, BAD PROPOSAL SYNTAX, INVALID PROPOSAL, are
logged in the appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the BAD-PROPOSAL-SYNTAX or PAYLOAD-MALFORMED
message type MAY be sent to the transmitting entity. This
action is dictated by a system security policy.
4. Process the Proposal and Transform payloads as defined by the
Next Payload field. Examples of processing these payloads are
given in section 4.2.1.
5.6 Transform Payload Processing
When creating a Transform Payload, the transmitting entity (initiator
or responder) MUST do the following:
1. Determine the Transform # for this transform.
2. Determine the number of transforms to be offered for this
proposal. Transforms are described in sections 3.6.
3. Construct a Transform payload.
When a Transform payload is received, the receiving entity (initiator
or responder) MUST do the following:
1. Determine if the Transform is supported. If the Transform-ID
field contains an unknown or unsupported value, then that
Transform payload MUST be ignored and MUST NOT cause the
generation of an INVALID TRANSFORM event. If the Transform-ID
field is invalid, the payload is discarded and the following
actions are taken:
(a) The event, INVALID TRANSFORM, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-TRANSFORM-ID message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
2. Ensure the Transforms are presented according to the details
given in section 3.6 and 4.2. If the transforms are not formed
correctly, the following actions are taken:
(a) Possible events, BAD PROPOSAL SYNTAX, INVALID TRANSFORM,
INVALID ATTRIBUTES, are logged in the appropriate system
audit file.
(b) An Informational Exchange with a Notification payload
containing the BAD-PROPOSAL-SYNTAX, PAYLOAD-MALFORMED or
ATTRIBUTES-NOT-SUPPORTED message type MAY be sent to the
transmitting entity. This action is dictated by a system
security policy.
3. Process the subsequent Transform and Proposal payloads as defined
by the Next Payload field. Examples of processing these payloads
are given in section 4.2.1.
5.7 Key Exchange Payload Processing
When creating a Key Exchange Payload, the transmitting entity
(initiator or responder) MUST do the following:
1. Determine the Key Exchange to be used as defined by the DOI.
2. Determine the usage of the Key Exchange Data field as defined by
the DOI.
3. Construct a Key Exchange payload.
4. Transmit the message to the receiving entity as described in
section 5.1.
When a Key Exchange payload is received, the receiving entity
(initiator or responder) MUST do the following:
1. Determine if the Key Exchange is supported. If the Key Exchange
determination fails, the message is discarded and the following
actions are taken:
(a) The event, INVALID KEY INFORMATION, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-KEY-INFORMATION message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
5.8 Identification Payload Processing
When creating an Identification Payload, the transmitting entity
(initiator or responder) MUST do the following:
1. Determine the Identification information to be used as defined by
the DOI (and possibly the situation).
2. Determine the usage of the Identification Data field as defined
by the DOI.
3. Construct an Identification payload.
4. Transmit the message to the receiving entity as described in
section 5.1.
When an Identification payload is received, the receiving entity
(initiator or responder) MUST do the following:
1. Determine if the Identification Type is supported. This may be
based on the DOI and Situation. If the Identification
determination fails, the message is discarded and the following
actions are taken:
(a) The event, INVALID ID INFORMATION, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-ID-INFORMATION message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
5.9 Certificate Payload Processing
When creating a Certificate Payload, the transmitting entity
(initiator or responder) MUST do the following:
1. Determine the Certificate Encoding to be used. This may be
specified by the DOI.
2. Ensure the existence of a certificate formatted as defined by the
Certificate Encoding.
3. Construct a Certificate payload.
4. Transmit the message to the receiving entity as described in
section 5.1.
When a Certificate payload is received, the receiving entity
(initiator or responder) MUST do the following:
1. Determine if the Certificate Encoding is supported. If the
Certificate Encoding is not supported, the payload is discarded
and the following actions are taken:
(a) The event, INVALID CERTIFICATE TYPE, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-CERT-ENCODING message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
2. Process the Certificate Data field. If the Certificate Data is
invalid or improperly formatted, the payload is discarded and the
following actions are taken:
(a) The event, INVALID CERTIFICATE, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-CERTIFICATE message type MAY be sent
to the transmitting entity. This action is dictated by a
system security policy.
5.10 Certificate Request Payload Processing
When creating a Certificate Request Payload, the transmitting entity
(initiator or responder) MUST do the following:
1. Determine the type of Certificate Encoding to be requested. This
may be specified by the DOI.
2. Determine the name of an acceptable Certificate Authority which
is to be requested (if applicable).
3. Construct a Certificate Request payload.
4. Transmit the message to the receiving entity as described in
section 5.1.
When a Certificate Request payload is received, the receiving entity
(initiator or responder) MUST do the following:
1. Determine if the Certificate Encoding is supported. If the
Certificate Encoding is invalid, the payload is discarded and the
following actions are taken:
(a) The event, INVALID CERTIFICATE TYPE, MAY be logged in
the appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-CERT-ENCODING message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
If the Certificate Encoding is not supported, the payload is
discarded and the following actions are taken:
(a) The event, CERTIFICATE TYPE UNSUPPORTED, MAY be logged in
the appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the CERT-TYPE-UNSUPPORTED message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
2. Determine if the Certificate Authority is supported for the
specified Certificate Encoding. If the Certificate Authority is
invalid or improperly formatted, the payload is discarded and the
following actions are taken:
(a) The event, INVALID CERTIFICATE AUTHORITY, MAY be logged in
the appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-CERT-AUTHORITY message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
3. Process the Certificate Request. If a requested Certificate Type
with the specified Certificate Authority is not available, then
the payload is discarded and the following actions are taken:
(a) The event, CERTIFICATE-UNAVAILABLE, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the CERTIFICATE-UNAVAILABLE message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
5.11 Hash Payload Processing When creating a Hash Payload, the transmitting entity (initiator or responder) MUST do the following: 1. Determine the Hash function to be used as defined by the SA negotiation. 2. Determine the usage of the Hash Data field as defined by the DOI. 3. Construct a Hash payload. 4. Transmit the message to the receiving entity as described in section 5.1. When a Hash payload is received, the receiving entity (initiator or responder) MUST do the following: 1. Determine if the Hash is supported. If the Hash determination fails, the message is discarded and the following actions are taken: (a) The event, INVALID HASH INFORMATION, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the INVALID-HASH-INFORMATION message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 2. Perform the Hash function as outlined in the DOI and/or Key Exchange protocol documents. If the Hash function fails, the message is discarded and the following actions are taken: (a) The event, INVALID HASH VALUE, MAY be logged in the appropriate system audit file. (b) An Informational Exchange with a Notification payload containing the AUTHENTICATION-FAILED message type MAY be sent to the transmitting entity. This action is dictated by a system security policy. 5.12 Signature Payload Processing When creating a Signature Payload, the transmitting entity (initiator or responder) MUST do the following:
1. Determine the Signature function to be used as defined by the SA
negotiation.
2. Determine the usage of the Signature Data field as defined by the
DOI.
3. Construct a Signature payload.
4. Transmit the message to the receiving entity as described in
section 5.1.
When a Signature payload is received, the receiving entity (initiator
or responder) MUST do the following:
1. Determine if the Signature is supported. If the Signature
determination fails, the message is discarded and the following
actions are taken:
(a) The event, INVALID SIGNATURE INFORMATION, MAY be logged in
the appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the INVALID-SIGNATURE message type MAY be sent to
the transmitting entity. This action is dictated by a
system security policy.
2. Perform the Signature function as outlined in the DOI and/or Key
Exchange protocol documents. If the Signature function fails,
the message is discarded and the following actions are taken:
(a) The event, INVALID SIGNATURE VALUE, MAY be logged in the
appropriate system audit file.
(b) An Informational Exchange with a Notification payload
containing the AUTHENTICATION-FAILED message type MAY be
sent to the transmitting entity. This action is dictated by
a system security policy.
5.13 Nonce Payload Processing
When creating a Nonce Payload, the transmitting entity (initiator or
responder) MUST do the following:
1. Create a unique random value to be used as a nonce.
2. Construct a Nonce payload.
3. Transmit the message to the receiving entity as described in
section 5.1.
When a Nonce payload is received, the receiving entity (initiator or
responder) MUST do the following:
1. There are no specific procedures for handling Nonce payloads.
The procedures are defined by the exchange types (and possibly
the DOI and Key Exchange descriptions).
5.14 Notification Payload Processing
During communications it is possible that errors may occur. The
Informational Exchange with a Notify Payload provides a controlled
method of informing a peer entity that errors have occurred during
protocol processing. It is RECOMMENDED that Notify Payloads be sent
in a separate Informational Exchange rather than appending a Notify
Payload to an existing exchange.
When creating a Notification Payload, the transmitting entity
(initiator or responder) MUST do the following:
1. Determine the DOI for this Notification.
2. Determine the Protocol-ID for this Notification.
3. Determine the SPI size based on the Protocol-ID field. This
field is necessary because different security protocols have
different SPI sizes. For example, ISAKMP combines the Initiator
and Responder cookie pair (16 octets) as a SPI, while ESP and AH
have 4 octet SPIs.
4. Determine the Notify Message Type based on the error or status
message desired.
5. Determine the SPI which is associated with this notification.
6. Determine if additional Notification Data is to be included.
This is additional information specified by the DOI.
7. Construct a Notification payload.
8. Transmit the message to the receiving entity as described in
section 5.1.
Because the Informational Exchange with a Notification payload is a
unidirectional message a retransmission will not be performed. The
local security policy will dictate the procedures for continuing.
However, we RECOMMEND that a NOTIFICATION PAYLOAD ERROR event be
logged in the appropriate system audit file by the receiving entity.
If the Informational Exchange occurs prior to the exchange of keying
material during an ISAKMP Phase 1 negotiation there will be no
protection provided for the Informational Exchange. Once the keying
material has been exchanged or the ISAKMP SA has been established,
the Informational Exchange MUST be transmitted under the protection
provided by the keying material or the ISAKMP SA.
When a Notification payload is received, the receiving entity
(initiator or responder) MUST do the following:
1. Determine if the Informational Exchange has any protection
applied to it by checking the Encryption Bit and the
Authentication Only Bit in the ISAKMP Header. If the Encryption
Bit is set, i.e. the Informational Exchange is encrypted, then
the message MUST be decrypted using the (in-progress or
completed) ISAKMP SA. Once the decryption is complete the
processing can continue as described below. If the
Authentication Only Bit is set, then the message MUST be
authenticated using the (in-progress or completed) ISAKMP SA.
Once the authentication is completed, the processing can continue
as described below. If the Informational Exchange is not
encrypted or authentication, the payload processing can continue
as described below.
2. Determine if the Domain of Interpretation (DOI) is supported. If
the DOI determination fails, the payload is discarded and the
following action is taken:
(a) The event, INVALID DOI, MAY be logged in the appropriate
system audit file.
3. Determine if the Protocol-Id is supported. If the Protocol-Id
determination fails, the payload is discarded and the following
action is taken:
(a) The event, INVALID PROTOCOL-ID, MAY be logged in the
appropriate system audit file.
4. Determine if the SPI is valid. If the SPI is invalid, the
payload is discarded and the following action is taken:
(a) The event, INVALID SPI, MAY be logged in the appropriate
system audit file.
5. Determine if the Notify Message Type is valid. If the Notify
Message Type is invalid, the payload is discarded and the
following action is taken:
(a) The event, INVALID MESSAGE TYPE, MAY be logged in the
appropriate system audit file.
6. Process the Notification payload, including additional
Notification Data, and take appropriate action, according to
local security policy.
5.15 Delete Payload Processing
During communications it is possible that hosts may be compromised or
that information may be intercepted during transmission. Determining
whether this has occurred is not an easy task and is outside the
scope of this memo. However, if it is discovered that transmissions
are being compromised, then it is necessary to establish a new SA and
delete the current SA.
The Informational Exchange with a Delete Payload provides a
controlled method of informing a peer entity that the transmitting
entity has deleted the SA(s). Deletion of Security Associations MUST
always be performed under the protection of an ISAKMP SA. The
receiving entity SHOULD clean up its local SA database. However,
upon receipt of a Delete message the SAs listed in the Security
Parameter Index (SPI) field of the Delete payload cannot be used with
the transmitting entity. The SA Establishment procedure must be
invoked to re-establish secure communications.
When creating a Delete Payload, the transmitting entity (initiator or
responder) MUST do the following:
1. Determine the DOI for this Deletion.
2. Determine the Protocol-ID for this Deletion.
3. Determine the SPI size based on the Protocol-ID field. This
field is necessary because different security protocols have
different SPI sizes. For example, ISAKMP combines the Initiator
and Responder cookie pair (16 octets) as a SPI, while ESP and AH
have 4 octet SPIs.
4. Determine the # of SPIs to be deleted for this protocol.
5. Determine the SPI(s) which is (are) associated with this
deletion.
6. Construct a Delete payload.
7. Transmit the message to the receiving entity as described in
section 5.1.
Because the Informational Exchange with a Delete payload is a
unidirectional message a retransmission will not be performed. The
local security policy will dictate the procedures for continuing.
However, we RECOMMEND that a DELETE PAYLOAD ERROR event be logged in
the appropriate system audit file by the receiving entity.
As described above, the Informational Exchange with a Delete payload
MUST be transmitted under the protection provided by an ISAKMP SA.
When a Delete payload is received, the receiving entity (initiator or
responder) MUST do the following:
1. Because the Informational Exchange is protected by some security
service (e.g. authentication for an Auth-Only SA, encryption for
other exchanges), the message MUST have these security services
applied using the ISAKMP SA. Once the security service processing
is complete the processing can continue as described below. Any
errors that occur during the security service processing will be
evident when checking information in the Delete payload. The
local security policy SHOULD dictate any action to be taken as a
result of security service processing errors.
2. Determine if the Domain of Interpretation (DOI) is supported. If
the DOI determination fails, the payload is discarded and the
following action is taken:
(a) The event, INVALID DOI, MAY be logged in the appropriate
system audit file.
3. Determine if the Protocol-Id is supported. If the Protocol-Id
determination fails, the payload is discarded and the following
action is taken:
(a) The event, INVALID PROTOCOL-ID, MAY be logged in the
appropriate system audit file.
4. Determine if the SPI is valid for each SPI included in the Delete
payload. For each SPI that is invalid, the following action is
taken:
(a) The event, INVALID SPI, MAY be logged in the appropriate
system audit file.
5. Process the Delete payload and take appropriate action, according
to local security policy. As described above, one appropriate
action SHOULD include cleaning up the local SA database.
(page 75 continued on part 4)
