Pre-authentication fallback considerations
rharwood at redhat.com
Thu Apr 5 11:47:29 EDT 2018
Greg Hudson <ghudson at mit.edu> 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
Size: 832 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20180405/57bff550/attachment.bin
More information about the krbdev