Re: [ldapext] DBIS - new IETF drafts

Andrew Findlay <andrew.findlay@skills-1st.co.uk> Fri, 10 January 2014 17:37 UTC

Return-Path: <andrew.findlay@skills-1st.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 32D391ADFA4 for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 09:37:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
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 rR1w36_JbX6n for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 09:37:43 -0800 (PST)
Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) by ietfa.amsl.com (Postfix) with ESMTP id 2044B1ADF30 for <ldapext@ietf.org>; Fri, 10 Jan 2014 09:37:43 -0800 (PST)
Received: from 9.d.e.2.e.6.a.d.5.9.e.0.f.9.4.9.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1:949f:e95:da6e:2ed9] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1W1g1T-0008Cp-PL; Fri, 10 Jan 2014 17:37:31 +0000
Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.80.1) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1W1g1T-0007Ea-9u; Fri, 10 Jan 2014 17:37:31 +0000
Date: Fri, 10 Jan 2014 17:37:31 +0000
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Luke Howard <lukeh@padl.com>
Message-ID: <20140110173731.GA3938@slab.skills-1st.co.uk>
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> <52CFFEAC.7070208@proseconsulting.co.uk> <C6DD84E6-0D5D-4F7A-90DF-46C382D4B06A@padl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <C6DD84E6-0D5D-4F7A-90DF-46C382D4B06A@padl.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Cc: Ldapext <ldapext@ietf.org>, Michael Ströder <michael@stroeder.com>
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 17:37:45 -0000

On Sat, Jan 11, 2014 at 01:15:03AM +1100, Luke Howard wrote:

> > 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.
> 
> Active Directory cannot.

True, but there are many things that Active Directory cannot do.
It is not a general-purpose LDAP server: it is a proprietary
database that happens to support an LDAP access method.

As for CRYPT (at least the traditional 13-character DES version) in
other servers:

	OpenLDAP				yes
	IBM Tivoli Directory Server		yes
	389					yes
	OpenDJ					yes
	Sun/Oracle DSEE				yes
	Oracle OID				yes
	Isode M-Vault				yes
	ApacheDS				yes
	Lotus Domino				very unlikely

The only server that I have not been able to find a clear
statement of CRYPT support for is Lotus Domino - and like AD, that
is really not intended as a general-purpose LDAP server.

Of course these days we are not just talking about 13-character
CRYPT in migration jobs. Any decent Unix-like system released in the
past decade or two is likely to use a stronger hash algorithm in
/etc/shadow. Support for those is much more restricted, and normally
depends on the underlying OS to supply the hashing code. Some of the
enterprise distros have only gained support for my preferred hash
algorithms in the past couple of years, so running LDAP servers on
older enterprise OSs can be rather limiting.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------