Pre-authentication fallback considerations

[Greg Hudson]

I am considering implementing the following rules in the client preauth
framework:

1. If a preauth mech reaches the point of generating an authenticated
request, and it fails, do not fall back to another mechanism, and
instead error out.  (This point would be the first client message for
most mechs, but for SPAKE, it would normally be the second client
message as the first message is just a group offer.  Mechs would
indicate when they have reached this point via a new callback.)

2. If a preauth mech is tried optimistically and it fails, do not apply
any special fallback considerations such as trying the same mech again,
or falling back to another mechanism even if #1 applies.

Rationale (apologies for the length):

In most current real-world deployments, a principal is only set up for
one preauth mechanism.  With authentication indicators, we are opening
up the possibility of allowing stronger or weaker authentications
depending on what credentials the client has on hand; however, if we try
a stronger credential and it doesn't work (e.g. a PKINIT client cert is
configured but the KDC doesn't agree that it actually authenticates the
principal), it is perhaps a better user experience to report the failure
than to fall back to the lower-strength mechanism.  (This is especially
the case in the regrettably common situation where a KDC offers both
PKINIT and encrypted timestamp, but the latter is useless becaues the
principal has randomized keys.  That's not really a driving
consideration, as it can usually be corrected at the KDC.)

For security reasons, if we try one-factor SPAKE and the KDC rejects the
SPAKE response message, we should not then try encrypted timestamp.
Implementing rule #1 will take care of this, although we could of course
implement it more narrowly.

We currently have very limited support for optimistic preauth--there is
no way to make it happen with configuration or kinit command-line
options, so the calling application must request it with
krb5_get_init_creds_opt_set_preauth_list(), and there isn't any support
for providing hints (such as etype-info) to mechanisms.  Over the years
there hasn't been much call for more useful optimistic preauth support.
Supporting SPAKE optimistic preauth does seem attractive because its
initial client message requires no guesswork.

RFC 6113 requires clients to try again using KDC-provided pa-data after
a failed optimistic preauth attempt, and we do that as of release 1.16,
including retrying the same mechanism.  But for SPAKE, that special
consideration is purely detrimental; because SPAKE makes no assumptions
in its initial client message, retrying it causes extra work and perhaps
extra increases on the lockout counter for the same result.  We could
add a "no-guesswork optimistic" flag to preauth mechs, but it might be
simpler to just remove the special consideration as we haven't been
doing much with optimistic preauth.

A bit more at:
http://krbdev.mit.edu/rt/Ticket/Display.html?id=8654
http://krbdev.mit.edu/rt/Ticket/Display.html?id=8656