pkinit slotid=N ?

Nicolas Williams Nicolas.Williams at
Thu Jan 10 11:38:26 EST 2008

On Wed, Jan 09, 2008 at 02:03:46PM -0600, Douglas E. Engert wrote:
> >>> There's a pam_pkcs11 module that does just that sort of thing.  It looks
> >>> at each cert it can find in the token until it finds one that a) maps to
> >>> the given PAM_USER,
> >> Where is this mapping done? We expect to use certs from the HSPD-12
> >> PIV cards that do not require a subject alt name for a local principal
> >> in the cart. In fact the card should be usable at many different
> >> locations, against different realms.
> > 
> >
> > 
> > It has number of configurable mapping schemes, from algorithmic (e.g.,
> > try to map the cert's DN's CN to a username, similarly with e-mail addr
> > and krb5 SANs, ...) to lookup based (in local files, in
> > ~/.ssh/authorized_keys, in LDAP).
> But this map is local to a machine. We are talking pkinit, and want to
> have the KDC do the mapping. But this requires at least finding a cert
> that could be usable with pkinit.

What I meant by "that sort of thing" above is this: trying all private
key / cert pairs found in the token.

I see no reason why the same approach can't work for pam_krb5 w/ PKINIT.

You then asked about the mapping facilities in pam_pkcs11, and I
answered that, but that was not meant to indicate that pam_krb5 should
need such a mapping facility.

> > PKCS#11 is designed so that could be handled.  So this would be a bug in
> > the "Kerberos code" (are we talking MIT or Heimdal, or both?).
> No not a bug, but code not implemented. is there a "gss mech_glue" equivelent
> for pkcs11? Maybe the Solaris pkcs11 has this, if so great. But I don't know
> of any other.

The Solaris libpkcs11 is, indeed, pluggable (you have to get a cert
issued to you by Sun for code signing your PKCS#11 plug-ins).


More information about the krbdev mailing list