3.3.5.1 Received Generalize Main Mode First Exchange Response

  • Article

If the responder is not in Start state, when it receives the above packet it MUST tear down the corresponding main mode SA if it can match the packet to an existing main mode, or silently discard the packet otherwise.

Main Mode First Exchange packet

Figure 6: Main Mode First Exchange packet

On receiving a packet in Start state the responder MUST verify that message #1 is formatted as specified in the preceding diagram, and constructed as follows:

  • HDR: The ISAKMP header MUST be identical to the first IKE phase 1 initiator header (see section 2.2.1), except that the exchange type MUST be 243 (main mode exchange type). The Encrypted flag SHOULD NOT be set.

  • The initiator MUST set the encrypted flag to zero.

  • The responder MUST ignore the encrypted flag.

  • The responder MAY<15> verify that the message ID field is zero.

If a receiver encounters any errors in the processing of a message it MUST be treated as an Invalid Message event. See section 3.3.7.1.

Upon receipt, the responder MUST look up its SAD and SPD to determine whether one of the proposals in the SA payload is acceptable. If more than one acceptable proposal is received, then the responder MUST construct the list of (all acceptable) proposals that it would send to this peer if the responder were the initiator, and accept the first proposal on this constructed list that is also in the received SA payload. The responder MUST choose one proposal or none.

If the NATD payloads are present, they MUST be processed as specified in [RFC3947] section 3.2. If the presence of a NAT is detected ([RFC3947] section 3.2), then the isNatPresent setting MUST be set to TRUE (see section 3.1.1).

If the responder encounters no errors in processing message #1, the responder MUST create an MM SA in its MMSAD. The responder MUST update the encryption algorithm, hash algorithm, group description, life type, and life duration values in the MMSAD from the SA payload, and the set of authentication methods in the same MMSAD from the auth payload.

If the "Impersonation Active MM" flag on the MM SA is TRUE, then the responder MUST set the ImpersonationHandle to a locally unique identifier (UID) value that uniquely represents the incoming user.

The responder MUST then transition to Main Mode Responder First Exchange Done state and send a packet out formatted as specified in the following diagram.

Main Mode First Exchange Response packet

Figure 7: Main Mode First Exchange Response packet

The responder MUST construct this message as follows:

  • HDR: The ISAKMP header MUST be identical to the first IKE phase 1 responder packet, except that the exchange type MUST be 243 (MM exchange type). The Encrypted flag MUST not be set.

  • The responder MUST set the message ID value to zero in message #2 (in MM exchange).

  • The remaining payloads MUST follow a nonencrypted Crypto payload.

  • SA: The SA payload MUST contain the accepted proposal, as specified in [RFC2408] section 5.4.

  • Auth: The responder MUST determine which set of the proposed authentication methods is acceptable (by comparing the proposals with the PAD's IKE Peer Authentication Data (see [RFC4301] section 4.4.3.2) and MUST respond with at least one method from that set. To allow for Auth retry, the responder MUST respond with all valid authentication methods. When responding with multiple authentication methods, the responder MUST put the methods in its Auth payload in the same order as they were in the initiator payload.

  • Nr, Nr(qm): The responder nonce and the quick mode responder Nonce payloads. The nonce value generation MUST be performed as specified in [RFC2408] section 3.13.

  • VID: A sequence of Vendor ID payloads that indicate the capabilities supported. See IKE [RFC2408] section 3.16.

  • NATD: NAT discovery payloads. If the IP addresses of the AuthIP peers are IPv4 addresses, these payloads SHOULD be constructed as specified in [RFC3947] section 3.2 and included. If the IP addresses of the AuthIP peers are IPv6 addresses, then these payloads SHOULD NOT be included.

  • GSS-API: If the GSS-API payload was provided in message #1, the responder MUST generate the response GSS_API payload as defined in [GSS]and in section 2.2.3.1. If the GSS_API payload was not provided in message #1, the responder MUST send its security principal name in a GSS_ID payload.

  • GSS_ID: The responder security principal name, if a GSS-API payload was not present in message #1.

  • KE: The KE payload, if requested by the initiator. The KE payload MUST be constructed as specified in IKE [RFC2408] section 3.13.