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

[Greg Hudson 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.