KDC modifications for FAST

[Sam Hartman]

Please see the KDC modifications section of the FAST project for some background.

FAST requires that  we extend the KDC pre-authentication requests to handle some additional state.
In particular, two items seem to affect a lot.

* pre-authentication mechanisms and other parts of the KDC need to be able to p get access to FAST state such as the armor key.

* FAST changes how error handling works.  FAST says that the e_data
  field in a krb-error always contains a sequence of padata.  It contains rules for dealing with typed data.

Doing this in the KDC code proper is reasonably easy.  However, doing
it is more difficult for the pre-authentication plugins.

The pre-authentication plugin interface has a get_data_entry procedure
that given a type can look up some data and return it.  The goal is to
avoid exposing too much internal structure to the plugins.  This would
be ideal for getting the FAST state, except that it only takes the
kdc_req and the db_entry as arguments.

There are a few possibilities for fixing that I discussed on jabber:

* extending kdc_req
* adding something to krb5_context and requiring that the context given to the preauth plugin be used
* a new plugin interface.


In addition, the current plugin interface assumes that plugins return
e_data to be included in errors in the verify_preauth stage.
Unfortunately, with FAST, we need to include the fast padata itself,
and we also assume we're going to be generating a pdata sequence.
So, we really want a sequence of padata out of the plugins, not a single e_data.

As it turns out, that e_data will always be a sequence of padata or a sequence of typed-data in our code and the plugins/errors I'm aware of.

I was considering designing a new plugin interface that:

* took a void * to give to the get_data procedure (as is done on the
  client)

* Returned a set of padata for inclusion in errors, possibly along
  with an indication as to whether they should be encoded as padata or
  typed data if FAST is not being used.

However there are a couple of issues with doing that.  There are some
tricky design issues around the error return, and the plugin are
interface doesn't provide a good way to support multiple versions.  If
you have a v1 and a v2 symbol table, there is no way of saying that
you want the v2 symbol table if available, otherwise the v1 symbol
table.


So, instead I propose to do something simpler: 

* add an internal_state pointer to krb5_kdc_req.  It's a krb5.h
  structure, but we've already extended it for krb5 1.7.  There are no
  public APIs that take or return it.


* Attempt to decode the returned e_data from the plugin as either a
  typed-data or padata sequence and if successful re-encode as legacy.
  Note that this will be required for legacy plugin support even if we
  do a new interface.

I believe that taking these steps allows me to move forward, does not
produce significantly more ugly code than otherwise might result, and
avoids boiling oceans.


Comments welcome.

--Sam