Michael Richardson writes: > > Tero Kivinen <[email protected]> wrote: > > That is why I think it is important that we do detect the failures > > correctly. > > >> > SK_d provides quantum resistance for the IPsec SAs and Child IKE > >> SAs. > The SK_pi and SK_pr provides key verification, meaning that > >> incorrect > PPKs will result AUTHENTICATION_FAILURE notification, > >> instead of just > wrong keys. > >> > >> Would it be reasonable to create some token/nonce from something > >> before the PPK is mixed in such that we could recognize the different > >> AUTH FAILUREs, or does that create too much of an oracle for testing > >> PPKs? > > > I think it is better to keep the AUTHENTICATION_FAILURE to mean both, > > i.e., not provide an oracle. > > okay, but can we determine the mismatch enough to log it?
Depends how we do it. If we change the SK_pi and SK_pr keys, then no. The key we use for MACedIDFor* is different, and output of that will get to be part of *SignedOctets, thus when responder verifies the signature or the MAC of with secret key it will simply get failure, so there is no way of knowing whether it was PPK failure or whether it was some other failure. This also means there is no way of the attacker to use the timing to find out whether it was PPK failure or other authentication failure, making it safe... If we do some other kind of verification for PPK (for example calculate some separate hash that we send out), then most likely the attacker will also know which kind of authentication failure it was... -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
