pkinit preauth plugin issue
Will Fiveash
William.Fiveash at sun.com
Wed Feb 10 16:39:09 EST 2010
On Tue, Feb 09, 2010 at 04:14:59PM -0600, Douglas E. Engert wrote:
>
>
> Will Fiveash wrote:
> > While doing more testing of pam_krb5 pkinit I noticed that the pkinit
> > preauth plugin code does not use gak_data if it is set via:
> >
> > krb5_get_init_creds_password(
> > kmd->kcontext,
> > my_creds,
> > me,
> > *krb5_pass, /* clear text passwd */
> > ^^^^^^^^^^ this is set
> > NULL, /* prompter */
> > NULL, /* prompter data */
> > 0, /* start time */
> > NULL, /* defaults to krbtgt at REALM */
> > &opts);
> >
> > This is troublesome because I want pkinit to use the gak_data/password
> > if set as the PIN/PEM password. I see that pkinit_client_process() has
> > a gak_data input parameter but doesn't do anything with it.
> >
> > Note, if krb5_get_init_creds_password is called like so:
> >
> > krb5_get_init_creds_password(kmd->kcontext,
> > my_creds,
> > me,
> > NULL, /* clear text passwd */
> > pam_krb5_prompter, /* prompter */
> > pamh, /* prompter data */
> > 0, /* start time */
> > NULL, /* defaults to krbtgt at REALM */
> > &opts,
> >
> > then pkinit will use the pam_krb5_prompter() and acquire the PIN/PEM
> > password and things function normally.
> >
> > Thoughts on whether it is reasonable for pkinit to pay attention to
> > gak_data?
>
>
> I would argue that a PIN is not a password, and should not be used
> interchangeably. Accidentally using one for the other could lock up
> a card or the account. Some readers have a keypad to enter the PIN,
> so the PIN would never be entered on the keyboard anyway.
Yes, that was the consensus when I brought this up at the weekly MITKC
dev. meeting. I'm going to use a different tack to provide a PIN to the
pkinit plugin (see the other e-mails on this thread).
--
Will Fiveash
Sun Microsystems Inc.
http://opensolaris.org/os/project/kerberos/
Sent from mutt, a sweet ASCII MUA
More information about the krbdev
mailing list