Thanks Paul, responses inline. > On Aug 11, 2017, at 18:23, Paul Wouters <p...@nohats.ca> 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
