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

[Ken Hornstein]

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

No disagreement here :-)

> - 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())

Agreed.

>   [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.

I hadn't thought about plugins for preauth modules, but that would be
cool.  Defining the right plugin API for this seems ... challenging, I
will admit, but that comes later :-)

> - 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.

Yes, definately.

> - 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

Yup.

> - 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)

Seems logical.

> - 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.

Hm, I can think of cases where it would be useful, actually (a preauth
type that might have different behavior if you were doing hardware preauth,
for example).

--Ken