On Wed, Aug 16, 2017 at 9:34 AM, Paul Wouters <p...@nohats.ca> 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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
