[IPsec] Privacy attack vectors against IKEv2 and Postquantum
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"), ) 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? Thanks, David Schinazi Apple ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Privacy attack vectors against IKEv2 and Postquantum
On Fri, 11 Aug 2017, David Schinazi wrote: 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. One of the two will have to show ID before the other can make a decision (before revealing itself) if it sees an attacker or a valid endpoint. There have been suggestions in the past (eg BTNS with channel binding) but no one thought it was worth the extra round trips. In theory you could still do this using NULL-AUTH on the client, which authenticates the server without losing any privacy and then running a second authentication to 'upgrade' the client. 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. Maybe we should run DH on all webserver's for IKE :) Straw man Proposal: [...] 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? I think the tor people will tell you that you would still be able to fingerprint this enough to tell it is IKE over TLS. I'd also prefer a mechanism not tied to PPKs. Those are supposed to be a bandaid that wouldn't be used anymore in the future where we have quantum safe algorithms. Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
[IPsec] Preference of ESP over AH in RFC7321bis question.
Hi all, In RFC 7321, we basically said that ESP is preferred over AH. However, that recommendation is not in the current RFC7321bis. Was that an accidental mistake or because people using AH wanted to remove that recommendation ? Thank you, Quynh. ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Preference of ESP over AH in RFC7321bis question.
Hi Dang, My understanding is that the usage of AH vs ESP is outside the scope of recommendations mandatory to implement cryptography. It is mostly a usage concern. In my view AH and ESP are both mandatory to be implemented and RFC7321bis limits its scope to the crypto recommendations. Do you refer to the following text in section 3: """ The IPsec community generally prefers ESP with NULL encryption over AH. """ Yours, Daniel On Fri, Aug 11, 2017 at 10:12 AM, Dang, Quynh (Fed)wrote: > Hi all, > > > In RFC 7321, we basically said that ESP is preferred over AH. However, > that recommendation is not in the current RFC7321bis. > > > Was that an accidental mistake or because people using AH wanted to remove > that recommendation ? > > > Thank you, > > Quynh. > > ___ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Preference of ESP over AH in RFC7321bis question.
On Fri, 11 Aug 2017, Dang, Quynh (Fed) wrote: In RFC 7321, we basically said that ESP is preferred over AH. However, that recommendation is not in the current RFC7321bis. Was that an accidental mistake or because people using AH wanted to remove that recommendation ? Daniel already responded, but let me add that I'd be happy if the WG decides to write a a draft-ipsecme-ah-ipcomp-diediedie :) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
Re: [IPsec] Preference of ESP over AH in RFC7321bis question.
I think that would be a very useful document. Quynh. From: Paul WoutersSent: Friday, August 11, 2017 11:05:59 AM To: Dang, Quynh (Fed) Cc: ipsec@ietf.org Subject: Re: [IPsec] Preference of ESP over AH in RFC7321bis question. On Fri, 11 Aug 2017, Dang, Quynh (Fed) wrote: > In RFC 7321, we basically said that ESP is preferred over AH. However, that > recommendation is not in the current RFC7321bis. > > Was that an accidental mistake or because people using AH wanted to remove > that recommendation ? Daniel already responded, but let me add that I'd be happy if the WG decides to write a a draft-ipsecme-ah-ipcomp-diediedie :) Paul ___ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec