RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 629022 - 'kinit' with smart card login fails to authenticate to the kdc using the cert and its private key.
Summary: 'kinit' with smart card login fails to authenticate to the kdc using the cert...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: krb5
Version: 6.0
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Nalin Dahyabhai
QA Contact: BaseOS QE Security Team
URL: http://krbdev.mit.edu/rt/Ticket/Displ...
Whiteboard:
Depends On: 629274
Blocks: 580448 644825
TreeView+ depends on / blocked
 
Reported: 2010-08-31 17:35 UTC by Asha Akkiangady
Modified: 2011-05-19 13:11 UTC (History)
10 users (show)

Fixed In Version: krb5-1.8.2-4.el6
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Environment:
Last Closed: 2011-05-19 13:11:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
signing cert 0x1e1 (1.15 KB, text/plain)
2010-09-02 21:46 UTC, Nalin Dahyabhai 		no flags Details
key encipherment cert 0x1e2 (1.15 KB, text/plain)
2010-09-02 21:47 UTC, Nalin Dahyabhai 		no flags Details
patch (probably suboptimal) proposed upstream (1.13 KB, patch)
2010-09-03 17:44 UTC, Nalin Dahyabhai 		no flags Details | Diff
additional patch to avoid breaking when one of the potential client certs has no SANs (1.39 KB, patch)
2010-09-13 21:29 UTC, Nalin Dahyabhai 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:0571 0 normal SHIPPED_LIVE krb5 bugfix update 2011-05-18 17:57:04 UTC

Description Asha Akkiangady 2010-08-31 17:35:00 UTC 
Description of problem:
'kinit' with smart card login (-X flag) fails to authenticate to the kdc using the cert and its private key. It prompts for the Kerberos password after entering the smartcard pin.

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Configured a Rhel 6 desktop to do smartcard login. loaded up root certs onto /etc/pki/nssdb.
2. Edit /etc/krb5.conf with the KDC and the client ticket details. Configure krb5.conf with trust anchors, example:
  pkinit_anchors = FILE:/etc/pki/nssdb/kdc-ca.pem
  pkinit_cert_match = <KU>digitalSignature

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

4. /etc/pki/nssdb/kdc-ca.pem contains CA certificates in base64 encoded format. CA that issued smart card and CA that issued KDC certificate.

kdc-ca.pem on KDC has these CA certificates.

5. Used the card to perform smart card login. 

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:
Comment 1 Asha Akkiangady 2010-08-31 17:40:04 UTC 
Note: KDC is installed on Rhel 6.
Comment 3 Nalin Dahyabhai 2010-08-31 18:04:45 UTC 
> 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.
Comment 4 Nalin Dahyabhai 2010-09-02 21:46:35 UTC 
Created attachment 442739 [details]
signing cert 0x1e1
Comment 5 Nalin Dahyabhai 2010-09-02 21:47:17 UTC 
Created attachment 442740 [details]
key encipherment cert 0x1e2
Comment 6 Nalin Dahyabhai 2010-09-02 21:50:56 UTC 
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.
Comment 7 Nalin Dahyabhai 2010-09-03 17:44:49 UTC 
Created attachment 442942 [details]
patch (probably suboptimal) proposed upstream
Comment 8 Nalin Dahyabhai 2010-09-10 19:55:15 UTC 
(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.
Comment 9 Nalin Dahyabhai 2010-09-13 21:29:40 UTC 
Created attachment 447050 [details]
additional patch to avoid breaking when one of the potential client certs has no SANs
Comment 16 Denise Dumas 2010-09-16 15:44:11 UTC 
    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.
Comment 17 Nalin Dahyabhai 2010-09-16 16:31:36 UTC 
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.
Comment 19 Nalin Dahyabhai 2010-09-20 15:05:03 UTC 
    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.
Comment 20 Nalin Dahyabhai 2010-09-20 15:06:12 UTC 
    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.
Comment 23 Ryan Lerch 2010-10-14 00:20:58 UTC 
    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.
Comment 25 Ryan Lerch 2010-10-14 01:49:34 UTC 
    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.
Comment 29 Asha Akkiangady 2011-04-19 20:04:05 UTC 
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.
Comment 30 errata-xmlrpc 2011-05-19 13:11:52 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.