PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11)

[Nicolas Williams]

On Tue, Jan 08, 2008 at 11:10:15AM +0000, Darren J Moffat wrote:
> ==========================================
> The pam_pkcs11 module overview
> ==========================================
> The pam_pkcs11 module is a PAM authentication module for PKCS#11 token
> libraries.  This module allows a user to login a system that supports PAM,
> using a certificate and its dedicated private key stored in a PKCS#11 token.
> 
> This pam_pkcs11 module supports any PKCS#11 token library, however, it
> is typically used by a Smart-card PKCS#11 token. 
> 
> The original source of this module is provided by opensc-project.org.
> The latest version is 0.6.0 which supports only the authentication service.
> It does not support pam_setcred, pam_acct_mgmt, or other services.

Why no pam_acct_mgmt?  The module checks that the cert is not expired/
revoked...

> For more information, see http://www.opensc-project.org/pam_pkcs11
> 
> =========================================================
> The pam_pkcs11 authentication/verification procedure
> =========================================================
> The authentication and verification procedure is as following:
> 
> Step 1: Find all certificate/private_key pair in the PKCS#11 token
> 
> Step 2: Find the certificate/private_key pair that matches the user
> 
>     For each pair of the certificate and its associated private key

If PAM_USER is not set when pam_pkcs11:pam_sm_authenticate() is invoked,
will it set PAM_USER, and if so, which cert will be used to derive the
username?  (see more below)

The pam_pkcs11.conf manpage mentions parameters that shouldn't be needed
on Solaris:

| # Do not prompt the user for the passwords but take them from the
| # PAM_ items instead.
| use_first_pass = false;
| 
| # Do not prompt the user for the passwords unless PAM_(OLD)AUTHTOK
| # is unset.
| try_first_pass = false;
| 
| # Like try_first_pass, but fail if the new PAM_AUTHTOK has not been
| # previously set (intended for stacking password modules only).
| use_authtok = false;

Or perhaps the token PIN should be seen as distinct from the AUTHTOK, in
which case that might require at least one parameter.

Also, if the home directory of the PAM_USER is on secure NFS, what
happens when the metaslot is used?  Will the module find any smartcards?
Or will it fail?

> [...]
> 
> ==========================================
> Deliverables:
> ==========================================
> Pam_pkcs11 module:
> 
>   /usr/lib/security/pam_pkcs11.so
> 
>   (Note: will support both 32bit and 64 bit versions.)
> 
> Non-built-in Mapper modules:
> 
>   /usr/lib/pam_pkcs11/ldap_mapper.so
>   /usr/lib/pam_pkcs11/opensc_mapper.so
>   /usr/lib/pam_pkcs11/openssh_mapper.so

Given that the mapper objects are volatile, how might these paths be
handled on upgrade if and when the cert->user mapping facility moves
into KMF?

Presumably the openssh and opensc mappers can only check that a given
cert maps to a given PAM_USER (since they cannot search all users' home
directories), and cannot derive a PAM_USER from a cert (whereas the
'generic' and 'subject' mappers could do both).

Will the 'ldap' mapper support the use of SASL/GSSAPI/Kerberos to
authenticate to the directory?

Will the 'ldap' mapper support the use of the native LDAP configuration
instead of having to repeat that in pam_pkcs11.conf (when the DIT
containing these mappings is also the same as the native LDAP DIT)?

Looking at the description of the 'ldap' mapper I see it can only really
support verification that a cert corresponds to a PAM_USER, not
derivation of a PAM_USER from a cert, and it appears to require storing
the entire cert in LDAP (as opposed to a fingerprint, or subject name,
or list of subjectAltNames).  This being a third-party open source PAM
module I think this is reasonable, but could we open RFEs in this area?

The 'krb' mapper should specify a realm name, no?  Or is it formatting a
principal name of the form <PAM_USER>@<default-realm> and then comparing
it to the krb5 princname subjectAltName?

The pam_pkcs11.conf manpage in the materials refers to
/usr/lib/opensc-pkcs11.so and so on as well...  This should be cleaned
up.

>   (Note: will support both 32bit and 64 bit versions.)
> 
> [...]
> 
> Sample Mapfiles and script:
> 
>   /etc/security/pam_pkcs11/digest_mapping.example
>   /etc/security/pam_pkcs11/subject_mapping.example
>   /etc/security/pam_pkcs11/mail_mapping.example
>   /etc/security/pam_pkcs11/make_hash_link.sh

The above are not in the materials.

> Utility commands:
> 
>   /usr/lib/pam_pkcs11/pkcs11_inspect
>   /usr/lib/pam_pkcs11/pklogin_finder
>   /usr/lib/pam_pkcs11/pkcs11_eventmgr
> 
>   (Note: will support both 32bit and 64bit versions.)

Shouldn't we already have pkcs11_inspect-like functionality in
pktool(1)?

How will pkcs11_eventmgr be used?

> [...]
> 
> Run:
> ------------------------------------------------------------------------
> hylee at bula$exec login
> Please insert your smart card or enter your username.
> login: hylee
> Smart card inserted.
> Welcome Sun Metaslot!
> Smart card password: XXXXXX
> Last login: Wed Sep 12 15:10:29 from comforter
> Sun Microsystems Inc.   SunOS 5.11      snv_65  October 2007
> ------------------------------------------------------------------------
> 
> Note that the "Smart card password" is the Solaris softtoken keystore
> password.

So each token type can have its own prompt?

Nico
--