Hi Greg,
   Thanks for the prompt reply. I think you are right. I mistook
mechListMIC set to GSS_C_NO_BUFFER as an invalid token. These 2 are
different. I added some more logs and here is more detailed information:

In, *init_ctx_cont* the *buf->length* is 9. From *init_ctx_cont*, we call
*get_negTokenResp*, which returns empty *mechListMIC* token with status:
*GSS_S_COMPLETE*.
Progressing in *init_ctx_cont*, we hit the following if-else block


        *....*
*        } else if (!sc->mech_complete ||*



*                   (sc->mic_reqd &&                    (sc->ctx_flags &
GSS_C_INTEG_FLAG))) {                /* Not obviously done; we may decide
we're done later in                 * init_ctx_call_init or handle_mic. */*






*                *tokflag = CONT_TOKEN_SEND;                ret =
GSS_S_COMPLETE;        } else {                /* mech finished on last
pass and no MIC required, so done. */                *tokflag =
NO_TOKEN_SEND;                ret = GSS_S_COMPLETE;        }*
*        ...*

After returning from here, we return back to *spnego_gss_init_sec_context*
function (from where we called *init_ctx_cont*). In this function, the
handle_mic call leads to the problem. Code snippet for the call:

*        ...*



*        negState = ACCEPT_INCOMPLETE;        if (spnego_ctx->mech_complete
&&            (spnego_ctx->ctx_flags & GSS_C_INTEG_FLAG)) {*







*                        ret = handle_mic(minor_status,
                     mechListMIC_in,
 (mechtok_out.length != 0),
 spnego_ctx, &mechListMIC_out,
 &negState, &send_token);                        if (HARD_ERROR(ret))
                          goto cleanup;*
*        ...*

To be more specific, in *handle_mic* function, I hit the following section:

*        ...*










*        } else if (sc->mic_reqd && !send_mechtok) {                /*
           * If the peer sends the final mechanism token, it
 * must send the MIC with that token if the                 * negotiation
requires MICs.                 */                *negState = REJECT;
        *tokflag = ERROR_TOKEN_SEND;                return
GSS_S_DEFECTIVE_TOKEN;        }*
*        ...*

So, I think you were right.

About, the suggestions that were made, I think what you are saying is that
(1) is not possible (or very hard). If you can add more details on (2), I
will be happy to make the change and test it.
Basically, I do not understand if the problem is
(a) The assumption that: if we send one, we should receive one? OR
(b) Sending MIC in the first place.

Regards,
Aman


On Mon, Jul 26, 2021 at 11:53 AM Greg Hudson via RT <
rt@kerborg-prod-app-1.mit.edu> wrote:

> Thanks for the comprehensive interop issue report.  I have one question:
>
> > In function, src/lib/gssapi/spnego/spnego_mech.c: get_negTokenResp we
> return
> error code that it is a defective token.
>
> This function should only return a defective token error if the packet has
> a
> bad length, which does not appear to be the case.  Is it possible that the
> error came from handle_mic() at the first else-if clause?
>
> Some background:
>
> * RFC 4178 (SPNEGO) section 5 only requires a mechlistMIC exchange if the
> negotiated mech is not the most-preferred mech of one of the two parties.
> Otherwise the MIC exchange is optional (unless the negotiated mech has no
> MIC
> support, in which case it's impossible).
>
> * RFC 4178 section 5 (c) (I) says, for the acceptor processing the final
> initiator token: "If a mechlistMIC token was included and is correctly
> verified, GSS_Accept_sec_context() indicates GSS_S_COMPLETE.  The output
> negotiation message contains a mechlistMIC token and an accept_complete
> state."
>
> In this exchange both parties prefer NTLMSSP, so one would expect the MIC
> exchange to be optional.   However, Microsoft imposes an additional
> constraint
> for NTLMSSP.  This is both observed and documented; [MS-SPNG] Appendix A
> says:
>
>     If NTLM authentication is most preferred by the client and the server,
> and
> the
>     client includes a MIC in AUTHENTICATE_MESSAGE ([MS-NLMP] section
>     2.2.1.3), then the mechListMIC field becomes mandatory in order for the
>     authentication to succeed. Windows clients in this case send an NTLM
> token
>     instead of an SPNEGO token.
>
> Accordingly, we have a helper mech_requires_mechlistMIC(), so that NTLMSSP
> can
> report that it's behaving in a way that causes a SPNEGO MIC to be
> required.
> In our code, the MIC requirement is treated as symmetrical; if we send
> one, we
> believe we must receive one, and (following RFC 4178 5.c.I) if we receive
> one,
> we send one.
>
> From the packet traces it would appear that the Azure server does not
> believe
> a MIC is required (i.e. it is not behaving according to [MS-SPNG] Appendix
> A)
> and isn't sending a MIC in response to the initiator's MIC (i.e. it it
> violates RFC 4178 section 5(c)(I)).  This apparent misbehavior could be
> accomodated in two ways:
>
> 1. Following the hint in [MS-SPNG] Appendix A, the application could send
> an
> NTLM token instead of a SPNEGO token.  Generally if a client prefers NTLM,
> it
> can only do NTLM, so negotiation isn't required.  However, it may be
> difficult
> for an application using MIT krb5 to implement this due to the abstraction
> boundaries; the application doesn't know that the client is only capable of
> NTLM and the SPNEGO layer can't generate a non-SPNEGO token.
>
> 2. In our SPNEGO layer, a true result from mech_requires_mechlistMIC()
> could
> cause a MIC token to be generated, but not required from the other party.
>
>
>