Authdata, preauth plugin headers

Greg Hudson ghudson at MIT.EDU
Thu Jun 9 12:25:59 EDT 2011


I've received no feedback that the existing preauth plugin interface
should be considered implicitly public, so for the moment I'm going to
assume that it's okay to make backward-incompatible changes for 1.10
before making the interface public (along with the authdata interface).
At a high level, here is the backlog of changes I think we want to
consider for preauth:

1. Use the new plugin framework.  Doing this will make it easier to make
backward-compatible extensions to the interface in the future.  We'll
need to add some kind of auto-registration mechanism for pkinit, to
avoid adding to the configuration necessary to get it working.

2. Provide a way to get and set the cookie.  Not sure what constraints
we want here to control the interaction of different plugins.  Linus,
why do you need to set the cookie?  I don't see anything about it in the
OTP draft.

3. Maybe make it possible for a preauth plugin to compute a reply key
after the service ticket is finalized (currently padata is produced
before authdata, and there are reasons why that's kind of necessary, but
the reply key could be computed after).  This would make it possible to
implement things like the current form of the PKINIT hash agility draft,
although I think we succeeded in changing the draft to make it
unnecessary.

4. Support asynchronous operation for at least KDC plugins.  How this
works will depend on how Nathaniel's work condenses, so it might not be
in the first pass depending on timing.

5. Maybe change to how error data is generated.  I'll need Sam's input
here.  Currently, plugins produce an arbitrary blob of e-data to be
placed in errors.  FAST requires preauth mechanism error data to be
padata.  PKINIT specifies that its errors come packaged as typed-data,
which walks and talks like padata but has a different ASN.1 tag.  What
we do right now is try to decode the e-data as padata, then try to
decode it as typed-data and convert for FAST.  Maybe there's a way we
can do better, although I'm not really sure how.

I hadn't really allocated any time to work on this when considering 1.10
deliverables, so I also need to minimize effort and design uncertainty.
So it's possible that some of this will get punted just for lack of
time.  As long as we can switch to using the new plugin framework, it
should be easier to make backward-compatible changes after 1.10.





More information about the krbdev mailing list