[kmf-discuss] PSARC/2006/283 Certificate & PKCS#11 PAM module (pam_pkcs11)

[Nicolas Williams]

On Sun, Jan 27, 2008 at 04:38:53PM -0800, Gary Winiger wrote:
> > This is a valid point.  Since UBS requested this port and they are happy with
> > the current pam_pkcs11 implementation, this case has merit to integrate as is.
> > We will work with the upstream community to add the functionality as a separate
> > pam_acct_mgmt() entry point. 
> 
> 	I disagree that this should be postponed.  Saying a single customer
> 	is happy with the implementation (do they have an IDR?) doesn't
> 	make it architecturally correct.  If the code is currently doing
> 	certificate validation (and CRL or OCSP processing), it seems
> 	a straight forward factoring of the code.  Waiting for phase 2
> 	likely means changes to pam.conf as well as updating the code.

There's no need to factor the code.

All that needs to happen is that pam_sm_authenticate() needs to call
pam_set_data(3PAM) to tell the same module's pam_sm_acct_mgmt() that
authentication succeeded, and the latter needs to call pam_get_data() to
check whether authentication succeeded.  The specific details of when
pam_sm_acct_mgmt() should return PAM_SUCESS, PAM_IGNORE, or some error,
need to be hashed out, but the rest seems trivial.

> > > 	4) Given that this is intended to replace the EOLed pam_smartcard,
> > > 	   I don't see sufficient Sun documentation (at least from what's
> > > 	   in this case) to guide me through how to use pam_pkcs11 to
> > > 	   replace pam_smartcard.  I would have expected at least that
> > > 	   much detail as pam_smartcard was equivalent to a "Committed"
> > > 	   interface in the past and its use more or less well documented
> > > 	   in Sun documentation.
> > > 	   P.S. I'm looking forward to the removal of the closed pam_smartcard
> > > 	   and the project private interfaces in libpam that are there to
> > > 	   support pam_smartcard ;-)
> > > 
> > 
> > I have discussed with Darren about this.   And here is our response:
> > 
> > "This case alone does not give us a functional replacement for pam_smartcard.
> > Another future case that provides a smartcard plugin to the crypto framework
> > is needed together with this case since this case has no smartcard
> > functionality it is all done via the PKCS#11 layer." 
> 
> 	Hummm, I guess I've read too much into the materials:
> 
> 	"I'm using this old case number as other ARC cases reference
> 	 this case number as a requirement for EOF removal of some old
> 	 smartcard functionality."
> 
> 	 "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"
> 
> 	Should the prompts (presumably) from pam_pkcs11 not imply
> 	use of a "smart card"?

I'm not on the i-team, but I suspect that the example is using the
softtoken as though it were a smartcard, and pam_pkcs11 doesn't know
that it isn't really.

Of course, if the softtoken lives on an NFS share accessed w/o sec=krb5i
or p, then there are some security considerations...  Even if secure NFS
or local home directories are used there's the issue of how much control
the user should be given over how to authenticate them (but then, ssh
already allows users to do that with pubkey userauth).

A knob for controlling whether the softtoken can be used by pam_pkcs11
would be useful.  Control over where the softtoken lives would be good
also (IIUC the only way to do that is through the SOFTTOKEN_DIR
environment variable, but that's not good enough for a PAM module).

[...]
> 	I guess I'm missing some understanding here.  I thought pkinit
> 	as part of pam_setcred() wasn't an if, but was in the immediate
> 	plan.  In any case I'm confused.  If the home directory is not
> 	kerberized, where does pam_pkcs11 go in the stack?  From 2,
> 	it sounds like pam_krb5 obsoletes pam_pkcs11.  If that's the case,

I think you'd either use pam_pkcs11 or pam_krb5 w/ PKINIT, but not both.

> 	what's the compelling architectural reason to not combine forces
> 	and deliver a pam_krb5 that does it all rather than a pam_pkcs11?

That not everyone uses Kerberos.  (At least for me that would be the
reason.)

(BTW, someday we're likely to have a PKI-based GSS-API mechanism,
allowing for secure NFS using that instead of Kerberos or DH.  That
mechanism is actually being specified in the IETF, and it's based on
Kerberos and PKINIT components internally, but it is/will be a PKI
mechanism -- the successor to the old SPKM.)

> 	It seem that pam_pkcs11 will need to be removed from pam.conf
> 	when pam_krb5 replaces it?  Or is it that in addition to Unix,
> 	Kerberos (and LDAP bind), a new account authority based on pkcs11
> 	access to certificates is being proposed?  I guess I can
> 	understand this if pam_pkcs11 is a replacement for pam_smartcard
> 	(which the case now says it isn't -- though I personally want to
> 	be able to support it as a replacement).

Well, if pam_pkcs11 is part of a two-pronged strategy to replace
pam_smartcard, what's the harm in delivering it first?  But, yeah,
there's the issue of how to secure the softtoken if it be the only
available token for pam_pkcs11.

Nico
--