NTLM (bleah) is a connection-oriented auth protocol, unlike Basic and Digest auth. That means that once a client has authenticated against a server on a given connection, all further requests on that connection are to be treated as already authenticated. So curl maintains NTLM state for each connection (conn->ntlm and conn->proxyntlm). The flow of messages in NTLM auth is as follows:

>>> GET /some/resource : conn->ntlm->state is NTLMSTATE_NONE)
<<< 401 Auth Required (WWW-Authenticate: NTLM) : conn->ntlm->state set to NTLMSTATE_TYPE1 (need to send a type-1 message)
>>> GET /some/resource (Authorization: NTLM blahblah) : conn->ntlm->state still NTLMSTATE_TYPE1
<<< 401 Auth Required (WWW-Authenticate: NTLM blahblahblah) : conn->ntlm->state set to NTLMSTATE_TYPE2 (type-2 message received)
>>> GET /some/resource (Authorization: NTLM blahblahblahblah) : conn->ntlm->state set to NTLMSTATE_TYPE3 (type-3 message sent)
<<< 200 OK : conn->ntlm->state still NTLMSTATE_TYPE3

If a 401 with an NTLM header is ever received on that connection again, curl will fail the authentication again immediately:

      if(ntlm->state >= NTLMSTATE_TYPE1) {
        infof(conn->data, "NTLM handshake failure (internal error)\n");
        return CURLE_REMOTE_ACCESS_DENIED;
      }

Curl is tracking the connection state and enforcing errors when a server wants to start NTLM authentication unnecessarily. But I think curl is doing too much here: state tracking on that level is the server's job. All curl really cares about is that if an NTLM header is received, it needs to respond and authenticate. The fact that it's already been done for this connection is irrelevant. Keeping track of whether NTLM authentication is required on a connection is done on the server, and if the server messes it up all that will happen is that things become slower as the client is force to reauthenticate needlessly. But right now, both server and client are keeping track of whether authentication is needed, and when the client is more strict than the server, bad things happen:

authenticate as above : conn->ntlm->state still NTLMSTATE_TYPE3
>>> GET /different/resource
<<< 401 Auth Required (WWW-Authenticate: NTLM) - oops, the server's asking for authentication again. We should go back to NTLMSTATE_TYPE1
curl prints "NTLM handshake failure (internal error)" and passes the 401 on to the header and write callbacks

(The NTLM specs are silent on the question of whether a server is ALLOWED to reauthenticate on the same connection or not. They don't even discuss the possibility. But at least one major product - the ISA proxy server - does send new 407 replies on an already-authenticated connection, and when this happens curl gives the above error and the connection becomes unusable - curl will continue to send requests on it, and the proxy will always reply with 407, to which curl prints the above error and does not reply.)

Really the only thing curl needs to do with the "connection-oriented" NTLM is ensure that the 3-step NTLM handshake messages are all sent on the same connection, and ensure that when a request with credentials is assigned to a connection it is never assigned to one that is NTLM-authenticated with different credentials. (And ideally, it should be assigned to one that is NTLM-authenticated with the SAME credentials, for performance.) I don't think curl should be making decisions about whether NTLM authentication on a connection is allowed. The server's idea of state should be considered definitive.

Thoughts?

Joe

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-01-04