[krbdev.mit.edu #1352] Cannot return prot_ready without unwrap working

[Nicolas Williams via RT]

On Fri, Feb 21, 2003 at 03:01:36PM -0500, Wyllys Ingersoll wrote:
> I think it is saying that you can include a mechlistMIC (optionally) and then
> return GSS_S_COMPLETE,  it does not say that you can only include the
> MIC after you get a GSS_S_COMPLETE status.  I think that would be impossible
> or at least rather useless.
> 
> The whole point of the MIC is so the acceptor can verify that the mechList was
> not modified in transit, so what good would it be to include the MIC only after
> the exchange was completed?

Including it early is nothing more than an optimistic optimization, and,
as such, good, but not absolutely central to security (although, work
avoidance is important if you want to limit DoS attacks, but in this
case I don't think that's a big deal).

> Once the initiator has the initial token from the underlying mech (Krb5) and it
> is preparing the SPNEGO NegTokenInit message, it should be able to MIC the
> mechList that it is including, even if the current status is GSS_S_CONTINUE_NEEDED,
> otherwise, there is no way to send a MIC.

The RFC2478 text makes sense if one thinks of odd-message exchanges,
such as a Kerberos exchange with no mutual auth, where the client sends
one more message than the server (in the Kerb no mutual auth case the
client sends one message and the server none (unless there's an error,
right?).

But even so, I think it makes plenty of sense to allow the client to
send the MIC as soon as the mech it picks to negotiate for
optimistically is ready to do so.

> I guess the inclusion of the MIC is optional, but it seems that Kerberos should be
> capable of supporting this feature.   I've included it in my implementation (at least
> for now).

I see no text in RFC2478 barring this, though the RFC does not
contemplate it.

Cheers,

Nico
--