Preauth / AES / MIT Kerberos / TGT des3-cbc-sha1

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Preauth / AES / MIT Kerberos / TGT des3-cbc-sha1

John Tang Boyland
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

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Preauth / AES / MIT Kerberos / TGT des3-cbc-sha1

Greg Hudson
On 02/12/2018 10:37 AM, John Tang Boyland wrote:
> What's going on?  Does MIT kerberos not actually support AES256?

Check the keys for the krbtgt/<REALM> principal entry.  The ticket will
always be encrypted in the first of those keys.  I suspect that key is des3.

To explain your three different results:

1. When you use kinit normally, the KDC chooses aes256-cts to encrypt
the reply (you can't see this), des3 to encrypt the ticket, and probably
des3 for the session key.

2. When you use "kinit -e aes128-cts", the KDC can't find a match
between the request enctypes and the client principal keys, since the
client principal has only an aes256-cts key.  The KDC should respond
with a "KDC has no support for encryption type" error, but instead it
says something nonsensical: "you have to do preauth, but I don't have
any preauth mechs which will work".  I will file a ticket for this KDC
behavior.  The Apple kinit has a special error message for this
response, which could probably be improved (but not by a lot; it's hard
to say something useful to a user in this case).

3. When you restrict the request enctypes to aes256-cts aes128-cts
through configuration, the KDC can't select a session key enctype
agreeable to both the request and the server (it assumes that the
server, in this case krbtgt/<REALM>, can only support ticket session
keys matching the enctypes it has keys for).  So it responds with a "KDC
has no support for encryption type" error.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Preauth / AES / MIT Kerberos / TGT des3-cbc-sha1

John Tang Boyland
In reply to this post by John Tang Boyland
Thanks very much!

Your information was very much on target.
(I was embarrassed to see that I had set
a 256 key and asked for a 128 key.)

There is the possible error in your reply that
even changing the 'test' principal to
have both aes128 and aes256 keys was not sufficient
to make Apple's kinit work.  But that was before
adding the new keys for the krbtgt/<REALM>.

Adding new keys for krbtgt/<REALM> did the trick.
Everything works now:

$ /usr/bin/kinit -e aes128-cts-hmac-sha1-96 test@<REALM>
test@<REALM>'s password:
$ /usr/bin/klist -v
Credentials cache: API:503:2
        Principal: test@<REALM>
            Cache version: 0

Server: krbtgt/<REALM>@<REALM>
Client: test@<REALM>
Ticket etype: aes128-cts-hmac-sha1-96, kvno 2
Ticket length: 299
Auth time:  Feb 12 12:50:15 2018
End time:   Feb 12 22:50:12 2018
Ticket flags: enc-pa-rep, pre-authent, initial, forwardable
Addresses: addressless

Best regards,
John Boyland

] On 02/12/2018 10:37 AM, John Tang Boyland wrote:
] > What's going on?  Does MIT kerberos not actually support AES256?
]
] Check the keys for the krbtgt/<REALM> principal entry.  The ticket will
] always be encrypted in the first of those keys.  I suspect that key is des3.
]
] To explain your three different results:
]
] 1. When you use kinit normally, the KDC chooses aes256-cts to encrypt
] the reply (you can't see this), des3 to encrypt the ticket, and probably
] des3 for the session key.
]
] 2. When you use "kinit -e aes128-cts", the KDC can't find a match
] between the request enctypes and the client principal keys, since the
] client principal has only an aes256-cts key.  The KDC should respond
] with a "KDC has no support for encryption type" error, but instead it
] says something nonsensical: "you have to do preauth, but I don't have
] any preauth mechs which will work".  I will file a ticket for this KDC
] behavior.  The Apple kinit has a special error message for this
] response, which could probably be improved (but not by a lot; it's hard
] to say something useful to a user in this case).
]
] 3. When you restrict the request enctypes to aes256-cts aes128-cts
] through configuration, the KDC can't select a session key enctype
] agreeable to both the request and the server (it assumes that the
] server, in this case krbtgt/<REALM>, can only support ticket session
] keys matching the enctypes it has keys for).  So it responds with a "KDC
] has no support for encryption type" error.
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos