[jcifs] jCifs' NTLMSSP: is it secure and sound?

[Giampaolo Tomassoni]

> -----Original Message-----
> From: jcifs-bounces+giampaolo=tomassoni.biz at lists.samba.org
> [mailto:jcifs-bounces+giampaolo=tomassoni.biz at lists.samba.org] On
> Behalf Of Michael B Allen
> 
> On Wed, 9 Apr 2008 11:00:24 +0200
> "Giampaolo Tomassoni" <Giampaolo at Tomassoni.biz> wrote:
> 
> > > Subject: Re: [jcifs] jCifs' NTLMSSP: is it secure and sound?
> > >
> > > On Wed, 9 Apr 2008 01:30:07 +0200
> > > "Giampaolo Tomassoni" <Giampaolo at Tomassoni.biz> wrote:
> > >
> > > > What are your thoughts about this?
> > >
> > > If NTLM does not provide the level of security you require then I
> > > recommend that you use Kerberos instead.
> > >
> > > Mike
> >
> > Well, I probably wasn't clean enough. It is not that I don't like
> NTLMSSP.
> > It is that the jCifs' implementation of NTLMSSP (NtlmHttpFilter  and
> > relatives) is not correct and thereby is more easily spoofed.
> 
> First, this has nothing to do with NTLMSSP or how it's
> implemented. NTLMSSP is just a messaging protocol.

See par. 1.3.1.1 "NTLM Connection-oriented Call Flow" point 4 of "MS-NLMP NT
LAN Manager (NTLM) Authentication Protocol Specification
(http://msdn2.microsoft.com/en-us/library/cc207842.aspx):

"If the challenge and the response prove that the client knows the user's
password, the authentication succeeds and the application protocol continues
according to its specification..."

Since HTTP/1.1 supports Persistent Connections, the protocol boundary is not
around a single message, but instead spans the whole connection lifetime.


> The problem of spoofing by session id is common to any application
> that bypasses subsequent authentications by caching the authentication
> in the session.

That's why most intranet/extranet applications would prefer something like
Digest and NTLMSSP instead of the Form-based authentication: the first are
meant to be more resistant to spoofing then the latter. NTLMSSP has *also*
the advantage of SSO support, but it is not meant to be a trade-off with
security.


> The solution to the session id spoofing issue is to simply not cache
> the authentication in the session. You could probably comment out one
> line somewhere in the filter to stop it from putting anything in the
> session. Technically I believe that is how things are supposed to work
> (I would have to get a capture of IIS to confirm that).

No, Mike, things are not that way when connection are "persistent" according
to HTTP/1.1: the message next to the authenticating one (the second) carries
no authentication data, thereby NtlmHttpFilter would attempt authenticating
that message too. Unfortunately, this results in IE7 (at least) to believe
something went wrong with the just completed authentication process and
issue a new login dialog. This dialog is prompted even if the first login
was through SSO support and it is prompted to every and each request...

Besides, I don't dislike the fact that a persistent connection needs to be
authenticated only once: it increases performance with no side-effect on
security.


> We chose to
> cache the authentication at the expense of speed.

And security, Mike. This implementation of NTLMSSP is more secure than a
form-based authentication over a clear channel, but weaker than a Digest
authentication. I'm pretty sure IIS and competitors avoid relying on session
data, probably to avoid any weakness.


> But still, if you really care that much about security then you should
> be using Kerberos. Kerberos does not require communication with a
> central authority so authenticating each request can more efficient.

If I was that much concerned about security, I would have used SSL with
client certificates instead.

It is not a matter of which is the most secure method and which is not. The
matter is that the jCif's NTLMSSP implementation is weaker than others,
while I believe it shouldn't be.

I'm not meaning that there is no solution to this: due to some requirements
for a site I am developing, I had to develop my own version of the
NtlmHttpFilter, which is how I discovered this problem. I "fixed" it by not
relying on session data, but to forward the authentication data to the
application, and tracking the connection in the filter. It is suboptimal,
but it works. I can spare sources, if anyone likes, but please note this
filter is quite different from the jCifs' actual one and its parameters are
incompatible because of the above-mentioned requirements.

By the way, I forwarded the auth data to the app through session data in
order to maintain compatibility with the jCif's implementation, but this is
not required and, perhaps, even not strictly correct: wrapping
NtlmHttpServletRequest around the original request would be enough.

Giampaolo


> Mike
> 
> --
> Michael B Allen
> PHP Active Directory SPNEGO SSO
> http://www.ioplex.com/