Re: [ldapext] DBIS - new IETF drafts

Mark R Bannister <dbis@proseconsulting.co.uk> Fri, 10 January 2014 14:37 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 8AC5C1AE01E for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 06:37:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 W7HMn6Fs-1k7 for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 06:37:21 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0D1A71AD68A for <ldapext@ietf.org>; Fri, 10 Jan 2014 06:37:21 -0800 (PST)
Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail6.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1W1dCw-0001Z2-LF; Fri, 10 Jan 2014 14:37:10 +0000
Message-ID: <52D0057D.2030501@proseconsulting.co.uk>
Date: Fri, 10 Jan 2014 14:36:45 +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: Luke Howard <lukeh@padl.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> <52CFFEAC.7070208@proseconsulting.co.uk> <C6DD84E6-0D5D-4F7A-90DF-46C382D4B06A@padl.com>
In-Reply-To: <C6DD84E6-0D5D-4F7A-90DF-46C382D4B06A@padl.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
Cc: Ldapext <ldapext@ietf.org>, Andrew Findlay <andrew.findlay@skills-1st.co.uk>, =?ISO-8859-1?Q?Mich?= =?ISO-8859-1?Q?ael_Str=F6der?= <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 14:37:22 -0000

On 10/01/2014 14:15, Luke Howard wrote:
>>> 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.
> Active Directory cannot.
>
> -- Luke

Thanks Luke.  Everywhere I have seen UNIX accounts deployed on AD, 
Kerberos password authentication has been used, so in those places it 
would not be an issue.  However, I cannot possibly know how many people 
out there rely on CRYPT hashes in AD attributes, and I'm not about to 
cut off the possibly of them migrating to DBIS.  CRYPT will therefore 
have to remain as an option, although I'm perfectly happy to put 
stronger wording around it.  So far I have written:

    While a DUA MAY implement any authentication password scheme
    supported by the DSA, it MUST support the CRYPT scheme for backwards
    compatibility, which is an implementation of the traditional UNIX
    crypt algorithm.  However, it is RECOMMENDED that a more secure
    scheme is used.

and ...

    Passwd and group database entries contain encrypted passwords and
    SHOULD be transmitted securely when transferred between DSA and DUA
    to prevent eavesdropping.  A DUA SHOULD NOT allow a user to see any
    encrypted passwords except they MAY see the password on their own
    posixUserAccount entry in encrypted form.

Open to suggestions on how to reword this.

Best regards,
Mark.