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 Password for atkac: 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.
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.
(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.
(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.
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.
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?
CKM_NETSCAPE_PBE_SHA1_DES_CBC is PBKDF1. Is MIT using something non-standard? bob
(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.
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.