[39285] in Kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Thu Oct 26 16:37:09 2023
Message-ID: <202310261827.39QIRu4Q000307@hedwig.cmf.nrl.navy.mil>
To: Nico Williams <nico@cryptonector.com>
cc: kerberos@mit.edu
In-Reply-To: <ZTqtQYPlzdpQGyr+@ubby21>
MIME-Version: 1.0
Date: Thu, 26 Oct 2023 14:27:56 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenneth.hornstein.ctr@nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>> As a side note, my impression is that gss-keyex has fallen out of favor,
>> and at least for us part of the problem is the unfortunate decision
>> to use MD5 in that protocol. You and I both know that the use of MD5
>> in there isn't security related, but if you live in a FIPS world
>> then any use of MD5 is a "challenge".
>
>What MD5? It's used for generating a mechanism name, which has no
>security implications. You can hardcode the OID->name mappings so you
>don't invoke MD5.
Ever hear the political adage, "If you're explaining yourself, you're
losing"?. The same adage applies when talking to security people,
especially the non-technical ones. The common gss-keyex code out there
calls the OpenSSL MD5 function at runtime, and some of the distributions
that do ship the gss-keyex code (RedHat) decided to simply disable
gss-keyex code when FIPS is turned on. So yes, you CAN hardcode the
OID->name mappings, but it seems that nobody actually does that.
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
