FAST error handling and our plugin interface

[Sam Hartman]

I need review on this, or at least I need people who don't raise
objections very soon to not raise objections later:-)


I've described the general issue on the ietf list, but I need to
discuss the implications for our code base.  Briefly, FAST changes how
errors are handled at a protocol level.  Today, most errors have an
unspecified e_data field that has an untyped octet string.  Some
errors tell you what goes there, but most do not.  So, with most
errors you cannot interoperably exchange information there.

One error (PREAUTH_REQUIRED) is specified to contain a sequence of
padata in that space.  Another error (PREAUTH_FAILED) traditionally
also contains padata in the Microsoft implementation.  Luke's changes
also cause us to include padata in that error.

Some pkinit errors contain something called typed-data which is
basically similar to padata except that the encoding is different.

One key thing to understand is that both in the PREAUTH_REQUIRED and
PREAUTH_FAILED error, the padata contained with the error roughly are
a list of pre-authentication mechanisms you should try next.


So, the code in preauth2.c interprets PREAUTH_REQUIRED and pulls out
the padata from the e_data and uses it to update the methods to try.
However for other errors, it simply calls the tryagain function and passes in the e_data.


FAST changes the handling of all errors.  They all return padata in
the e_data field.

However only the preauth_required and preauth_failed errors use padata
to drive what mechanisms a client should use.

So, the ideal fast interface would pass two sets of padata into the
preauth2.c loop.  It would pass a set of driving padata from hints or
from preauth_required along with a set of padata from the current
error.  The loop would make the set of padata available from the
current error to all pre-auth plugins, not just the padata
corresponding to the current plugin.


However we don't have that plugin interface today and it is desirable
to keep things working with the current plugins.  So, my plan for the
current interface is to continue doing what we're doing in the
non-FAST case.


In the FAST case, I plan to take the padata , re-encode as typed-data
and pass that into the plugins as the e_data field.  That is ugly, but
will work with all the existing plugins.


Things are correspondingly messy on the KDC side, although I have
discussed that via jabber.