content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Content-Length: 1536

Hi,
   We are using MIT krb5 with libsmb2: https://github.com/sahlberg/libsmb2/
and GSS implementation from here: https://github.com/gssapi/gss-ntlmssp. I
have attached the packet taces for the following:
-- Packet traces for authentication with azure [tcp_azure.pcap].
-- Packet traces of authentication with windows server (which also requires
MIC, encryption) [tcp_new_win_enc_test.pcap].
-- Packet traces for authentication with Samba [tcp_azure_old.pcap]

In authentication with Azure files Samba server, the session setup response
from the server (4th packet of 4) has a security blob of length only 9. In
function, src/lib/gssapi/spnego/spnego_mech.c: get_negTokenResp we return
error code that it is a defective token. As a result of this, we clean up
the gss context and then we are not able to retrieve the session key (which
would be required for encryption).

I tried the same with the Samba client and it works.

What could be the problem?
-- Is the token defective and clean up of the context is the
right approach? In this case, it needs to be handled in another layer. Not
sure if that is possible.
-- If we have received the MIC in the 3rd packet of session setup response,
do not make it mandatory to send MIC in the 4th packet. Can this be a
solution?
-- Do not clean up when we get the defective token from the 4th packet.

Regards,
Aman

P.S.: I do not have much idea on how the protocol works, and the above
understanding is gained by putting working on this issue. Please pardon any
mistakes in the bug analysis.