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.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
