[39269] in Kerberos
Re: RFC 4121 & acceptor subkey use in MIC token generation
daemon@ATHENA.MIT.EDU (Ken Hornstein via Kerberos)
Tue Oct 24 20:38:03 2023
Message-ID: <202310250036.39P0aVZr017365@hedwig.cmf.nrl.navy.mil>
To: kerberos@mit.edu
In-Reply-To: <3db2752e-565e-1f64-b354-9031a2fe9334@mit.edu>
MIME-Version: 1.0
Date: Tue, 24 Oct 2023 20:36:31 -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
>Whether the initiator can generate per-message tokens before receiving
>the subkey depends on whether the mechanism returned the prot_ready
>state (RFC 2743 section 1.2.7) to the caller after generating the
>initiator token. RFC 4121 does not mention prot_ready; I couldn't say
>whether that's an implicit contraindication on setting the bit. I'm not
>aware of any krb5 mechs setting the bit at that point in the initiator,
>although I recall Nico talking about maybe wanting to do so.
Fair enough; every time I think I might understand the GSSAPI, there
is always something else in that mess. I don't think given subkey
negotiation it would be possible for a krb5 mechanism to legitimately
set prot_ready before authentication was complete, but it sure seems
like this is a corner case. Certainly it seems like Heimdal always
assumes that the other end will behave that way.
>The comment was written twenty years ago by a developer no longer
>working for MIT, and I don't recall having any conversations about it
>before this one.
NOW I feel old :-/
--Ken
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
