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

[Greg Hudson via RT]

Some thoughts on preauth fallback in various specific scenarios:

* If the client attempts optimistic encrypted timestamp (or 
challenge), and fails, trying again with the correct etype-info 
(presented with PREAUTH_FAILED, or obtained with an unauthenticated 
request) might succeed, although if the password was wrong, there 
could be two increments on the lockout counter.  The current preauth 
framework resets the list of failed preauth mechanisms after 
optimistic preauth fails in order to support cases like this.

* If the client attempts optimistic SPAKE and it fails, trying again 
with the same user input won't help, since the initial SPAKE support 
message doesn't require any guesses.  So the reset behavior mentioned 
above is purely detrimental when applied to client optimistic SPAKE.

* If the KDC offers PKINIT and something else (like encrypted 
timestamp, or SPAKE, or both), and the client doesn't have any PKINIT 
configuration, falling back to the other things is crucial, as this 
could easily just be a client principal that uses PKINIT (or, less 
commonly, a client principal that can do either PKINIT or password 
auth, and this device doesn't have the client cert so we should do 
password auth).

* On the other hand, if the client has PKINIT configuration and it's 
wrong enough that no request can be generated, erroring out with a 
message about the misconfiguration might be a better user experience 
than trying something else.  It's hard to reliably make a good 
decision here as erroring out effectively locks the client out of 
authenticating when it otherwise might be able to.

* If the client actually makes a PKINIT request and gets a KDC 
failure, erroring out seems more likely to be useful than trying 
something else like password auth, although there might be 
exceptions.

* A 1FA-authenticated SPAKE request should not be followed with an 
encrypted timestamp request (the point of this ticket).

* If we're going to follow up actual failed attempts at 
preauthenticating (as distinct from, say, PKINIT having no client 
configuration, or SPAKE failing due to group/factor negotiation) with 
attempts using other mechanisms, following up 2FA SPAKE with 1FA 
SPAKE or a different factor type makes just as much sense, although 
our preauth framework won't currently allow it.

* If we're not going to follow up failed attempts with other 
mechanisms, it might be nice to have a way to skip a preauth mech so 
that we try the next one (e.g. to skip PKINIT so we can try password 
auth).