Authdata, preauth plugin headers

[Greg Hudson]

On Mon, 2011-06-27 at 07:40 -0400, Sam Hartman wrote:
> Why won't future mechanisms need this auto-registration?
> Why do we want to make them harder.

I refer to:

http://mailman.mit.edu/pipermail/krbdev/2010-July/009170.html

Briefly, we've beeen asked to make it possible for packages to install
the binary for a module without automatically turning it on.  The
consensus (which admittedly not many people contributed to) was that we
would use profile includes to make it possible to automatically turn on
modules as they're installed.

Modules we ship, whether dynamically loaded or linked into the consumer,
can be treated as "built-in" and auto-registered.  We already have
k5_plugin_register() for modules whose implementations are linked into
the consumer; I added k5_plugin_register_dyn() for modules like pkinit
which can't be linked in without adding dependencies.

>  For everything I'm familiar with, you can return errors as padata and
>  provide a flag requesting conversion to typed data for some non-fast
>  mechanisms.

It should be okay to stuff the flag into the PA_* flags for the module,
right?  Nothing should need to set it per-request.

> I think it's really important that the KDc handle hard parts of cookie
> management itself:
> * combining cookies from multiple mechanisms
> * Doing the encryption
> * managing expiration.

Hm, and neither RFC 6113 nor the OTP draft provide any guidance here
(because the contents of the cookie are not intended to be standardized,
although it's not unheard of to have different KDC implementations in
the same realm).  I'll start a separate thread with a rough design.