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

[Wyllys Ingersoll via RT]

Sam Hartman via RT wrote:
>>>>>>"Wyllys" == Wyllys Ingersoll via RT <rt-comment at krbdev.mit.edu> writes:
> 
> 
>     Wyllys> When using mutual authentication, at the time the initial
>     Wyllys> token is generated, the status is still "CONTINUE_NEEDED"
>     Wyllys> and the context->established flag is not set even though
>     Wyllys> the PROT_READY flag is set and the subkey is available.
>     Wyllys> We think (Nico and I) that gss_get_mic should be able to
>     Wyllys> succeed in this case.  I had not considered the "unseal"
>     Wyllys> case since that was not a problem.  The acceptor side
>     Wyllys> context is already "established" when the MIC is verified,
>     Wyllys> so it wasnt a problem.
> 
> But you should not be generating the MIC at this point.
>  negTokenInit
>       Negotiation token sent by the initiator to the target, which
>       contains, for the first token sent, one or more security mechanisms
>       supported by the initiator (as indicated in the field mechTypes)
>       and the service options (reqFlags) that are requested to establish
>       the context. The context flags should be filled in from the
>       req_flags parameter of init_sec_context().
> 
>       The mechToken field is optional for the first token sent that all
>       target implementations would not have to support. However for those
>       targets that do support piggybacking the initial mechToken, an
>       optimistic negotiation response is possible. Otherwise the
>       mechToken is used to carry the tokens specific to the mechanism
>       selected.
> 
> 
> 
> 
> 
>  Baize & Pinkas              Standards Track                     [Page 7]
>  
>  RFC 2478             GSS-API Negotiation Mechanism         December 1998
> 
> 
>       The mechListMIC is an optional field. In the case that the chosen
>       mechanism supports integrity, the initiator may optionally include
>       a mechListMIC which is the result of a GetMIC of the MechTypes in
>       the initial NegTokenInit and return GSS_S_COMPLETE.
> 
> 
> That text from 2478 indicates you can only include the mechlistmic in
> the initial token when the mechanism returns GSS_S_COMPLETE.
> 

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?

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.

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

-Wyllys