Questions about supported_enctypes

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

Questions about supported_enctypes

Dan Mahoney (Gushi)
All,

When I kinit from my macOS mojave machine against $dayjob's kdc, I get the
following

mustelid:~ dmahoney$ kinit
[hidden email]'s password:
Encryption type des3-cbc-sha1(16) used for authentication is weak and will
be deprecated

Searching for this message yields surprisingly little.

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?)

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).

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?

I've found links on the mit.edu page about des
(single-des) being deprecated, but not 3des yet:

https://web.mit.edu/kerberos/www/krb5-1.12/doc/admin/advanced/retiring-des.html

But deprecation of 3des is mentioned in this internet draft:

https://tools.ietf.org/id/draft-ietf-curdle-des-des-des-die-die-die-01.html

(I have no idea about apple's internal processes, or what other vendors
are following suit).

-Dan

--

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
FB:  fb.com/DanielMahoneyIV
LI:   linkedin.com/in/gushi
Site:  http://www.gushi.org
---------------------------

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

Re: Questions about supported_enctypes

Greg Hudson
On 5/18/19 10:49 PM, Dan Mahoney (Gushi) wrote:
> mustelid:~ dmahoney$ kinit
> [hidden email]'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           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: Questions about supported_enctypes

Robbie Harwood
Greg Hudson <[hidden email]> writes:

> On 5/18/19 10:49 PM, Dan Mahoney (Gushi) wrote:
>
>> 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).
A breakdown of the why and what was conducted as part of rfc8429
(https://tools.ietf.org/html/rfc8429), which you may find helpful as
well.

>> (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.
That's correct - I'm removing 3DES/1DES wholesale in Fedora 31.  The
change page for that is
https://fedoraproject.org/wiki/Changes/krb5_crypto_modernization , but
it's mostly a re-hash of what's been said above.

Thanks,
--Robbie

________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos

signature.asc (847 bytes) Download Attachment