issue with preauth processing

[Nicolas Williams]

On Wed, Oct 21, 2009 at 07:01:37PM -0500, Will Fiveash wrote:
> > The logic ignores the krb5_gic_opt_ext *options that is passed in to
> > krb5_get_init_creds().  Thoughts?
> 
> Actually my analysis above is wrong.  The issue is here where
> preauth_to_use is reset:
> 
>       if (should_continue_preauth(err_reply->error, loopcount) && retry) {
>         /* reset the list of preauth types to try */
>         if (preauth_to_use) {
>             krb5_free_pa_data(context, preauth_to_use);
>             preauth_to_use = NULL;
>         }
>         preauth_to_use = out_padata;
>         out_padata = NULL;
>         krb5_free_error(context, err_reply);
>         err_reply = NULL;
>         ret = sort_krb5_padata_sequence(context,
>                         &request.server->realm,
>                         preauth_to_use);
> 
> Perhaps somewhere there should be code to limit the preauth types to the
> intersection of options->preauth_list and out_padata?

I've not looked at the code, but here's how I think this should work,
pre-FAST: try the first app-requested pre-auth type, then, if that
fails, remove from the app-requested pre-auth list any that don't appear
in the KDC's PA-ETYPE-INFO*.

FAST will change things somewhat in that it's possible that it won't be
reasonable to expect apps (and/or admins, users!) to specify all
acceptable FAST combinations.  Instead apps/admins/users may wish to
specify constraints such as "must protect PA-ENC-TIMESTAMP", "must
authenticate KDC with certs", "must use client cert", and so on.  A
reasonable implementation strategy then may be to apply those
constraints to the list of all pre-auths and FAST combinations to obtain
a list that can then be used to as above.

Nico
--