[Dovecot] Concerned about Dovecot's new NTLM code

[Andrey Panin]

> On Mon, 2004-09-27 at 16:44, Andrey Panin wrote:
>> >
>> > 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 ? :)

Never encountered a single one outside of LAN's. Anyway correct unicode
support is impossible to implement without enormous amount of breakage.

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

Domain membership was not a goal, at least until you started this thread.

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

Long time passed after I used samba last time...
Do you mean that samba authentication database can contain not only user,
but also workstation and other "god knows what" accounts ?
IMHO it's a matter of right SQL/LDAP request.

> 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).

Yes, I heard about domain infrastructure advantages, but not all use it as
it's far too complex for many tasks.

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

NTLMv2 ?
On other hand I can't see a way to use non-NTLM (CRAM-MD5,APOP etc)
authentication methods with ntlm_auth. Looks like they can't work together
and IMHO it's not an interoperability improvement.

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

Yes, my primary concern is standalone mail servers. It's what I'm payd for
after all :)