6 Appendix A: Product Behavior

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.

The following tables show the relationships between Microsoft product versions or supplemental software and the roles they perform.

Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.

Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.

<1> Section 1.3: The following Internet Key Exchange Protocol Extensions (defined in [MS-IKEE]) are supported in Windows releases:

• IKE fragmentation

• Fast failover

• Negotiation discovery

• Denial of service protection

<2> Section 1.7:  Windows releases support the following message authentication algorithms.

• NULL [RFC2410]

• HMAC-SHA1-96 [RFC2404]

• HMAC-MD5-96 [RFC2403]

• AES-GMAC [RFC4543] (not supported in Windows Vista)

• SHA-256 [SHA256] (not supported in Windows Vista)

Windows releases support the following encryption algorithms:

• NULL [RFC2410]

• DES-CBC [RFC2405]

• Triple DES-CBC [RFC2451]

• AES-CBC with key sizes of 128, 192, and 256 bits [RFC3602]

• AES-GCM with key sizes of 128, 192, and 256 bits [RFC4106] (not supported in Windows Vista)

Windows releases support the following Diffie-Hellman algorithms:

• The default 768-bit modular exponential (MODP) group [RFC2409]

• The alternate 1024-bit MODP group [RFC2409]

• The 2048-bit MODP group [RFC3526]

• ECP_256 and ECP 384 [ECP]

<3> Section 1.7: The following vendor IDs are supported by the Windows implementation of the Authenticated Internet Protocol.

<4> Section 1.7: The following Vendor ID is sent by the Windows IKEv1 implementation when the initiator or responder supports both IKEv1 and the Authenticated Internet Protocol.

<5> Section 2.1: The UDP ports are not configurable.

<6> Section 2.2.3.1: The Authenticated Internet Protocol logs the failure to the Security Event Log; it does not report the error to the application whose network activity triggered the Authenticated Internet Protocol exchange. For more information about these codes, see [MS-ERREF].

<7> Section 2.2.3.1: Kerberos via proxy authentication is not supported in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

<8> Section 2.2.3.2.2: In Windows implementations, the responder adds 8 bytes of Initialization_Vector after the seqNUM field if the GSS-API exchange has completed. The presence of the Initialization_Vector is indicated by the length of the Crypto payload (16 bytes if the Initialization_Vector is present; otherwise, 8 bytes).

<9> Section 2.2.3.5: This field can take on any Windows error-code value. For more information about these codes, see [MS-ERREF].

<10> Section 3.1: Cryptographic parameters. Windows releases implement the following algorithms.

<11> Section 3.1.1: Kerberos via proxy authentication is not supported in Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2.

<12> Section 3.1.2: Negotiation retransmission timer: The first retransmission occurs after two seconds. The time-out is doubled for each subsequent retransmission up to a maximum of four retransmissions. In the shutdown phase, one retransmission, at most, is performed as described in section 3.1.7.

In Windows 7 and later and in Windows Server 2008 R2 and later, the number of retransmissions of the first negotiation packet sent by the initiator is reduced to 3. Additionally, if in co-existence mode (section 1.7), and the IKEv1 negotiation gets a valid response to its first packet, then AuthIP stops its retransmission timer. If in negotiation discovery mode (see [MS-IKEE] section 1.3.5), and the responder replies with cleartext (TCP or UDP for example), then AuthIP stops its retransmission timer on receiving cleartext for the same connection that caused the initial the AuthIP negotiation.

Notify retransmission timer: The first retransmission occurs after two seconds. The time-out is doubled for each subsequent retransmission up to a maximum of four retransmissions. In the shutdown phase, one retransmission, at most, is performed as described in section 3.1.7.

Authentication retry timer: The first authentication retry is triggered within a negotiation when the current authentication method fails and there are remaining authentication methods (or remaining authentication parameters for the current methods) that can be tried before failing the negotiation. The retry timer expires when all existing authentication methods (and all authentication parameters for each configured authentication method) are exhausted. The timers mentioned in the retry state (section 3.1) are explicitly the negotiation retransmission timer on initiator and the responder time-out timer on responder.

Responder time-out timer: The responder deletes its state if it does not receive a message from the initiator within 60 seconds. The responder sends a NOTIFY_STATUS notify payload.

NAT-T keep-alive timer: The timer expires after 20 seconds.

quick mode rekey timer: The timer expires after 60 seconds and all old QM SAs are deleted. The responder sends a NOTIFY_STATUS notify payload.

<13> Section 3.2.4: The following Vendor ID is sent by the Microsoft IKEv1 implementation when the initiator or responder supports both IKEv1 and the Authenticated Internet Protocol.

<14> Section 3.2.5.1: Windows releases do not verify that the message ID field is zero.

<15> Section 3.3.5.1: Windows releases do not verify that the message ID field is zero.

<16> Section 3.4.5.1: KeyDictationWt is not supported in Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

<17> Section 3.6.5.1: Windows implementations do not verify that the encrypted flag is not set for payloads denoted as HDR in the payload exchange.

<18> Section 3.7.5.1: Windows Vista does not verify that the message ID field is set to one.

<19> Section 3.8.5.1: Windows implementations do not verify that the encrypted flag is not set for payloads denoted as HDR in the payload exchange.

<20> Section 3.8.7.1: Windows implementations do not verify that the encrypted flag is not set for payloads denoted as HDR in the payload exchange.

<21> Section 3.10.4.1: It is possible for the cleartext SYN message to be received before the ESP SYN message. If this scenario occurs, a common practice for the server is to drop both messages, after which the client attempts to reconnect. This reconnection attempt will delay a connection by approximately three seconds. For inbound TCP connections where NAT-T is not enabled, Windows can be configured to decrypt the ESP SYN message and send it up the stack as if it were the cleartext SYN message. By taking this action, the client is not required to reconnect. This behavior is supported by Windows 8.1 with [MSKB-3023555] and by later clients, in addition to Windows Server 2012 R2 with [MSKB-3023555] and by later servers.

<22> Section 4.3: The Authenticated Internet Protocol logs the failure to the Security Event Log. For more information about these codes, see [MS-ERREF].