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

2017-08-16 Thread David Schinazi
Paul, I understand your concerns, and I do agree with them. However, the proposal isn't meant to solve all issues - the idea is that if we're building a PPK infrastructure already, I believe this is an incremental improvement to it that solves a few more attack vectors without compromising

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

2017-08-16 Thread Christopher Wood
On Wed, Aug 16, 2017 at 9:34 AM, Paul Wouters wrote: > On Mon, 14 Aug 2017, David Schinazi wrote: > >> [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

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

2017-08-16 Thread Paul Wouters
On Mon, 14 Aug 2017, David Schinazi wrote: [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

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

2017-08-14 Thread David Schinazi
Thanks Paul, responses inline. > On Aug 11, 2017, at 18:23, Paul Wouters 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

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

2017-08-11 Thread Paul Wouters
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

[IPsec] Privacy attack vectors against IKEv2 and Postquantum

2017-08-11 Thread David Schinazi
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,