[krbdev.mit.edu #9018] Bugs while authenticating to azure files

[Amandeep Gautam via RT]

Mon Jul 26 10:58:12 2021: Request 9018 was acted upon.
 Transaction: Ticket created by amandeepgautam5 at gmail.com
       Queue: krb5
     Subject: Bugs while authenticating to azure files
       Owner: Nobody
  Requestors: amandeepgautam5 at gmail.com
      Status: new
 Ticket <URL: http://kerborg-prod-app-1.mit.edu/rt/Ticket/Display.html?id=9018 >


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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcp_azure.pcap
Type: application/octet-stream
Size: 2600 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20210726/6ae9651b/attachment-0003.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcp_new_win_enc_test.pcap
Type: application/octet-stream
Size: 5022 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20210726/6ae9651b/attachment-0004.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcp_azure_old.pcap
Type: application/octet-stream
Size: 8021 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/krb5-bugs/attachments/20210726/6ae9651b/attachment-0005.obj