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.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
