-
-
Notifications
You must be signed in to change notification settings - Fork 6.7k
In non-sspi builds, NTLM cannot identify against saslauthd (cyrus-sasl) #6813
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Some other client libraries behavior:
Possible fixes in curl
In all cases, if A local build with fix 2 applied has been tested against saslauthd successfully. Whatever fix is adopted, the test suite would have to be adapted accordingly. Real tests against a M$ server are also mandatory. Questions:
|
Aren't there NTLM libraries out there that do this correctly that curl can
leverage? It's always seemed suspect to me that we roll our own implementation
of this.
|
Yes, there are. But I don't know if they were available at the time NTLM was introduced in curl. |
I like option 2. It's not only more secure, but also the smaller change in behavior. |
According to Microsoft document MS-NLMP, current flags usage is not accurate: flag NTLMFLAG_NEGOTIATE_NTLM2_KEY controls the use of extended security in an NTLM authentication message and NTLM version 2 cannot be negotiated within the protocol. The solution implemented here is: if the extended security flag is set, prefer using NTLM version 2 (as a server featuring extended security should also support version 2). If version 2 has been disabled at compile time, use extended security. Tests involving NTLM are adjusted to this new behavior. Fixes curl#6813
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:
NTLMFLAG_NEGOTIATE_NTLM2_KEY
as a request to use NTLMv2 andNTLMFLAG_NEGOTIATE_NTLM_KEY
to use NTLMv1 with extended security.NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
andNTLMSSP_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 ofNTLMFLAG_NEGOTIATE_NTLM_KEY
is not clear (probably can be cleared to downgrade the authentication to LM-only).NTLMFLAG_NEGOTIATE_NTLM_KEY
andNTLMFLAG_NEGOTIATE_NTLM2_KEY
. But saslauthd does not support extended security and thus properly clears flagNTLMFLAG_NEGOTIATE_NTLM2_KEY
in challenge message (type2). AsNTLMFLAG_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.
The text was updated successfully, but these errors were encountered: