issue with preauth processing
Nicolas.Williams at sun.com
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 sun.com> 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