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

[Sam Hartman via RT]

>>>>> "Wyllys" == Wyllys Ingersoll via RT <rt-comment at krbdev.mit.edu> writes:


    Wyllys> I think it is saying that you can include a mechlistMIC
    Wyllys> (optionally) and then return GSS_S_COMPLETE, it does not
    Wyllys> say that you can only include the MIC after you get a
    Wyllys> GSS_S_COMPLETE status.  I think that would be impossible
    Wyllys> or at least rather useless.

No, it is what you should do in the non-mutual authentication case for
Kerberos.

    Wyllys> The whole point of the MIC is so the acceptor can verify
    Wyllys> that the mechList was not modified in transit, so what
    Wyllys> good would it be to include the MIC only after the
    Wyllys> exchange was completed?

That's how SPNEGO works.  The last step in the process is the acceptor
verifies the MIC and returns GSS_S_COMPLETE or fails to verify the MIC
and returns GSS_S_FAILURE.

Quoting the RFC:


    If the mechanism supports integrity and uses an even number of
    messages, then the target must compute a MIC as described above, and
    send this in the final NegTokenTarg along with the final mechToken.
    The initiator when receiving the last token must require that the
    mechListMIC field be present and valid. In the absence of a valid
    mechListMIC, the negotiation must fail as if the last context
    establishment token was invalid.

    In the case that the chosen mechanism supports integrity and uses an
    odd number of messages, the final mechanism token will be sent from
    the initiator to the target. In this case, there is a tradeoff
    between using the optimal number of messages, or using an additional
    message from the target to the initiator in order to give the
    initiator assurance that no modification of the initiator's mechanism
    list occurred. The implementation can choose which tradeoff to make.

    When generating the final NegTokenInit message, the NegTokenInit may
    optionally include a mechListMIC which is the result of a GetMIC of
    the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE.
    The target must check the presence of the MIC computed over the
    mechList sent in the initial NegTokenInit. Three cases may then be
    considered:

       1) If the mechListMIC is present and correct, then
          GSS_S_COMPLETE is returned to the target with no token; the
          context is established by the target.

       2) If the mechListMIC is present but invalid, then the context
          establishment must fail.  An error major status code is
          returned to the target.

       3) If the mechListMIC is not included in the final NegTokenInit,
          then GSS_S_COMPLETE must be returned to the target with a
          token. This token must be a NegTokenTarg, with a MIC included
          as described above, and no responseToken.  The application will
          then send this token back to the initiator, which must verify
          that the mechListMIC field is present and valid.




That text makes it quite clear the  mechlistmic is not sent as early
as possible but rather as late as possible.