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

Ken Hornstein kenh at cmf.nrl.navy.mil
Mon Dec 30 16:47:01 EST 2002

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


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


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


More information about the krbdev mailing list