Current curl NTLM implementation is based on https://curl.se/rfc/ntlm.html: this document seems to be an outstanding work of reverse engineering and/or information compilation done at a time when NTLM was a proprietary protocol and no specification were published.

Since then, M$ released the specification: https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/

Comparing both documents, there seems to be some misunderstanding in the first one, one of them explaining why curl is not able to authenticate against saslauthd using NTLM:

Trying to be short:

• there are 3 ways to provide authentication information, NTLMv1, NTLMv1 with extended security and NTLMv2.
• curl understand negotiated flags NTLMFLAG_NEGOTIATE_NTLM2_KEY as a request to use NTLMv2 and NTLMFLAG_NEGOTIATE_NTLM_KEY to use NTLMv1 with extended security.
• according to the MS-NLMP document (that names these flags NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY and NTLMSSP_NEGOTIATE_NTLM respectively), this is a misuse: there is no possible negotiation of NTLMv2 in the protocol (client should have an external way of selecting it or not). If NTLMv2 is not used, NTLMFLAG_NEGOTIATE_NTLM2_KEY tells to use NTLMv1 extended security, while the meaning of NTLMFLAG_NEGOTIATE_NTLM_KEY is not clear (probably can be cleared to downgrade the authentication to LM-only).
• curl negotiates the full capabilities (according to its protocol understanding and conditional compilation statements), that is: NTLMFLAG_NEGOTIATE_NTLM_KEY and NTLMFLAG_NEGOTIATE_NTLM2_KEY. But saslauthd does not support extended security and thus properly clears flag NTLMFLAG_NEGOTIATE_NTLM2_KEY in challenge message (type2). As NTLMFLAG_NEGOTIATE_NTLM_KEY is still set, curl uses NTLMv1 with extended security for authentication, which is wrong according to MS-NLMP.

Note that, although NTLMv2 is not negotiated, a server receiving an authentication (type3) message can determine it from the NTLM authentication data length. A client however, has no way to know if a server supports NTLMv2 or not.

Although MS-NLMP does not specifiy any meaning of NTLMFLAG_NEGOTIATE_NTLM2_KEY when using NTLMv2, it sets it in negotiation of all NTLMv2 examples.

This does not affect builds with ntlm-sspi.