ELVIS-PLUS

RU svan@elvis.ru

Cloudflare

US chrispatton+ietf@gmail.com

This document describes an extension to the Internet Key Exchange protocol version 2 (IKEv2) that prevents particular downgrade attacks on this protocol by having the peers confirm they have participated in the same conversation. This document updates RFC 7296.

The Internet Key Exchange version 2 protocol (IKEv2) provides authenticated key exchange in the IP Security (IPsec) architecture. The cryptographic design of IKEv2 is based on the SIGn-and-MAc (SIGMA) protocol . The protocol allows peers to mutually authenticate themselves and to derive session keys that are used to protect traffic. This document modifies the way peers construct the data to be authenticated in IKEv2, and thus updates RFC 7296. (RFC EDITOR: Please remove this paragraph.) This document is being developed at .

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. It is assumed that readers are familiar with the IKEv2 protocol .

The details of how authentication is performed in IKEv2 are defined in Section 2.15 of IKEv2 . Peers sign (or MAC) some blocks of data that consist of various parts of protocol data (see also SIGMA for the rationale). The definition of these blocks of data is provided below for convenience. The initiator's signed octets can be described as:

The responder's signed octets can be described as:

In particular, the initiator, but not the responder, authenticates the IKE_SA_INIT request (RealMessage1) and the responder, but not the initiator, authenticates the IKE_SA_INIT response (RealMessage2). Thus, each side authenticates only the initial message it has sent and not the initial message it has received.

The way authentication is performed in IKEv2 allows at least two kinds of downgrade attacks. The first of these is a key-compromise impersonation (KCI) attack and requires a set of preconditions that are not common, but still plausible. In particular:

1. The attacker must be on the path with the ability to intercept communications between the peers and to modify their messages.
2. Security policies for both initiator and responder must include both "strong" and "weak" key exchange methods and the attacker must be able to break "weak" key exchange methods in real time.
3. The attacker must either have a long-term authentication key for one of the peers or must be able to break the authentication algorithm used by one of the peers in real time.

Having these preconditions the goal of the attacker is to eavesdrop on communication between the peers. While the attack requires impersonating one of these peers to the other, impersonation is not its primary goal. In case the attacker knows the initiator's long-term authentication key, the attack can be mounted as follows.

1. The initiator sends the IKE_SA_INIT request message with a list of proposed algorithms that includes both "weak" and "strong" key exchange methods.

   IKE_SA_INIT(SA(strong, weak), KE, Ni) ]]>

2. The attacker intercepts this message and re-injects a modified message without "strong" key exchange methods.

   IKE_SA_INIT(SA(weak), KE, Ni) ]]>

   Note that this may require an additional step for the attack to succeed if the initiator includes a Key Exchange Data value for a "strong" key exchange method in the request. In this case the attacker intercepts this message and responds with the INVALID_KE_PAYLOAD notification indicating that the initiator must include a Key Exchange Data value for a "weak" key exchange method. Then this message is intercepted and re-injected without "strong" key exchange methods.
3. The responder receives this message and selects one of the "weak" key exchange methods (since the message does not include any "strong" ones), then it sends back a response message, which the attacker allows to pass through without modifications.

4. Since the attacker has seen both Key Exchange Data values and can break the selected "weak" key exchange method in real time, it calculates the SK_* session keys that allow the attacker to read and modify the content of the encrypted IKE messages.
5. The initiator receives the IKE_SA_INIT response message, accepts the responder's selected algorithms, including the "weak" key exchange method (since it is allowed by its policy), and starts the IKE_AUTH exchange. It computes the AUTH payload, thus authenticating the IKE_SA_INIT request message it has sent.

   IKE_AUTH(IDi, AUTH, SA, TSi, TSr) ]]>

