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

[Michael B Allen]

On Wed, 9 Apr 2008 22:50:51 +0200
"Giampaolo Tomassoni" <Giampaolo at Tomassoni.biz> wrote:

> > -----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,

I'm not going to change anything in our filter. In fact, I would love
to get rid of it. It really has no place in JCIFS and never did. It was
just so popular it was hard to deny people.

Please, please, pretty please start you own NTLM Filter project.

Or better still, create an SPNEGO w/ Kerberos + NTLM filter.

Mike

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