pkinit updates

[Douglas E. Engert]

Nicolas Williams wrote:

> On Wed, Dec 13, 2006 at 01:16:40PM -0500, Jim Rees wrote:
> 
>>Token labels are only needed if you anticipate having more than one token,
>>and you don't want to use the slot id.  If you do have more than one token,
>>and you don't want to use the first one, you will have to specify which one,
>>either via an option or a (yet to be specified) krb.conf entry.  I agree it
>>would be nice to use a token label for this and as I said I'll do that as
>>time permits.
> 
> 
> Token labels -> no options needed, no config params needed, no
> 		interaction needed, provided that there is a labelling
> 		convention and that it's used.
> 
> 		(A good default labelling convention would be good to
> 		have; a config param to establish alternative labelling
> 		conventions may be useful.)
> 
> No token labels -> options, config params, interaction (think PAM).
> 
> Now, there may not be a label, so the client needs a reasonable way to
> cope, and options/config/interaction are good enough for that.

PKCS#11 says: " CK_TOKEN_INFO
                 CK_CHAR label[32];

                label - application-defined label, asigned during token
                        initialization"

The way I read this, is the label, if any, is assigned when the smartcard
is initialized by the card issuer. The label may or may not be different
on each card and for security reasons may even be null.  The label is a
PKCS#11 thing, and a card may or may not have any information that might
correspond to something that could be called a label. So I don't think there
is any chance of expecting a labelling convention. Even so the convention
is under control of the card issuer that may not be in the same oraginazation.

Looking at other applicaitons, like FireFox or Windows CSP that have to deal
with smartcards, they all do somting like registering the certificates that
they have seen, rather then labels. So in my option the best pkinit
could do is default to using the card found in the reader.

> 
> 
>>Would there be any value in trying to automatically find the right token,
>>maybe by looking for one whose label matches the principal?
> 
> 
> But what's the principal?
> 
> Let me guess: it's an argument, the current ccache's default princ or
> <user>@<client's default realm>.
> 
> What if there are several certs with krb5 princ SANs, all for the same
> username but different realms and none match the client's default realm?
> 
> There are too many non-obvious cases, and interacting with the user
> (through the krb5_get_init_creds() prompter or PAM conversation) seems
> much better to me than just failing.
> 

Yes good idea, if you can give the user a choice using data from his
card.

This does bring up a point. Most (all?) cards allow the certs to be read
without providing the pin. The UMich pkinit code is asking for the PIN then
reading the certs. (The main difference between NIST 800-73 and 800-73-1
hinged on this point, as most other application like Windows CSP depend on
reading the cert before asking for the pin.)

If you are trying to select among certs on multiple cards in readers
on the same machine, you dont wan't to have to ask for the PINs just to
find out the cert on the card is not useable.

> Interaction would also be better than asking the user to know about slot
> IDs or what have you.
> 
> Also, if there would be options like slotid then perhaps an option to
> match cert/key by Name/SAN would be good (kinit -X dn=...; kinit -X
> san=rfc822Name:...; kinit -X issuer=...).  But now I'm probably asking
> for the Moon ;)
> 
> 
>>  I think these should all be separate parameters; most, if not all of
>>  them, can be optional.
>>
>>I was only using that syntax because that's roughly what we have now, not
>>because I think that's what it should be.
> 
> 
> OK.
> 
> 
>>All options will have reasonable defaults:
>>
>>module name: opensc-pkcs11.so (unless you have a better idea)
> 

Not sure how far you want to go with this, but FireFox for example
allows for multiple PKCS11 plugins, i.e. the security devices. This was
needed as most smartcards came with their own middleware, and PKCS#11
library. Apple used the tokend, and Microsoft has the CSP.

OpenSC's opensc-pkcs11.so  is a little different in that it can handle
different cards with the same PKCS#11, but not all cards are supported
by OpenSC.

Maybe this is a future enhancement.

The first cut should use a default pkcs11, with a default slot, and id.
This would catch 99% of the cases.

> 
> If the OS ships with a PKCS#11 implementation, then use that as the
> default.  (Solaris 10+, for example, has /usr/lib/libpkcs11.so.)

*WOW...* But this is not a smartcard interface as best as I can tell,
it is a crypto provider for interal use only. If it can use a smartcard,
please correct me if I am wrong!

I ran in to a problems with it when porting the kx509/libkpkcs11 to run
on Solaris 10. FireFox was having troubles loading libpkes11.so as it kept
finding the /usr/libpkcs11.so that is used by the Kerberos gss/mech_krb5.so

> 
> 
>>slotid: the first one that has a token in it
> 
> 
> Sure.
> 
> 
>>Which cert to use is the bigger problem.  If there is only one with a SAN
>>that matches the principal, you're all set.  If not, I suppose for now we'll
>>use the first one.
> 
> 
> Interaction.
> 
> Either multiple yes/no prompts for each useable credential, or one
> prompt with a menu (pick a number) where the items are the names of the
> credentials.  Of course, the krb5_gic prompter and PAM conv are not
> designed deal with menus, so that could be a problem (you could have a
> single string with multiple new-lines, but you'd have to assume a
> minimum screen size).
> 
> 
>>If you have only one token, and it only has one cert/key, you shouldn't need
>>to specify anything.
> 
> 
> But how many smartcards should I have to carry around with me?

How many credit card do you carry?

> 
> Nico

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444