fre 2006-04-14 klockan 17:07 +0800 skrev Adrian Chadd: > Was anything ever written to define/clarify the semantics of connection > pinning (at least for NTLM authentication) ? I couldn't find anything > with a quick browse with google defining the behaviour (so I could > see how the error condition should be handled.) > > Let me know when you have something and I'll test it out.
It's vaguely defined by the Kerberos/Negotiate I-D by Microsoft, the rest has to be deduced from NTLM authentication and HTTP specifications on persistent connections.. What the I-D says (draft-jaganathan-kerberos-http-01.txt): If an HTTP proxy is used between the client and server, it must take care to not share authenticated connections between different authenticated clients to the same server. If this is not honored, then the server can easily lose track of security context associations. A proxy that correctly honors client to server authentication integrity will supply the "Proxy-support: Session- Based-Authentication" HTTP header to the client in HTTP responses from the proxy. The client MUST NOT utilize the SPNEGO HTTP authentication mechanism through a proxy unless the proxy supplies this header with the "401 Unauthorized" response from the server. My comments: Connection pinning is to support end-to-end connection relations as required by NTLM and Negotiate. Once the connections are pinned they enter a very close relation. The prime requirement is that requests must not be sent on another server connection, and other client requests must not be sent on this server connection. This due to the Microsoft design bug that NTLM/Negotiate authentication being tied to the TCP connection, not the request as such.. If the server connection is gone we have little choice but to close the client connection as well. This due to the client considering that connection already authenticated and sending a new authentication challenge on the same client connection would be considered by the client as "access denied for this user, ask the user if he has another login which might be granted access to the requested object". On persistent connection error conditions such as when the server closes the connection while we attempt to forward the next request it's best to do the same on the client to make things behave more like when no proxy is being used. Technically the HTTP specs says we should send an error message if acting as a proxy and not being able to forward the request for some reason (which this could count as), but the tricky part is that it can not really be expected clients know what to do with that error so I prefer to see pinned connections as more like tunnels via the proxy even if we still do full protocol parsing and even caching of public content. Regards Henrik
signature.asc
Description: Detta är en digitalt signerad meddelandedel
