[jcifs] NTLMv2 and the HTTP Authentication Filter's Future (or lack thereof)

[Michael B Allen]

Russ,

Please send all JCIFS questions to the JCIFS mailing list. I have
redirected (and mostly anonymized) your message.

First some background:

JCIFS is a client implementation of the CIFS and DCERPC protocols. The
JCIFS NTLM HTTP Authentication Filter is a little side project that we
bundled with JCIFS for user convenience. I could be wrong about this
but my impression has been that some people think JCIFS *is* the HTTP
Filter. That is not so. I personally have not used or even tested the
HTTP Filter in many years. This is why there are numerous patches for
it that have never been applied as I do not dare make modifications to
it.

Now regarding your question about the HTTP Filter not supporting NTLMv2:

The JCIFS NTLM HTTP Authentication Filter uses a "man in the middle"
technique whereby the web server simply marshals the NTLM
challenge-response tokens between the browser and an SMB server.
Specifically, when the browser triggers the Filter, JCIFS connects to
an SMB server (the "domain controller") and returns the "server
challenge" for that SMB connection to the browser. The browser
computes NTLM password hashes using the DC's challenge and the user's
password and sends them to the Filter which just forwards them to the
SMB server as if it were authenticating itself. Meaning, the browser
thinks it's authenticating with the web server when it's really
authenticating directly with the DC.

This "man in the middle" technique works fine with NTLMv1 however it
cannot work with NTLMv2. The NTLMv2 challenge also consists of "target
information" that includes the hostname of the target (among other
things). That target information is factored into the calculations of
the password hashes. So the problem is that target information for the
web server is different from the target information for the domain
controller and therefore the password hash computation will be wrong
as the browser will expect target information for the web server and
not the domain controller. This is done specifically to thwart "man in
the middle" scenarios. And thus the technique used by the JCIFS NTLM
HTTP Filter cannot be used with NTLMv2.

Finally, the JCIFS NTLM HTTP Authentication Filter is a hack. It is a
hack that has worked quite well and to our knowledge is secure but it
is not a correct implementation of an NTLM authentication acceptor. A
proper implementation would do as IIS would do which in the case of
NTLM would be to use the DCERPC NETLOGON service. Specifically, the
web server would generate it's own random challenge with the proper
target information, send that to the browser, collect the password
hashes and then call the NetrSamLogon RPC with the challenge that we
generated and the corresponding password hashes. Or, according to the
Heimdal project, it is also possible to use a form of Kerberos digest
authentication to validate this information.

Note that when Kebreros is added in JCIFS 2.0 (currently on-hold
indefinitely due to recent financing issues) the HTTP NTLM Filter will
be removed. This is mostly because the Filter is not related to CIFS
or DCERPC but it is also because the "man in the middle" technique is
unstable (see "hiccup bug").

If someone were to start a "proper" HTTP SSO authentication Filter
project, we will try to expose the necessary protocol support for NTLM
and the NETLOGON service (although we currently do not have
NetrSamLogon and there are currently no plans for it).

The JCIFS project is currently not interested in supporting an HTTP
Authentication Filter as that is not related to CIFS or DCERPC (and
CIFS and DCERPC is what our sponsors are using).

Mike

On Sun, 26 Oct 2008 11:22:22 -0700
Russ wrote:

> Michael:
>
> In your announcement you say NTLMv2 is now supported... Yet at the bottom you say HTTP filter can't support it...
>
> I'm confused here. Can you explain the 'setup' to me?
>
> --Russ