Pre-authentication fallback considerations

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

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
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Pre-authentication fallback considerations

Nathaniel McCallum-5
This seems reasonable to me. I support both proposals.

On Tue, Apr 3, 2018 at 7:48 PM, Greg Hudson <[hidden email]> 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             [hidden email]
> https://mailman.mit.edu/mailman/listinfo/krbdev
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|

Re: Pre-authentication fallback considerations

Robbie Harwood
In reply to this post by Greg Hudson
Greg Hudson <[hidden email]> writes:

> 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.
With #2 included, this seems good to me.

Thanks,
--Robbie

_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev

signature.asc (847 bytes) Download Attachment