Re: [IPsec] Privacy attack vectors against IKEv2 and Postquantum

[David Schinazi <[e-mail]>]

Thanks Paul, responses inline.

> On Aug 11, 2017, at 18:23, Paul Wouters <[e-mail]> wrote:
> 
> 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.

[DS] I think "showing ID" is exactly what we're avoiding here. You can think of this in terms of the Socialist Millionaire Problem - we want to be able to assert identity without anyone disclosing anything first. And the proposed solution is to send a MAC without the identity of the key used to MAC. Peers can than iterate their list of peers to check the MAC against.

>> 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.

[DS] Some security is still better than less security, you can imagine timing attacks and such but this is better than what we have today.

> 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.

[DS] I was initially going to make this a separate proposal that only involved a pre shared key and SA_INIT MAC, but it was pointed out to me that once you have that might as well include the benefits of PPK. If you know of a way to solve the described privacy attack vectors without a pre shared key and without adding round trips, I'm interested - I couldn't come up with one myself.

David