Bug 679012
| Summary: | kinit no longer works in krb5-workstation-1.9-6.fc16 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Adam Tkac <atkac> | ||||
| Component: | krb5 | Assignee: | Nalin Dahyabhai <nalin> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | 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 13:57:05 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Adam Tkac
2011-02-21 09:48:13 UTC
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. |