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