Re: Adding support for optimistic preauth to kinit

>>>>> "Ken" == Ken Hornstein <[email protected]> writes:

    >> I think the problem is both harder and easier than this.
    >> 
    >> Each preauth mechanism works differently, and some lend
    >> themselves to optimistic preauth better than others: [...]

    Ken> That's all fair, and I admit that this is kind of the
    Ken> intersection of what's available in terms of the API and the
    Ken> complexity of the preauth code.

    Ken> Really, the REAL goal is to force a particular preauth
    Ken> mechanism.  We have patches to kinit that make it so when kinit
    Ken> is called as "pkinit", it will try PKINIT by default.  The way
    Ken> this is done is by setting the optimistic preauth list.  But
    Ken> that has the sub-optimal behavior of making it that if PKINIT
    Ken> doesn't work, it falls back to a password prompt (well, that
    Ken> happens if PKINIT fails in the context of loading the plugin or
    Ken> some other initial setup fails).

As part of designing FAST and the preauth framework, we kind of accepted
that we were effectively killing off optimistic preauth.  In the
generalized case you might need either the hint data or some other
information from the KDC to get started, and in the general case, once
you've started you cannot really restart (without completily restarting
over and possibly implementing lockout counters).

Also, one of the goals of FAST was to get to a point where after you got
the initial KDC reply you could present all the UI you would ever
present.  Feedback we got on the GUI side was thet models like PAM
keyboard interactive didn't work welll.

I think that having a list of preauth mechanisms the client hopes to use
(or a single mechanism) makes sense,
but  trying to reduce round trips is close to incompatible with other
design constraints that came up with FAST/the preauth framework.
I don't think we forbid anything in the spec, but we definitely
acknowledged that optimistic was going to be nearly impossible in the
general case.

--Sam
_______________________________________________
krbdev mailing list             [email protected]
https://mailman.mit.edu/mailman/listinfo/krbdev