content-type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Content-Length: 1859

<div dir="ltr">Hi,<div>   We are using MIT krb5 with libsmb2: <a href="https://github.com/sahlberg/libsmb2/">https://github.com/sahlberg/libsmb2/</a> and GSS implementation from here: <a href="https://github.com/gssapi/gss-ntlmssp">https://github.com/gssapi/gss-ntlmssp</a>. I have attached the packet taces for the following:</div><div>-- Packet traces for authentication with azure [tcp_azure.pcap].</div><div>-- Packet traces of authentication with windows server (which also requires MIC, encryption) [tcp_new_win_enc_test.pcap].</div><div>-- Packet traces for authentication with Samba [tcp_azure_old.pcap]</div><div><br></div><div>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).</div><div><br></div><div>I tried the same with the Samba client and it works.</div><div><br></div><div>What could be the problem?</div><div>-- 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.</div><div>-- 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?</div><div>-- Do not clean up when we get the defective token from the 4th packet. </div><div><br></div><div>Regards,<br></div><div>Aman<br><br>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.</div></div>