[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

Jeffrey Arbuckle via RT
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