RFC 4121 & acceptor subkey use in MIC token generation

[Ken Hornstein]

>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.

I mean, fair enough; I understand what Nico was saying as to the
intention; my point is just that it seems that (a) MIT Kerberos only
sets the PROT_READY flag when GSS_S_COMPLETE is returned, and Heimdal
sets it ... never?  At least that's what the MacOS X version of Heimdal
seems to do.  So if there ARE apps that actually look at the PROT_READY
flag, it seems like at least if they're using Kerberos mechanisms they
never actually will see it which makes me wonder if anyone ever actually
tested this, ever.  No idea what the GSS code in Microsoft will do.

>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.

It's worse: the initiator doesn't assert a subkey (which I can
personally live with) but also ignores the subkey asserted in the
AP-REP, at least for ssh authentication code (there are comments that
say they do look at the subkey when doing tests that involve SMB).
Like I said, this works with MIT Kerberos because they don't actually
enforce the RFC's MUST, based on (what I argued was wrong) a 20 year
old comment.

--Ken