Pre-authentication fallback considerations

[Nathaniel McCallum]

This seems reasonable to me. I support both proposals.

On Tue, Apr 3, 2018 at 7:48 PM, Greg Hudson <ghudson at mit.edu> wrote:
> 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
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev