Bug 679012

Summary: kinit no longer works in krb5-workstation-1.9-6.fc16
Product: [Fedora] Fedora Reporter: Adam Tkac <atkac>
Component: krb5Assignee: Nalin Dahyabhai <nalin>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: djasa, dodji, nalin, ovasik, rrelyea, tbzatek
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
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:
Attachments:
Description Flags
small test harness none

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.