Questions about supported_enctypes
Greg Hudson
ghudson at mit.edu
Sun May 19 01:26:33 EDT 2019
On 5/18/19 10:49 PM, Dan Mahoney (Gushi) wrote:
> mustelid:~ dmahoney$ kinit
> dmahoney at FOO.ORG's password:
> Encryption type des3-cbc-sha1(16) used for authentication is weak and will
> be deprecated
>
> Searching for this message yields surprisingly little.
I believe this message is specific to Apple's fork of Heimdal. I can
find it in their source code from opensource.apple.com, but not in
mainline Heimdal.
> My install of mojave has no krb5.conf, so it's using whatever the
> compiled-in defaults are. Here are my questions, then.
>
> q1: Is there a way of seeing what those are? (Or, of spewing out a
> krb5.conf that reflects the defaults?)
On my macOS machine, "man krb5.conf" displays the defaults for each
variable, but I'm not sure it's displayed in a useful way, since the
default_etypes default is documented as "all enctypes".
The client-side defaults are probably not the issue here anyway.
> q2: Is there a way of seeing which enctypes are supported on a krb5kdc
> (i.e. as part of the kinit process, not by looking in the filesystem).
Not really. KDCs don't supply a list of supported enctypes during the
initial ticket exchange. They do supply something called etype-info,
which the client uses the correctly convert the password into the key
needed to decrypt the reply. Some versions of KDC software will look at
the request enctypes and pick just one key to supply etype-info for
(using the highest-preference enctype), so you don't get a full view of
what long-term keys are present in the client principal entry. Other
versions will give etype-info for each key in the client principal
entry--but the keys in the server principal entry are also relevant for
the session key, and the KDC doesn't supply information about those.
Also, kinit isn't very forthcoming about what was in etype-info, so
you'd have to use wireshark or similar to look at it.
Since (based on the warning) a des3-cbc-sha1 key was chosen either for
the reply key or the session key, it's a good bet that either the client
principal or the realm's krbtgt principal has a des3-cbc-sha1 key and no
AES keys.
> q3: On the same note, what are others in the modern world moving to with
> this algo being deprecated? Is there a current recommendation? If one
> disables des3-cbc-sha1, what versions of kerberos are you effectively
> blackholing?
Any Kerberos implementation from the last 15 or so years will support
the aes-sha1 enctypes, so aes256-cts-hmac-sha1-96 should interoperate
with everything you're likely to run into. des3-cbc-sha1 doesn't see a
lot of use because it was introduced not long before the aes-sha1
enctypes, and because it was never implemented by Microsoft (only MIT
krb5 and Heimdal).
> (I have no idea about apple's internal processes, or what other vendors
> are following suit).
I think Apple has traditionally been more aggressive than the rest of
the ecosystem, having completely removed single-DES support a while ago
and now warning about des3 and rc4.
MIT krb5 is tentatively planning to remove single-DES support in 1.18
and deprecate triple-DES. I believe Fedora plans to remove both
single-DES and triple-DES support in the next release.
More information about the Kerberos
mailing list