On 02/10/2010 11:07 AM, Andreas Jellinghaus wrote: > ok, let me phrase it that way: > a typical card has certificates - non-authoritative belong to > the user, authoritatives are part of the chain to the root ca. > normal cards don't have rsa public keys. > normal cards have a private rsa keys for each user certificate. > normal cards need a pin before the private rsa key is visible.
Right, i understand this; but the certificates themselves contain public
keys, so the one thing held in common by all these cards is that they
publish a public key in some form (whether embedded in a certificate or
as a raw public key).
> so what pam_p11 does is match the certificates or rsa public
> key in whatever file against the certificates (or rsa public
> key inside the certificate). only if it finds a match, it will
> ask for the pin, and then make sure there is a private key
> that can sign some random data, and verifiy that signature.
understood.
> switching from looking to certificate to _INSTEAD_ look
> for public rsa keys only would be a grave mistake, as
> many cards have no public rsa keys (well, with some
> cards opensc emulates those, but other pkcs#11 libs
> don't do that). so with typical cards it will no longer
> work.
my point was simply that the cards which publish certificates *do*
publish public keys -- they're just wrapped up in the X.509 certificates.
> you could extend the code, to look also for public keys.
> but that will only work with some cards, and only with
> the _openssl module.
What is the _openssl module? do you mean pam_p11_openssh ?
> while it might be a nice solution
> cards with a public rsa key, but without certificates
> (opensc can create those), I don't think many cards like
> that are around.
The amount of storage space on my eGate appears to be such that if it
contains two 2048-bit RSA secret keys, it can only fit one certificate.
since public keys are smaller than certificates, it turns out that it
can store two public keys.
>> pam_p11 currently appears to ignore everything in A (e.g. it doesn't
>> care about the expiration date on the cert, the extensions, the issuer,
>> etc), and cares only about B.
>
> IIRC only for the _openssh module, but not 100% sure.
i'm only using pam_p11_opensc, actually, not _openssh. My point is not
that pam_p11 is using a raw public key as a data structure -- it's
clearly currently using an X.509 certificate as the data structure,
*not* a raw public key. But for the purposes of authentication, it is
ignoring all of the material in that data structure except for the
public key.
>> It asks: can the plugged-in-device, in
>> conjunction with the user-supplied PIN, produce a successful RSA
>> response from the associated private key?
>
> no, it first tries to guess, if there is a matching private key on
> the card. and the way to do that is to look for a matching certificate
> with the public rsa key part in it. public rsa key objects only exist
> with some cards.
right, i understand this.
> so having a debian bug about this possibility is kind of pointless.
> if you send a clean and nice patch to add such functionality, I can
> apply it and release a new version. but since you are the first
> user in ages to ask for such an uncommon feature, it is unlikely anyone
> else will implement it, unless you do it yourself.
that's fair enough -- and it's actually been on my list of things to
look into doing for a while (though my plate is pretty full at the
moment). Would you prefer i file a bug with some upstream bugtracker as
well to keep it on a list we could both refer to?
>> In fact, that would be a bad idea on my particular device, because i
>> have two keys on it. It's important that the authorized public key be
>> matched against a particular authentication slot (PIN) on the card and
>> be able to test that the supplied PIN enables the card to produce a
>> successful RSA response from the expected private key. We don't want to
>> blindly try all authentication slots.
>
> well, the code should only ask for a pin and use it, if the slot contains
> a matching ceritificate. so I don't see any "blindly try all authentication
> slots".
i agree, it's not blindly trying right now, and that's good. You seemed
to suggest that was what i wanted to do, and i was trying to explain
that i did not want to do that.
> yes, we could add an option to limit the pam module to some slot. haven't
> had a request for it so far, patches welcome. also for alternative locations
> for those files (the file names implemented are simply the old file names
> that had been implemented by old modules preceeding pam_p11)...
i don't want an option to hard-bind the pam module to a given slot. i
think that would be a mistake. the current approach of choosing a slot
based on the acceptable cryptographic authentication material is the
right one.
> the current code is simple, allowing more is adding complexity.
> if people need more features, they can be added, but so far the code
> was small and simple and worked without much work.
yes, and i appreciate it! I'd like to simplify it further conceptually
by throwing away the requirements for X.509, since pam_p11 doesn't
actually use any information about them.
All spelled out, my proposal is:
* the filesystem can supply certificates, certificate requests, or raw
public keys in ~/.eid/authorized_certificates
* pam_p11 extracts the RSA public key from these, to create a set of
public keys.
* the card produces a set of public keys bound to authentication slots,
either embedded in X.509 certificates or as raw public keys.
* the system finds the first public key which is in both sets, and asks
the user to authenticate to the corresponding slot on the card
* the system grants the authentication based on whether the card can
properly compute the response to the RSA challenge using the
user-supplied PIN.
Does that make it clearer? I probably should have written it up like
that earlier.
> also there is a much bigger and more complex alternative to pam_p11:
> pam_pkcs11. it has modules, does CA chain certificateion, can check
> if certiifcates are expired or revoked, can lookup ldap etc.
yeah, i'm not using pam_pkcs11 because the X.509 hierarchical trust
model doesn't match the way i think that cryptographic trust should
work. I much prefer the simpler model offered by pam_p11, which can be
used as a backend for various other trust models.
> so I'm not sure how much complexity added to pam_p11 would still be good,
> or when users would be better off with using pam_pkcs11. the whole point
> of pam_p11 is: it is dead simple.
agreed, which is why the X.509 trimmings that aren't actually used by
the authentication process shouldn't be required. Keep the
authentication simple: proving that you have control over the secret
counterpart to a given public key should be sufficient. i *don't* want
to see pam_p11 embed or require all the X.509 craziness.
> so what do you think is best to do?
I'd like to leave this bug open (possibly forwarding it to an upstream
tracker if you like) until we have a chance to get it sorted out. I
understand that might mean me doing the work, and i don't mind that.
Thanks for having this discussion, and thanks for pam_p11! I hope it's
understood that my suggestions and contributions here are meant
constructively, not just whining.
Regards,
--dkg
signature.asc
Description: OpenPGP digital signature
