Bug 629022

Note: KDC is installed on Rhel 6.

> 3. yum install  krb5-pkinit-openssl. Edit /etc/pam.d/smartcard-auth and
> /etc/pam.d/system-auth to use pam_krb5 with
> preauth_options=pkinit_identities=PKCS11:/usr/lib64/pkcs11/libcoolkeypk11.so

That's my mistake -- the preauth_options should take the same form that arguments passed to kinit would, so the correct value here is

  preauth_options=X509_user_identity=PKCS11:libcoolkeypk11.so

This doesn't affect the kinit case, though.
 
> 6. kinit -X X509_user_identity=PKCS11:/usr/lib64/pkcs11/libcoolkeypk11.so
> 
> Actual results:
> Smart card pin is requested. Entering the correct pin prompt for Kerberos
> password. Entering the correct pin does not authenticate to the kdc using the
> cert and its private key. 
> 
> Expected results:
> Entering correct smart card pin when prompted should authenticate to the kdc.
> User should get Kerberos credential. Should not prompt user for Kerberos
> password.
> 
> Additional info:

Please paste a copy of the certificates from the card so that we can be sure it's not a problem with the client certificates themselves.

Created attachment 442739 [details]
signing cert 0x1e1

Created attachment 442740 [details]
key encipherment cert 0x1e2

When checking the attached certificates with a matching rule consisting of only "<KU>digitalSignature", the pkinit module essentially ignores the key usage bits because it doesn't cause them to be stored in the variable (the certificate's ex_kusage field) from which it attempts to retrieve them.

Due to this bug, neither certificate appears to have a keyUsage extension present, and both are treated as though they satisfy the matching rule, and because the pkinit module can't hone in on exactly one certificate to use as the client's identity, the module returns an error to libkrb5, and kinit moves on to password authentication.

Created attachment 442942 [details]
patch (probably suboptimal) proposed upstream

(In reply to comment #7)
> Created attachment 442942 [details]
> patch (probably suboptimal) proposed upstream

Note: after tracing through the code, that first hunk turns out to be unnecessary.

Created attachment 447050 [details]
additional patch to avoid breaking when one of the potential client certs has no SANs

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
'kinit' with the -X flag for smart card login fails to authenticate to the KDC using the certificate and its private key. It instead prompts for the Kerberos password after
entering the smartcard pin.

There are two cases here.  In both, the client has multiple candidate client certificates (the smart cards we test with contain two: one for signing, another for encryption).  In the first, the client software is configured to select which certificate/key pair to use based on the values of the keyUsage extension in the certificates, but it doesn't read them correctly.  In the other, at least one of the candidates doesn't have a subjectAltName extension, and a logic error causes them all to be rejected.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1,2 +1 @@
-'kinit' with the -X flag for smart card login fails to authenticate to the KDC using the certificate and its private key. It instead prompts for the Kerberos password after
+When attempting to perform PKINIT preauthentication, if the client has more than one possible candidate certificate, the client may fail to select the certificate and key to use when performing PKINIT if certificate selection is configured to use the value of the keyUsage extension, or if any of the candidate certificates does not contain a subjectAltName extension.-entering the smartcard pin.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-When attempting to perform PKINIT preauthentication, if the client has more than one possible candidate certificate, the client may fail to select the certificate and key to use when performing PKINIT if certificate selection is configured to use the value of the keyUsage extension, or if any of the candidate certificates does not contain a subjectAltName extension.+When attempting to perform PKINIT preauthentication, if the client has more than one possible candidate certificate, the client may fail to select the certificate and key to use when performing PKINIT if certificate selection is configured to use the value of the keyUsage extension, or if any of the candidate certificates does not contain a subjectAltName extension.  The client will then typically attempt to perform preauthentication using a different (usually password-based) mechanism.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-When attempting to perform PKINIT preauthentication, if the client has more than one possible candidate certificate, the client may fail to select the certificate and key to use when performing PKINIT if certificate selection is configured to use the value of the keyUsage extension, or if any of the candidate certificates does not contain a subjectAltName extension.  The client will then typically attempt to perform preauthentication using a different (usually password-based) mechanism.+When attempting to perform PKINIT pre-authentication, if the client has more than one possible candidate certificate, the client may fail to select the certificate and key to use. This usually occurs if certificate selection is configured to use the value of the keyUsage extension, or if any of the candidate certificates does not contain a subjectAltName extension.  Consequently, the client attempts to perform pre-authentication using a different (usually password-based) mechanism.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-When attempting to perform PKINIT pre-authentication, if the client has more than one possible candidate certificate, the client may fail to select the certificate and key to use. This usually occurs if certificate selection is configured to use the value of the keyUsage extension, or if any of the candidate certificates does not contain a subjectAltName extension.  Consequently, the client attempts to perform pre-authentication using a different (usually password-based) mechanism.+When attempting to perform PKINIT pre-authentication, if the client has more than one possible candidate certificate the client may fail to select the certificate and key to use. This usually occurs if certificate selection is configured to use the value of the keyUsage extension, or if any of the candidate certificates does not contain a subjectAltName extension.  Consequently, the client attempts to perform pre-authentication using a different (usually password-based) mechanism.

Tested smart card login with kerberos authentication with Rhel 6 KDC.
kinit successfully get the kerberos credential using keys and the certificate. 


$ uname -a
Linux dhcp231-62.rdu.redhat.com 2.6.32-128.el6.x86_64 #1 SMP Mon Mar 28 21:55:33 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux


[ashatest@ ~]$ kinit
Asha PIN: 
[ashatest@ ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_502_TmOYqz
Default principal: ashatest.REDHAT.COM

Valid starting     Expires            Service principal
04/19/11 15:56:00  04/20/11 15:56:00  krbtgt/DSDEV.SJC.REDHAT.COM.REDHAT.COM
	renew until 04/19/11 15:56:00

Marking the bug verified.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2011-0571.html