Pre-authentication fallback considerations

Robbie Harwood rharwood at
Thu Apr 5 11:47:29 EDT 2018

Greg Hudson <ghudson at> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
Url :

More information about the krbdev mailing list