issue with preauth processing

Nicolas Williams Nicolas.Williams at
Mon Oct 26 16:26:57 EDT 2009

On Mon, Oct 26, 2009 at 04:03:01PM -0400, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at> writes:
>     Nicolas> On Mon, Oct 26, 2009 at 02:33:45PM -0400, Sam Hartman wrote:
>     Nicolas> Second, I think it's fair for an application to want to
>     Nicolas> avoid the "no pre-auth" and "plain PA-ENC-TIMESTAMP"
>     Nicolas> methods, even if the KDC might allow it, in which case
>     Nicolas> you'd want the system to try all other pre-auth methods
>     Nicolas> available.
>     >> 
>     >> I agree.  I don't think that is what the current interface was
>     >> intended to be though.
>     Nicolas> I know.  I'm not sure that changing this semantic now
>     Nicolas> would break anything, but then, I also agree with this:
> It would for example break someone using enc-ts for optimistic
> pre-auth who upgrades to FAST and then sholud be using enc-challenge.

It's not clear to me that this was intended to be for optimistic
purposes.  But yes, assuming it was, then the addition of new
password-based pre-auth would, indeed, break apps that wanted plain
PA-ENC-TIMESTAMP as an optimistic choice.

Still, it doesn't matter, we should just add the additional options that
we need and move on.


More information about the krbdev mailing list