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