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

[Christopher Wood <[e-mail]>]

On Wed, Aug 16, 2017 at 9:34 AM, Paul Wouters <[e-mail]> 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 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.
>
>
> But when you are using X.509 based clients, you will have never seen the
> cert/ID until you receive it via IKE ? So your use case is limited to
> very static type deployments (which suffer less from this issue as they
> tend to not move around)
>
>> [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.
>
>
> But I think we would need something a little better to make it part of
> an RFC standard.
>
>> [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.
>
>
> A PreSharedKey based solution is also very limiting, and people should
> be migrating away from PSK in favour of RSA/ECC based solutions :P

David's original email suggested that this technique was enabled by
(and perhaps constrained to) draft-fluhrer-qr-ikev2, which assumes the
existence of a long-term PPK.

Best,
Chris