home | help | back | first | fref | pref | prev | next | nref | lref | last | post |
MIME-Version: 1.0 In-Reply-To: <ZTk62q0DIAZmW0eL@ubby21> From: Jeffrey Hutzelman <jhutz@cmu.edu> Date: Wed, 25 Oct 2023 12:16:15 -0400 Message-ID: <CALF+FNwtDrQ0d+a=zsXyiYq6rhOiXXkqoxUnscwum0Q0wchLJQ@mail.gmail.com> To: Nico Williams <nico@cryptonector.com> Cc: Ken Hornstein <kenh@cmf.nrl.navy.mil>, Jonathan Calmels via Kerberos <kerberos@mit.edu> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kerberos-bounces@mit.edu On Wed, Oct 25, 2023, 11:59 Nico Williams <nico@cryptonector.com> wrote: > On Wed, Oct 25, 2023 at 08:51:29AM -0400, Ken Hornstein wrote: > > I think we've lost the thread here; I do not think that any krb5 > > mechanism today ever asserts PROT_READY before GSS_S_COMPLETE, but I > > would love to be proven wrong. > > That's the whole point of being able to use the initiator sub-session > key: to allow the Kerberos GSS mechanism to assert PROT_READY on the > first call to GSS_Init_sec_context() even when mutual auth is requested. > > Yes, RFC 4121 didn't say so, but it's the point. > 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. In any case, I think the behavior Ken is seeing is that the initiator doesn't even assert a subkey -- it always uses the ticket session key. That seems... unfortunate. -- Jeff > ________________________________________________ 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 |