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