[39277] in Kerberos

home help back first fref pref prev next nref lref last post

Re: RFC 4121 & acceptor subkey use in MIC token generation

daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Thu Oct 26 13:42:25 2023

Message-ID: <202310261741.39QHfgIl030099@hedwig.cmf.nrl.navy.mil>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
cc: <kerberos@mit.edu>
In-Reply-To: <CALF+FNwtDrQ0d+a=zsXyiYq6rhOiXXkqoxUnscwum0Q0wchLJQ@mail.gmail.com>
MIME-Version: 1.0
Date: Thu, 26 Oct 2023 13:41:42 -0400
From: Ken Hornstein via Kerberos <kerberos@mit.edu>
Reply-To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

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

--Ken
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post