다음을 통해 공유

3.2.4 Higher-Layer Triggered Events

  • 아티클

When the higher level event described in section 3.1.4 is triggered, it MUST create a main mode security association (MM SA) in its main mode security association database (MMSAD) containing encryption algorithm, hash algorithm, group description, life type, and life duration values and send the first main mode exchange packet with the following form:

Main Mode First Exchange Packet

Figure 4: Main Mode First Exchange Packet

The packet MUST be 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 remaining payloads MUST follow a non-encrypted Crypto payload. If an error has occurred at this stage or before, the responder MUST silently discard the message.

  • Security association (SA): The SA payload MUST be determined by looking up the PAD and the SPD, and constructed in an identical way to the IKE SA payload, as specified in [RFC2408] section 3.4. If a Diffie-Hellman exchange is required by the authentication method (for example, the authentication method is anonymous or the NTLM authentication protocol), the Diffie-Hellman group MUST be the same for all proposals in the SA payload. If a Diffie-Hellman exchange is not required, then the DH attribute in the SA (see [RFC2409] Appendix A, attribute classes) MUST be 0, and the KE payload MUST NOT be present.

  • Auth payload (auth): The Auth payload MUST be constructed by looking up the PAD and the SPD to determine the list of authentication methods that are valid for this negotiation, and including exactly this list of methods.

  • Ni: The initiator Nonce payload MUST be constructed as specified in [RFC2408] section 3.13. Nonces MUST be cryptographically strong random numbers generated by using a [FIPS140]-compliant random-number generator.

  • VID: A sequence of Vendor ID payloads that indicate the capabilities supported. These payloads MUST be constructed as specified in [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: The GSS-API payload is optional. If the initiator already possesses the peer security principal name (for example, by locating it in the SAD), the initiator MUST use the peer security principal name to construct the GSS-API payload as specified in [GSS] and section 2.2.3.1. If on the other hand the initiator does not have the peer security principal name, this payload MUST NOT be sent.

  • [KE]: The GSS-API payload is optional. The KE payload, if included, MUST be identical to the one specified in [RFC2409] section 5. The KE payload MUST be included if the authentication method is anonymous or NTLM. Otherwise, it MUST NOT be included.

After sending the packet, the main mode initiator MUST transition to the Main Mode First Generalized Packet Sent state.

In addition to the message specified above, the initiator MUST also send the first message sent by an IKEv1 initiator, as specified in [RFC2409] section 5. This message SHOULD<13> contain the "MS-MamieExists" IKE Vendor ID payload.

The initiator MUST also set the negotiation retransmission timer for each of these messages (section 3.1.2).