Pre-authentication fallback considerations

[Robbie Harwood]

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.

Thanks,
--Robbie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20180405/57bff550/attachment.bin