[39278] in Kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Oct 26 14:17:56 2023
Date: Thu, 26 Oct 2023 13:17:37 -0500
From: Nico Williams <nico@cryptonector.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Cc: Jeffrey Hutzelman <jhutz@cmu.edu>, kerberos@mit.edu
Message-ID: <ZTqtQYPlzdpQGyr+@ubby21>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <202310261741.39QHfgIl030099@hedwig.cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Thu, Oct 26, 2023 at 01:41:42PM -0400, Ken Hornstein via Kerberos wrote:
> >Yeah; IIRC that was to allow cases where the initiator would send the first
> >context token in the same packet/message with early data, such as a MIC
> >binding the exchange to some channel. In retrospect, perhaps it has caused
> >more trouble than it was worth. We didn't use this in RFC 4462 userauth,
> >which doesn't use mutual anyway.
>
> 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.
Nico
--
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
