Adding support for optimistic preauth to kinit
Sam Hartman
hartmans at suchdamage.org
Mon Apr 26 07:46:30 EDT 2021
>>>>> "Ken" == Ken Hornstein <kenh at cmf.nrl.navy.mil> 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
More information about the krbdev
mailing list