pkinit updates

[Jeffrey Hutzelman]

On Wednesday, December 13, 2006 04:43:34 PM -0600 Nicolas Williams 
<Nicolas.Williams at sun.com> wrote:

> Sure.  Let me have a krb5.conf parameter to specify a token label
> precedence for PKINIT:
>
> 	token_labels = foo bar foobar
>
> And then client can sort tokens by label ("foo" first, "bar" second,
> "foobar" last) and select the cert/key from the first token in the
> resulting list that has one.
>
> If slotids may depend on credential creation order (which I gather they
> do), but token labels depend on the application's whims (which they do),
> then labels will be easier to use than slotids as an input into
> credential selection.

slotid's depend on the order in which the slots (readers, tokens, whatever) 
were added to the system.  Or not.  It depends on the software.

Labels depend on the whims of whoever initialzed the card.  Choosing a 
token based on the label may be useful, but it may not.  In any case, a 
fixed list of labels in krb5.conf is not always workable.  To make the 
point, another card I carry looks like this:

[jhutz at sirius ~] 68> pkcs11-tool -L
Available slots:
Slot 0           E-Gate 00 00
  token label:   jhutz (MiniWorld Access)
  token manuf:   OpenSC Project
  token model:   PKCS #15 SCard
  token flags:   rng, login required, PIN initialized, token initialized
  serial num  :  0000
Slot 1           E-Gate 00 00
  token label:   jhutz (SSH)
  token manuf:   OpenSC Project
  token model:   PKCS #15 SCard
  token flags:   rng, login required, PIN initialized, token initialized
  serial num  :  0000
Slot 2           E-Gate 00 00
  token label:   jhutz
  token manuf:   OpenSC Project
  token model:   PKCS #15 SCard
  token flags:   rng, PIN initialized, token initialized
  serial num  :  0000
Slot 3           E-Gate 00 00
  token label:   jhutz
  token manuf:   OpenSC Project
  token model:   PKCS #15 SCard
  token flags:   token initialized
  serial num  :  0000
Slot 4           (empty)
Slot 5           (empty)
Slot 6           (empty)
Slot 7           (empty)

Note that these "slots" correspond to multiple credentials on the same 
token.  Only the first two actually contain any credentials; their token 
labels correspond to the key labels I set when I initialized the PKCS15 
structure on this card.  The next two slots are fictional; they exist as a 
workaround to a limitation of PKCS11 which means the number of slots cannot 
change dynamically.  Since there is no real credential behind those, their 
labels corrspond to the label I assigned to the _card_ when it was 
initialized.  The last four slots are even more fictional; they're the 
PKCS11 module's way of making it possible for me to insert a second card 
and have it be accessible to the application.



>> Doug brought up the point that our code currently asks for the PIN before
>> reading the certs.  In fact, it only does this if the token info says
>> that login is required.  But I wasn't sure we were doing the right
>> thing.  I can change the code so that it first tries to read the certs,
>> and only prompts for the PIN if needed.  Does anyone think that would be
>> useful?
>
> Yes.

Yes, absolutely.  The PIN's for multiple keys on a card might be different, 
and there's no reason to request the PIN for the wrong slot.  Also, you 
should be very clear about which PIN you're asking for (print as much 
information as possible, including the labels) and respond appropriately to 
an empty PIN (i.e. don't actually try to use it).


>>   But what's the principal?
>>
>> It's the one the user gave on the kinit command line, and passed down
>> through init_creds.  Or PAM equivalent.  Are you suggesting we should
>> try to guess the principal and realm when it hasn't been specified?  How?
>
> One does not tell PAM what one's principal is

That depends on one's PAM module.  But currently, if one's PAM module does 
not provide a way to specify the principal, then it must infer it from 
PAM_USER.  The same goes for kinit.  If a smartcard or token is in use, it 
might be interesting to enumerate the credentials on the card that might be 
appropriate for PKINIT and use one, especially if you could examine the 
corresponding principal names and do the authorization checks in advance, 
so the user doesn't have to pick the "right" principal.  But the Kerberos 
API currently provides no way to do this, so an application that wants to 
do so must be PKCS11-aware.


-- Jeff