On 4/22/10 3:08 PM, Will Fiveash wrote:
On Thu, Apr 22, 2010 at 10:29:30AM +0100, Darren J Moffat wrote:
On 21/04/2010 20:33, Will Fiveash wrote:
While testing the Kerberos pkinit preauth plugin which talks to
libpkcs11 I discovered that if the metaslot is enabled it overrides the
token label of the actual token being used by the metaslot by default.
Yes that is by design to ensure that the same token isn't visible
under two different names.
I also notice that metaslot can be configured to use a particular slotID
and token via cryptoadm. With that in mind I'm wondering what the
Not quite, metaslot can be configured to use a particular token -
not slotID (the distinction is actually very important in PKCS#11).
recommendation is for configuring the metaslot to accommodate the
following situation:
- There is a smart card reader attached to the system.
- pam_krb5 is configured to use the pkinit preauth plugin to
authenticate the user when logging it which requires access to the
cert and private key stored in the smart card token.
- The smart card has a lock-out feature if the wrong PIN is given too
many times.
My recommendation would be to leave metaslot with the default
configuraton and configure pam_krb5 to look for the PKCS#11 token
(by name) of the smartcard.
So it is important that the pkinit preauth plugin locate the proper
token before prompting the user for their PIN and if that token isn't
located prompting the user to insert their smart card.
Right so pkinit needs to look for the PKCS#11 token by name and
explicitly open a session to the slot the token is in.
For PKINIT just imagine that metaslot doesn't exist - which it
doesn't on systems other than Solaris anyway.
What I've observed with metaslot enabled is that when C_GetSlotList is
called with tokenPresent either true or false count is always 1. I was
surprised that count wasn't 2 meaning that slotID 0 would be the
metaslot and slotID 1 would be softtoken.
When metaslot is enabled, the keystore slot does not show up. In the
default case, softtoken.
I also notice that metaslot
let me login using the PIN I setup for softtoken. My concern is that if
metaslot also virtualizes a smart card token as it does softtoken then:
1. If the admin specifies a particular token label in the krb5.conf it
will never be found because metaslot masks it with its own label
unless that is changed to the label requested by the admin.
2. If metaslot is virtualizing both softtoken and a smart card token,
and C_Login() is done using the metaslot session handle, which token
is being used for login?
Is my understanding of metaslot wrong in this regard?
The admin (via cryptoadm) or user (via env vars) has to set the keystore
to something other than softtoken. 'cryptoadm list metaslot' tells you
the keystore. Metaslot won't find a keystore by itself and can have
only one keystore. If someone has a smartcard token configured as the
keystore it's because they did it manually, not because metaslot chose
it. Metaslot will only put the Sun Metaslot label on the configured
keystore, not other keystores in the slot list.
Tony
_______________________________________________
crypto-discuss mailing list
crypto-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/crypto-discuss