6. The attacker intercepts this message, decrypts it and modifies the AUTH payload so that it allegedly authenticates the IKE_SA_INIT request message that was modified and injected by the attacker. The attacker is able to do this because it knows the session keys and the initiator's long-term authentication key.

   IKE_AUTH(IDi, AUTH', SA, TSi, TSr) ]]>

7. The responder receives this message, verifies the AUTH payload and sends back the IKE_AUTH response message, which the attacker allows to pass through.

8. At this point the peers have established a connection using the "weak" key exchange method. Note, that this is allowed by their security policies, but without the attacker's intervention they would have used a more secure "strong" key exchange method. The attacker essentially forced the peers to use a "weak" method that it is able to break, thus downgrading the security properties of the connection so that it can read the peers' communication.

A variant of this attack can be mounted if the attacker has the responder’s long-term authentication key. In this case the attacker cannot change the set of algorithms from which the responder makes its choice, but still may be able to force peers not to use some protocol extensions, in particular those that are initially proposed by the responder. The second type of attack is an identity misbinding attack described in "Downgrade Resilience in Key-Exchange Protocols" (IEEE Security & Privacy 2016) . The attacker's goal is once again to eavesdrop on the communication between two peers, but unlike the KCI attack, it does not need to compromise one of the peers. Instead, the attacker only needs to know the long-term authentication key of some party with whom one of the peers is configured to communicate. In particular, suppose the attacker wants to eavesdrop on communication between initiator I and responder R and has access to the long-term authentication key of a different initiator A. The attack works exactly the same way as the previous one, with one exception: after decrypting I's IKE_AUTH request it modifies it by replacing I's identity IDi with A's identity IDa and authenticates the modified request with A's long-term authentication key. At the end of the attack, initiator I will believe it has established a connection with responder R, but responder R will believe it has established a connection with initiator A (whose authentication key is known to the attacker). Nevertheless, the attacker will be able to read the encrypted messages sent between I and R. This attack used to be less relevant when cryptographic algorithms were considered secure or insecure because peers would disable the insecure ones according to their security policy and not negotiate them. On the other hand, the coexistence of old and new algorithms in the post-quantum (or any other) migration makes this attack more relevant. With migration to quantum-resistant algorithms the KCI or identity misbinding attacks could be mounted on a hybrid PQ/T or pure post-quantum key exchange; where an attacker able to break a traditional key exchange method (e.g. by means of a quantum computer) prevents peers from executing quantum-resistant key exchange method(s).

This document defines an IKEv2 extension that detects attempts to mount the downgrade attacks described in . If both peers support this extension and if at least one non-compromised authentication key is used by the peers in the protocol run then:

• An attacker cannot fool any protocol participant that its peer does not support this extension without being detected.
• An attacker cannot modify the IKE_SA_INIT messages without being detected.

If this extension is not supported by both peers, then the IKEv2 negotiation runs as defined in IKEv2 . The idea is that both the IKE_SA_INIT request and the IKE_SA_INIT response messages must be directly authenticated by both peers. Thus, if at least one non-compromised key is used in the IKE SA establishing, then any modification of the IKE_SA_INIT messages will be detected. In particular, for the attacks described in , it is necessary that the attacker forward the responder’s signed octets. Since the attacker is presumed to be incapable of forging a valid signature on behalf of the responder, an attempt by the attacker to remove the responder’s commitment to this extension would invalidate the signature in the AUTH payload. Consequently, while an attacker could strip support for this extension from the initiator, it could not do so from the responder. In essence, the peers use this extension to confirm they have had the same conversation, a property enjoyed by many modern authenticated key exchange protocols that may have other benefits beyond downgrade protection, like TLS 1.3 .

The initiator supporting this extension includes a new status type notification IKE_SA_INIT_FULL_TRANSCRIPT_AUTH in the IKE_SA_INIT request message. The Notify Message Type for this notification is 16447, Protocol ID and SPI Size are both set to 0 and the notification data is empty. If the responder supports this extension then it also includes this notification in the response message regardless of whether it was received in the request or not.

<--- HDR, SAr1, KEr, Nr, [CERTREQ,] N(IKE_SA_INIT_FULL_TRANSCRIPT_AUTH) ]]>

If a peer sent and received the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification, then it uses the modified construction of the blocks of data to be signed (or MAC'ed) compared to the definition from Section 2.15 of IKEv2 :

where RealMessage1, RealMessage2, NonceIData, NonceRData, MACedIDForI and MACedIDForR are defined in Section 2.15 of IKEv2 , and ZeroPrefix is 8 octets of zero. ZeroPrefix serves a role of a domain separator making the new authentication blocks of data always different from authentication blocks of data defined in Section 2.15 of IKEv2 , because in both RealMessage1 and RealMessage2 the first 8 octets constitute IKE Initiator's SPI that can never be zero.

The IKE_INTERMEDIATE exchange also modifies blocks of data to be signed (or MAC'ed). This modification is described in Section 3.3.2 of IKE_INTERMEDIAE exchange and can be summarized as an addition of a new piece of data (IntAuth) to the end of the blocks of data from Section 2.15 of IKEv2 . If peers support extension defined in this document, then they MUST treat modified blocks of data to be signed (or MAC'ed) defined in as replacements for blocks of data defined in Section 2.15 of IKEv2 , so that in case of IKE_INTERMEDIATE the IntAuth is added to these modified blocks.

IKE Session Resumption allows peers to quickly restore IKE SA upon a failure. To be able to do it a security gateway provides a client with session ticket that allows the gateway to restore the IKE SA if this ticket is later presented by the client. IKE Session Resumption contains the list of IKE SA parameters marking each of parameter as either "restored from the ticket" or "re-negotiated at the time of resumption". The information of whether an implementation used the new authentication logic for old SA MUST be stored in the ticket and the implementation MUST act the same way when doing resumption. This means that in the IKE_SESSION_RESUME exchange peers do not send the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification and do not expect it in the received messages. If there is a chance that the state of this feature can be changed during SA inactivity (e.g., a host is upgraded or its configuration was changed), it is RECOMMENDED that the host do not use IKE SA resumption and does a full handshake instead.

The IKEv2 extension defined in this document protects against downgrade attacks on IKEv2 described in . It only provides this protection when both peers implement the extension. The attacks described in this document can also be mitigated by disabling support for weak key exchange methods. Doing so is feasible when the peer is known out-of-band to support strong key exchange methods, but this information may not be available in all deployment scenarios for IKEv2. The attacks can also be mitigated by mixing a pre-shared key into the session key calculation. An attacker that does not know this pre-shared key will be unable to decrypt even if it manages to downgrade the key exchange. However, the use of a pre-shared key is negotiated by one of extensions Mixing Preshared Keys in IKEv2 or Mixing Preshared Keys in the IKE_INTERMEDIATE and CREATE_CHILD_SA Exchanges , and this negotiation is itself subject to downgrade attack. It is therefore necessary for each of the peers to mandate the use of a pre-shared key and abort the connection if negotiation fails.

This document defines new Notify Message Type in the "IKEv2 Notify Message Status Types" registry:

Springer Berlin Heidelberg

Thanks to those who contributed to mailing list discussions that shaped this document. Tero Kivinen suggested adding protocol diagrams for readability, Shubham Kumar discussed applicability of downgrade prevention to IKE session resumption.