Bug 679012 - kinit no longer works in krb5-workstation-1.9-6.fc16
kinit no longer works in krb5-workstation-1.9-6.fc16
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: krb5 (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Nalin Dahyabhai
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-21 04:48 EST by Adam Tkac
Modified: 2013-04-30 19:48 EDT (History)
6 users (show)

See Also:
Fixed In Version: krb5-1.9-7.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-03-21 09:57:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
small test harness (1.02 KB, text/plain)
2011-02-24 18:12 EST, Nalin Dahyabhai
no flags Details

  None (edit)
Description Adam Tkac 2011-02-21 04:48:13 EST
Description of problem:
kinit no longer works in krb5-workstation-1.9-6.fc16. I can't obtain Kerberos TGT when I type correct password.

Version-Release number of selected component (if applicable):
krb5-workstation-1.9-6.fc16.x86_64

How reproducible:
always

Steps to Reproduce:
1. kinit
2. type correct password
  
Actual results:
$ kinit -V
Using default cache: /tmp/krb5cc_500
Using principal: atkac@REDHAT.COM
Password for atkac@REDHAT.COM: 
kinit: Password incorrect while getting initial credentials

Expected results:
successfully obtained TGT

Additional info:
When I downgrade krb5-* packages to 1.9-5.fc15 everything is OK.
Comment 1 Nalin Dahyabhai 2011-02-21 10:16:11 EST
Is "allow_weak_crypto" enabled in your client system's /etc/krb5.conf?

Can you get a packet capture of the AS-REP coming from the KDC?  The credentials it contains should be encrypted with your key, and I'm curious as to which cipher is being used if it worked for a non-NSS build but doesn't when built with NSS for libk5crypto.
Comment 2 Adam Tkac 2011-02-21 10:57:28 EST
(In reply to comment #1)
> Is "allow_weak_crypto" enabled in your client system's /etc/krb5.conf?

Yes it is. Without "allow_weak_crypto" kinit refuses to obtain TGT.

> Can you get a packet capture of the AS-REP coming from the KDC?  The
> credentials it contains should be encrypted with your key, and I'm curious as
> to which cipher is being used if it worked for a non-NSS build but doesn't when
> built with NSS for libk5crypto.

All except the "Ticket" section in AS-REP is encrypted via des-cbc-crc. The "Ticket" section is encrypted via aes256-cts-hmac-sha1-96.

Let me know if this information is not sufficient, I will send complete network traffic dump to your mail, I would rather not attach it here.
Comment 3 Nalin Dahyabhai 2011-02-24 16:28:53 EST
(In reply to comment #2)
> (In reply to comment #1)
> > Can you get a packet capture of the AS-REP coming from the KDC?  The
> > credentials it contains should be encrypted with your key, and I'm curious as
> > to which cipher is being used if it worked for a non-NSS build but doesn't when
> > built with NSS for libk5crypto.
> 
> All except the "Ticket" section in AS-REP is encrypted via des-cbc-crc. The
> "Ticket" section is encrypted via aes256-cts-hmac-sha1-96.

That suggests that the client's libraries aren't converting your password to a des-cbc-crc key in a way that produces the same key they used to.
Comment 4 Nalin Dahyabhai 2011-02-24 18:12:34 EST
Created attachment 480880 [details]
small test harness

Invoked with arguments "password" and "ATHENA.MIT.EDUraeburn", gives a result that doesn't match rfc3961's test vector when libk5crypto is using NSS.
Comment 5 Nalin Dahyabhai 2011-02-24 18:18:55 EST
Bob, the NSS code appears to be assuming that CKM_NETSCAPE_PBE_SHA1_DES_CBC is an MIT-style string-to-key, but it appears to be a PBKDF1 string-to-key.  Am I reading that right?
Comment 6 Bob Relyea 2011-02-28 20:29:23 EST
CKM_NETSCAPE_PBE_SHA1_DES_CBC is PBKDF1. Is MIT using something non-standard?

bob
Comment 7 Nalin Dahyabhai 2011-03-01 13:20:17 EST
(In reply to comment #6)
> CKM_NETSCAPE_PBE_SHA1_DES_CBC is PBKDF1. Is MIT using something non-standard?

Kerberos is, yes.  The best description is probably in RFC3961 section 6.2, and of course there's the "builtin" implementation.
Comment 8 Nalin Dahyabhai 2011-03-21 09:57:05 EDT
Switched back to built-in crypto for 1.9-7.fc16.  It should work properly in the next upstream version, so we'll switch back to NSS then.

Note You need to log in before you can comment on or make changes to this bug.