Re: [IPsec] Call for independent experts (IKEv2) for Stage 4 of the PAKE selection process

[Tero Kivinen <[e-mail]>]

Dan Harkins writes:
> > How does the responder know which of the one million username password
> > pairs to pick to generate the generator when calculating D-H in the
> > IKE_SA_INIT? The actual identity of the user is only sent in the
> > encrypted IKE_AUTH message.
> >
> > I.e., I think this has exactly same problem than IKEv1 has with
> > pre-shared keys for main mode. You must know the initiator identity
> > based on the IP-addresses, thus makes this completely unusable for
> > non static VPN cases.
> 
>    HA! I did miss something :-)
> 
>    Yes, I guess a new payload is needed to express the username. This can
> be added to the IKE_SA_INIT message. Or maybe it can be a special type of
> NOTIFY, that's a six-of-one-and-a-half-dozen-of-the-other issue. But this
> should not involve an extra Auth exchange (as the framework PAKEs do)
> since SPEKE is just a Diffie-Hellman exchange which is exactly what IKE
> is.

We had similar discussion in the postquantum preshared keys case,
i.e., we needed to know the identity of the other end to pick the PPK,
but the identity is only transmitted in the IKE_AUTH, and IKE_AUTH is
encrypted with the key which is generated in IKE_SA_INIT. We solved
this issue in qr-ikev2 by making so that encryption of the IKE_AUTH
does not need the PPK, but uses only normal Diffie-Hellman and PPK is
only added to the actual IPsec trafic keys.

The problem is that if we add the identity to the IKE_SA_INIT, then we
loose the identity protection part of the IKEv2, as we then cannot
encrypt the identity.

Current solutions have been trying to keep the identity protection
part as good as it is without those extensions, i.e., qr-ikev2 still
provides same identity protection than what normal IKEv2 does, and
then provides extended protection for the actual trafic keys. Attacker
who can break Diffie-Hellman can see the identities, but will not see
the actual trafic protected by PPK.

With PAKEs, I think it is important to do the same, i.e., keep the
identity protection parts of the IKEv2 at least as good as they are
now, and that usually needs we need to do normal IKEv2 Diffie-Hellman
first to protect identities, and then inside that when we know
identities do the actual authentication using PAKE.

Hybrid qske does things bit differently as it adds IKE_INTERMEDIATE
exchanges between IKE_SA_INIT and IKE_AUTH but all of those
IKE_INTERMEDIATE exchanges are anonymous, i.e., the identity of the
other end is not yet known, the authentication is done in the end with
IKE_AUTH, and only then the identity of the other end is known, and we
can use per user information like shared keys or password etc.
-- 
[e-mail]