RFC 4121 & acceptor subkey use in MIC token generation
Greg Hudson
ghudson at mit.edu
Tue Oct 24 20:09:20 EDT 2023
On 10/24/23 15:50, Ken Hornstein via Kerberos wrote:
[Disputing the following comment in k5sealv3.c:]
> First, we can't really enforce the use of the acceptor's subkey,
> if we're the acceptor; the initiator may have sent messages
> before getting the subkey. We could probably enforce it if
> we're the initiator.
> I was under the impression
> that when you're doing mutual authentication (which in my experience
> is pretty much all of the time) you can't send any other GSSAPI tokens
> until authentication is complete and if authentication is complete then
> you can definiteley be assured any subkeys have already been exchanged.
> Clearly Heimdal enforces this and other than this obviously wrong client
> code I am not aware of any operational issues. Am I wrong? I admit
> that is always a possibility!
I believe mutual authentication is frequently omitted for HTTP
negotiate, but that's a minor point as in that case there's no acceptor
subkey.
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.
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.
More information about the Kerberos
mailing list