Hi everyone,

I'd like to start off by saying that I have read draft-fluhrer-qr-ikev2-04 and 
I really like it, particularly the fact that it is a minor change, does not add 
RTTs and keeps existing properties.

I have however come across two privacy attack vectors that IKEv2 is vulnerable 
to, with and without postquantum, that I think the postquantum draft could also 
help mitigate.

1) Active man-in-the-middle attack against the initiator
An attacker that can intercept and spoof packets can complete the SA_INIT part 
of the exchange with both sides and get the initiator to disclose its IDi (and 
PPK_id). This allows an attacker to fingerprint devices and/or users.

2) Passive off-path attack against a "hidden" responder
Today an IKEv2 server cannot hide the fact that it exists - the initiator's 
SA_INIT is not authenticated so the responder must respond to it even if it is 
forged, leaking the fact that it is running an IKEv2 server. Hypothetically 
speaking, if one were to run IKEv2 over TLS and sharing port 443 with a web 
server to obfuscate the fact that it is using IKEv2, an attacker could open a 
TLS connection and sending an SA_INIT to divulge the fact that this HTTPS 
server also supports IKEv2.

Straw man Proposal:

We slightly change the PPK_SUPPORT status notification payload to include 
notification data, and that data would contain a MAC of the SA_INIT using the 
PPK. Note that this would not contain the PPK_ID, just the MAC. The MAC would 
be defined as
PPK_MAC = prf( prf(PPK, "PPK MAC for IKEv2"), <SAInitOctets>)
where SAInitOctets is the entire SA_INIT, starting with the first octet of the 
first SPI in the header and ending with the last octet of the last payload, 
with PPK_MAC set to all zeroes (this is inspired by the IP header checksum) and 
where prf is the PRF of the first proposal in the SA_INIT.
Both peers MUST send this PPK_MAC on all SA_INIT that contain PPK_SUPPORT.

Upon receiving an SA_INIT, each endpoint has two options:
- if it knows only of a small number of PPKs, it tries all of them and if none 
of them match it silently drops the SA_INIT.
- if it has too many PPKs or if it is worried about DoS attacks, it MAY choose 
to ignore PPK_MAC entirely (and continue the IKEv2 exchange with PPK in the 
IKE_AUTH exchange)

If the responder does not support the PRF from the first initiator's proposal, 
it can either
- ignore PPK_MACi entirely and continue the IKEv2 exchange with PPK in the 
IKE_AUTH exchange
- silently drop the SA_INIT if it was configured to only use a set of PRFs when 
provisioned with the PPK. The initiator can retry with a different PRF.

I believe this proposal does not reduce the security properties of the current 
draft, it also does not leak any information to any party that does not possess 
PPK, and it mitigates the attack vectors discussed above.

What are your thoughts?

David Schinazi

IPsec mailing list

Reply via email to