[Nicolas Williams <Nicolas.Williams@sun.com>] client-side pre-auth re-architecting

[Sam Hartman]

Hi.  I happened to be in the same city as Nico so we got together to
meet and discuss his  mail  about preauth.

We believe that the client side preauth API in
src/lib/krb5/krb/preauth2.c needs significant improvement.

Nico gave a point-by-point summary of the conclusions of the meeting
I've edited somewhat below.

 - a generic mechanism is needed for setting mech-specific pre-auth
   options via a get_init_creds options (say,
   krb5_get_init_creds_opt_set_preauth_opt())

   [hartmans]  Originally I thought that  you could  just have
   functions like krb5_gic_opt_set_hwauth_keytab.  Nico pointed out
   this style does not work well if we have plugins for preauth
   modules.  He indicated that might be important to him in the
   future.


 - krb5_get_init_creds() should maintain a per-call pre-auth context
   structure, complete with initializer/destructor in preauth2.c.  This
   structure is needed for pre-auth mechs that interact with each other,
   for example.  This context should be passed to the pa_functions.

 - each pre-auth mechanism should have an optional context structure -
   this is needed for multi-round-trip mechanisms - also complete with
   initializer/destructor function pointers in pa_types_t

 - some arguments of pa_function can move into the gic context since the
   pa_functions can then get them from there (e.g., the
   gak_fct/gak_data)

 - the as-reply should probably be passed, when available, to the
   pa_function

   [hartmans]  I remember saying this, but I thought I unsaid it
   later.  I am reluctant to have one preauth type reading another
   preauth type 's data.