[Dovecot] Concerned about Dovecot's new NTLM code

[Andrew Bartlett]

On Mon, 2004-09-27 at 16:44, Andrey Panin wrote:
> > I'm pleased to see another project increasing compatibility with windows
> > clients, by the addition of NTLM login support, but I'm a bit worried
> > about a few implementation details, and hope to offer an alternate
> > approach.
> >
> > I mean no disrespect to those who have implemented to the code so far,
> > but I feel that the idea of 'everybody re-implement NTLM' is prone to
> > failure.
> >
> > Firstly, to bugs I've noticed by casual inspection of your
> > implementation:
> >
> >  - Unicode support is by 'null padding' - there is no real support for
> > non-ascii characters.
> 
> Does it really matter ? Do you know many people who use non-ascii
> characters in their email addresses and passwords ? :)

A lot, actually.  There are serious issues with even simple ASCII/CP850
interactions as it applies to usernames, domains and passwords - that is
why Unicode is standard and expected in NTLMSSP.  Perhaps more
importantly, on the Samba team we have found that matching Microsoft in
the move from ASCII to Unicode solved bugs, and avoided untested
codepaths on the Microsoft client.

> >  - NTLM2 (a negotiated scheme to avoid sending the LM response) is
> > unsupported
> 
> Did you RTFS ? Or may be I missed something ?

I did.  This is not NTLMv2, and yes, the naming is confusing.  While
NTLMv2 is configured, the NTLM2 case is negotiated.

NTLM2 replaces the LM response with a client-supplied challenge, to
avoid server-side known plaintext attacks.
http://davenport.sourceforge.net/ntlm.html#theNtlm2SessionResponse

> >  - NTLMSSP is NDR, not 'C struct pushed to the wire', it needs to be
> > correctly marshaled and unmarshaled.
> 
> Yes, it's not a C struct, so what ? Where is the actual bug ?

In my reading of the code, it appeared not to cope with the multiple
forms that NTLMSSP can take, and in particular the Dovecot code seemed
to perform some of the conversions by cast.

I'm just a bit worried about some of the parsing code, given the issues
that we (the Samba Team) have had in the past.  I'm also hoping that
this particular nasty can of worms can be kept in one place, where we
can implement all the protocol twists and turns, as we come across them.

> > There are other missing features, some of which are rumoured to become
> > mandatory flags in future, but more importantly, because the
> > implementation is standalone, it has no ability to integrate into an
> > NT/Win2k/Samba domain.
> 
> It can be directly integrated with password backends using NTLM password
> scheme.

I've looked over the source, and I'm having trouble seeing how you are
using the Samba passwords (as I can't find a use of the Samba password
attributes).  The userPassword attribute doesn't exactly count, as Samba
never reads nor writes that value directly...

Even if the code was to change to read these attributes, there are two
very difficult problems with this.  Firstly, I strongly advise against
directly relying on the format of the Samba password database - we can
and do change that format, as we have done between Samba 2.2 and Samba
3.0, and that presumes LDAP...

This also assumes that the the mail server is privileged to have access
to the password-equivalent values in the database, and makes it
completely incompatible with a role as a domain member.

(Domain membership allows the IMAP server to be separate from the DC, no
matter what it may be running.  This allows mail servers to run in a
windows or Samba domain, without change to the infrastructure).

This is why I've been working with projects to see how we can best
provide Samba's domain membership services beyond just PAM and
nss_winbind.

> > As part of the Samba team, I have worked with other projects - Squid in
> > particular, to deliver server-side (and client-side) NTLMSSP
> > authentication, without the need to re-implement the NTLMSSP protocol.
> >
> > This is done by a callout to 'ntlm_auth', a Samba 3.0 utility designed
> > for this purpose, which in turn can contact domain controllers, allowing
> > for seamless single sign on.
> >
> > http://samba.org/samba/docs/man/ntlm_auth.1.html
> 
> So you'll need Samba to run POP3/IMAP server. Doesn't look convinent to me.
> Many people have no windows domain infrastructure, but want to provide
> secure authentication for poor MS Outlook users.

Unfortunately, without support for NTLM2 at least, the client will send
the LM response, which is a particularly weak.

Perhaps we have different aims - but I had hoped that there was some
interest in the corporate mail server space, where proper domain
integration is critical, and single-sign on (which is what NTLMSSP
provides) is expected.

I have enjoyed using Dovecot on my own networks, backed against PAM for
authentication.  I'm still trying to see how Dovecot's own password
database fits into all this however (and why we ended up with one
password database per application.. :-)

I'm quite willing to work with developers of independent software
packages to see how Samba can be of most assistance.  If the issue of 'I
need my own password db' is the real sticking point, I'm quite willing
to add a callback in ntlm_auth, to fit into such a scheme (I did not
propose this intiailly, as otherwise this function is present and
working in every Samba 3.0 version).

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                                 abartlet at samba.org
Authentication Developer, Samba Team            http://samba.org
Student Network Administrator, Hawker College   abartlet at hawkerc.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://dovecot.org/pipermail/dovecot/attachments/20040927/0baefe9c/attachment-0001.bin>