tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 2408

 
 
 

Internet Security Association and Key Management Protocol (ISAKMP)

Part 3 of 4, p. 44 to 75
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 44 
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

Top      Up      ToC       Page 45 
   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.

Top      Up      ToC       Page 46 
   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

Top      Up      ToC       Page 47 
   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

Top      Up      ToC       Page 48 
   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        !

Top      Up      ToC       Page 49 
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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        !

Top      Up      ToC       Page 50 
    /  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.

Top      Up      ToC       Page 51 
   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

Top      Up      ToC       Page 52 
   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.

Top      Up      ToC       Page 53 
                    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

Top      Up      ToC       Page 54 
   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

Top      Up      ToC       Page 55 
   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.

Top      Up      ToC       Page 56 
                        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.

Top      Up      ToC       Page 57 
   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.

Top      Up      ToC       Page 58 
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.

Top      Up      ToC       Page 59 
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

Top      Up      ToC       Page 60 
       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.

Top      Up      ToC       Page 61 
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.

Top      Up      ToC       Page 62 
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

Top      Up      ToC       Page 63 
       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.

Top      Up      ToC       Page 64 
       (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

Top      Up      ToC       Page 65 
            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

Top      Up      ToC       Page 66 
            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.

Top      Up      ToC       Page 67 
   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:

Top      Up      ToC       Page 68 
   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.

Top      Up      ToC       Page 69 
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:

Top      Up      ToC       Page 70 
   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.

Top      Up      ToC       Page 71 
   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.

Top      Up      ToC       Page 72 
   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.

Top      Up      ToC       Page 73 
   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.

Top      Up      ToC       Page 74 
   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.

Top      Up      ToC       Page 75 
   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)

Next RFC Part