Re: [ldapext] DBIS - new IETF drafts

Mark R Bannister <> Fri, 10 January 2014 14:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B26861AE078 for <>; Fri, 10 Jan 2014 06:08:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Status: No, score=-1.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4YL3Q7_rHmNV for <>; Fri, 10 Jan 2014 06:08:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 8CD221AE068 for <>; Fri, 10 Jan 2014 06:08:14 -0800 (PST)
Received: from ([] helo=[]) by with esmtpa (Exim 4.71) (envelope-from <>) id 1W1ckm-00051O-8o; Fri, 10 Jan 2014 14:08:04 +0000
Message-ID: <>
Date: Fri, 10 Jan 2014 14:07:40 +0000
From: Mark R Bannister <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Andrew Findlay <>, =?ISO-8859-1?Q?Mich?= =?ISO-8859-1?Q?ael_Str=F6der?= <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Subject: Re: [ldapext] DBIS - new IETF drafts
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 10 Jan 2014 14:08:15 -0000

On 09/01/2014 17:43, Andrew Findlay wrote:
> On Thu, Jan 09, 2014 at 04:22:22PM +0100, Michael Ströder wrote:
>> Mark R Bannister wrote:
>>>> Exposing hashes should be a last resort for compatibility reasons only
>>>> and should be disabled by default with appropriate ACIs.
> Absolutely. You need the LDAP server to support the old-style hashes
> to allow for migrating data in, but exposing *any* form of hash
> outside your trusted LDAP servers is asking for trouble.
> Every LDAP-aware client system that I have worked with can use the
> bind operation as a means to validate passwords, so the only
> possible excuse for exporting hashes is temporary support of
> migrating systems. If you only allow the export of hashes that are
> actually needed by the old non-LDAP systems then at least you are
> not making matters worse than they were before the migration.

Ok, so I posed this question just now, but can all LDAP servers you can 
think of authentication bind operations using CRYPT-style passwords?  If 
it can be done server-side there'll be no problem here and we need never 
expose the hashes to clients.

> <snip>
>> IMO any new standard should focus on getting the near future right.
> Yes, but that does have to include migrating stuff that is currently
> stuck in the technological past!

Thanks Andrew, I think this point can't be emphasised enough.  We must 
always be aware of how customers are going to be expected to get from A 
to B.  That journey needs to be as simple as possible. If that means 
supporting extra legacy stuff to smooth the transition, than so be it.

Best regards,