Re: [ldapext] DBIS - new IETF drafts

Mark R Bannister <dbis@proseconsulting.co.uk> Fri, 10 January 2014 14:08 UTC

Return-Path: <dbis@proseconsulting.co.uk>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26861AE078 for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 06:08:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4YL3Q7_rHmNV for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 06:08:14 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD221AE068 for <ldapext@ietf.org>; Fri, 10 Jan 2014 06:08:14 -0800 (PST)
Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail5.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1W1ckm-00051O-8o; Fri, 10 Jan 2014 14:08:04 +0000
Message-ID: <52CFFEAC.7070208@proseconsulting.co.uk>
Date: Fri, 10 Jan 2014 14:07:40 +0000
From: Mark R Bannister <dbis@proseconsulting.co.uk>
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 <andrew.findlay@skills-1st.co.uk>, =?ISO-8859-1?Q?Mich?= =?ISO-8859-1?Q?ael_Str=F6der?= <michael@stroeder.com>
References: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <1389050240.27654.67.camel@pico.ipa.ssimo.org> <52CDB6B2.2080406@proseconsulting.co.uk> <52CEBEAE.5090701@stroeder.com> <20140109174321.GV3938@slab.skills-1st.co.uk>
In-Reply-To: <20140109174321.GV3938@slab.skills-1st.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Cc: ldapext@ietf.org
Subject: Re: [ldapext] DBIS - new IETF drafts
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=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,
Mark.