Proposal: krb5_get_init_creds_opt_set_change_password_prompt

[Douglas E. Engert]

Kevin Coffman wrote:

> On 12/5/06, Douglas E. Engert <deengert at anl.gov> wrote:
> 
>>Sam Hartman wrote:
>>
>>
>>>>>>>>"Douglas" == Douglas E Engert <deengert at anl.gov> writes:
>>>
>>>
>>>    Douglas> Kevin Coffman wrote:
>>>
>>>    >> Branch users/coffman/gic_opt_ext has my propoal for extending
>>>    >> the get_init_creds_opt structure and making use of it to pass
>>>    >> preauth options through the to preauth plugins.
>>>    >>
>>>    >> There is currently extra test code in kinit.c which does not
>>>    >> belong.  Hopefully it is obvious.  There is currently *not* a
>>>    >> compatibility function/macro to match Heimdal's
>>>    >> krb5_get_init_creds_opt_set_pkinit() function.
>>>
>>>    Douglas> Since PAM_KRB5 is a common source routine that needs to
>>>    Douglas> call krb5_get_init_creds_* it would be nice if both MIT
>>>    Douglas> and Heimdal used the same API....
>>>
>>>As I've said before, we cannot have a pkinit-specific entry point in
>>>libkrb5 for licensing reasons.
>>
>>Well, if MIT can get PKINIT to work, without a special
>>krb5_get_init_creds_opt_*  then maybe Heimdal can too.
>>I would still like to see the same API,
> 
> 
> I've updated this branch to remove the extra 'user_id' paramter in
> krb5_get_init_creds_opt_set_pa() and added an emulation function to
> match Heimdal's krb5_get_init_creds_opt_set_pkinit().  Sam won't want
> this function in libkrb5, but it is there for testing and proof of
> concept...
> 
> It requires that we agree on attribute name equivalents to the
> parameters supplied to krb5_get_init_creds_opt_set_pkinit().  I used
> the following, but am open to discussion.


Antother way to look at having the same API, but not have any
PKINIT specific info when calling krb5_get_init_creds_opt_*
is to look at passing arbatrary parameters  to be used only by the underlying
plugins that understool them. Thus making a generic way to pass parameters
to any preauth plugin not just pkinit.

For example,

kinit --pp x509_user_identy:/home/user/usercert.pem,/home/user/userkey.pem \
       --pp X509_anchors:/some/path/trust.dir \
       --pp ... \
       - f user at realm

Then there is a krb5_get_init_creds_opt_set_pp that adds the string to
a list of strings that are passed to the plugins. Multiple pluigins could
use the same parameters, and the order of the strings could also be used.

Thus the caller of the API just passes in the strings, without regard
for which plugin is using it or if it implies OpenSSL or not.


Another thing to look at is using something like ENV:<varablename>
in the krb5.conf file

For example something like:

   [kinit]
     X509_user_idenity = ENV:X509_USER_IDENTITY
     X509_user_idenity = ENV:X509_USER_PROXY
     X509_user_idenity = PARM:1
     X509_user_idenity = ~/.globus/usercert.pem,~/.globus/userkey.pem

Here the pkinit code (in a plugin or not) would look first
at for an environment variable X509_USER_IDENTITY, then for
then for  the a X509_USER_PROXY, then for the first parmaeter passed,
then default

The idea is to get identification of the paramaters for the plugins
out of the API but still alow then to be passed in as parameters from
the calling application, like kinit or pam_krb5.


> 
> Love, I didn't find another use of flags besides 2 to specify using
> RSA vs. DH, are there others?
> 
>   .attr = "X509_user_identity"  /* Location of user's X.509 identity
> (cert/key)*/
>   .attr = "X509_anchors"; /* X.509 Trust Anchors */
>   .attr = "X509_chain_list";  /* Other X.509 certs for building
> verification chains */
>   .attr = "X509_revoke_list";  /* Location of revocation information */
>   .attr = "flag_RSA_PROTOCOL";  /* Use RSA rather than DH */
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444