[krbdev.mit.edu #8654] Prevent fallback from SPAKE to encrypted timestamp

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[krbdev.mit.edu #8654] Prevent fallback from SPAKE to encrypted timestamp

Greg Hudson via RT-2
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
suppression mechanism.
_______________________________________________
krb5-bugs mailing list
[hidden email]
https://mailman.mit.edu/mailman/listinfo/krb5-bugs