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

[Nicolas Williams]

On Mon, Dec 30, 2002 at 04:46:31PM -0500, Ken Hornstein wrote:
> > - 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 :-)

Think pam_set_data().  Something like krb5_gic_opt_set_pa_data(), using
a char string to name a datum, with a naming convention of prefixing
data names with "<pre-auth name>_" and a (void *) parameter for the
actual datum.

This way krb5.h, preauth2.c and gic_opt.c need never be updated when
adding pre-auth types - instead you can add a per-pre-auth mech header
for pre-auth mechs with private C types.  The application will have to
know the datum names and types, but that's no big deal - nor would the
apps have to do anything special for PA-ENC-TIMESTAMP; and PA-TGS-REQ
would have only two parameters, with default values: a princ name and a
keytab name.  Similarly with your hw pre-auth type.

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

gak_fct should be called once and then its result memoized (a macro
for this would be handy).

Nico
--