FAST error handling and our plugin interface

Sam Hartman hartmans at MIT.EDU
Thu Mar 5 11:50:54 EST 2009


>>>>> "Jeffrey" == Jeffrey Altman <jaltman at secure-endpoints.com> writes:

    Jeffrey> Sam Hartman wrote:
    >> 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.

    Jeffrey> For clarity sake, just how many plugins are we talking
    Jeffrey> about?

I don't know.  I know of two companies that would be affected with
shipping products that it would be difficult for me to change, and
suspect others.

I do agree a new plugin interface should be designed, especially for
mechanisms that are actually FAST factors.

    Jeffrey> My failing to pass in the two separate sets of padata to
    Jeffrey> the plugins, each plugin is going to have to replicate
    Jeffrey> the logic to separate the hints from the actual error
    Jeffrey> data.

    Jeffrey> I agree with you.  The hack of re-encoding the pa-data as
    Jeffrey> typed-data so that the existing plug-ins can accept it in
    Jeffrey> the e_data field is ugly and potentially confusing to
    Jeffrey> future implementers.


Note that some hack like this is actually much easier for pkinit
authors, which are the primary consumer of the tryagain interface
today.  If I'm getting an error from a non-FAST KDC, I don't know what
the e_data field is encoded as.  So, I have to pass it directly to the
plugin.

If I re-encode padata as typed-data, then a pkinit plugin can always
look at the e_data field as a sequence of typed data both in the FAST
and non-FAST case.

An obvious question that comes up at this point is whether FAST is
right to change the encoding of errors.  I think so, because I think
normalizing that and removing the typed-data vs padata vs other things
confusion is good.  However there is a consensus call open on that
issue over in the IETF right now.  You might argue that this uglyness
is worse than normalizing the errors at all.



More information about the krbdev mailing list