Preauth / AES / MIT Kerberos / TGT des3-cbc-sha1
John Tang Boyland
boyland at pabst.cs.uwm.edu
Mon Feb 12 10:37:45 EST 2018
Apple's kinit is now complaining if a KDC generates a des3 ticket:
Encryption type des3-cbc-sha1(16) used for authentication is weak and will be deprecated
If one uses the "-e" option, one gets the message:
$ /usr/bin/kinit -e aes128-cts-hmac-sha1-96 test@<REALM>
test@<REALM>'s password:
kinit: krb5_get_init_creds: Preauth required but no preauth options send by KDC
But the principle in question has the REQUIRES_PRE_AUTH flag:
kadmin: getprinc test
Principal: test@<REALM>
...
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Failed password attempts: 0
Number of keys: 1
Key: vno 2, aes256-cts-hmac-sha1-96
MKey: vno 1
Attributes: REQUIRES_PRE_AUTH
Policy: [none]
If I use kinit without the -e option, I get:
$ /usr/bin/klist --verbose
Credentials cache: API:D6263E03-4C49-46C2-80B5-9C72FF37009B
Principal: test@<REALM>
Cache version: 0
Server: krbtgt/<REALM>@<REALM>
Client: test@<REALM>
Ticket etype: des3-cbc-sha1, kvno 1
Ticket length: 318
Auth time: Feb 12 08:23:42 2018
End time: Feb 12 18:23:37 2018
Ticket flags: enc-pa-rep, pre-authent, initial, forwardable
Addresses: addressless
When I describe the krb5-admin-server package on the admin server, I see
Package: krb5-admin-server
Architecture: amd64
Version: 1.13.2+dfsg-5ubuntu2
Priority: optional
Section: universe/net
Source: krb5
Origin: Ubuntu
...
In an attempt to prevent krb5-kdc from using these insecure encryption
types, I added the following to krb5.conf:
default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96
Then the client claims that KDC has no support for encryption type while getting
initial credentials.
(I also tried just using "aes" which the documentation also suggests)
What's going on? Does MIT kerberos not actually support AES256?
or is the online documentation that claims that these aes encryption types
are supported wrong?
Best regards,
John
More information about the Kerberos
mailing list