[krbdev.mit.edu #8654] Prevent fallback from SPAKE to encrypted timestamp
The SPAKE draft security considerations states "Client
implementations SHOULD assume that encrypted timestamp and encrypted
challenge are unlikely to succeed if SPAKE pre-authentication fails
in the second pass and no second factor was used." Otherwise, when
an incorrect password is used with SPAKE, the client unnecessarily
offers a dictionary-attackable ciphertext to the network.
The SPAKE module should set a flag when it sends a single-factor
response, probably via a new callback. The encrypted timestamp and
encrypted challenge modules should check this flag and error out.
To be determined:
* What should the callback name be?
* Should it also affect SAM-2? SAM-2 begins with a dictionary-
attackable ciphertext from the KDC, so it probably doesn't help for
us to suppress it.
* It also doesn't seem right to fall back from a two-factor SPAKE
attempt to encrypted timestamp. Falling back to single-factor SPAKE
would be strictly better (but not trivial to engineer); failing out
entirely seems maybe more appropriate. In general, if we get as far
as using credentials to send a request in one preauth mechanism,
falling back to another seems questionable; for instance, PKINIT
rejections manifesting as password requests has never been a great
user experience. So we might give thought to a more general fallback
krb5-bugs mailing list
[hidden email] https://mailman.mit.edu/mailman/listinfo/krb5-bugs