RFC 4121 & acceptor subkey use in MIC token generation

[Greg Hudson]

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.