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

[Dan Harkins <[e-mail]>]

On 8/30/19 2:27 AM, Tero Kivinen wrote:
> 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.

   Sure we can. We could do the thing that was done in TLS-pwd. When the
client registers his username and password she gets a static DH public
key of the server (TLS-pwd made this be a p256 curve for its compact
representation and adequate strength for the purpose of identity
protection). The scheme then is if the client wants to protect its
identity it uses the server's DH public key and does a static-ephemeral
exchange, gets a secret, encrypts its identity and sends its ephemeral
DH key (in compact representation, it's 33 octets) plus the encrypted
identity in one "identity payload". If it doesn't care about identity
protection it just sends its 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.

Yes, we can do a PAKE exchange after IKE_SA_INIT and use that to do
identity protection. It just does add another round trip and I was trying
to point out how we can get a PAKE mode of IKE without any additional
round trips or things like that. SPEKE is just a Diffie-Hellman and IKE
already does a Diffie-Hellman. With the identity protection scheme I
described above we're doing a 2nd Diffie-Hellman so work-wise it's a
wash but from a protocol standpoint I think it's cleaner.

The qr-ikev2 stuff is done that way but that's because we want to augment
the qr exchange with a traditional D-H. That's the design. There is no
reason to force PAKEs to do the same thing, which isn't to say we can't
just that we don't have to.


   regards,

   Dan.