[krbdev.mit.edu #8654] Prevent fallback from SPAKE to encrypted timestamp
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
* 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
* 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
krb5-bugs mailing list
[hidden email] https://mailman.mit.edu/mailman/listinfo/krb5-bugs