On 5/18/19 10:49 PM, Dan Mahoney (Gushi) wrote: > mustelid:~ dmahoney$ kinit > dmaho...@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. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
