Re: [ldapext] DBIS - new IETF drafts

Michael Ströder <michael@stroeder.com> Thu, 09 January 2014 15:56 UTC

Return-Path: <michael@stroeder.com>
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 4D4DD1ACCE2 for <ldapext@ietfa.amsl.com>; Thu, 9 Jan 2014 07:56:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.839
X-Spam-Level:
X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 0DshUVyrdlVH for <ldapext@ietfa.amsl.com>; Thu, 9 Jan 2014 07:55:59 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 5578D1AD627 for <ldapext@ietf.org>; Thu, 9 Jan 2014 07:55:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 39D4760775; Thu, 9 Jan 2014 16:55:49 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU6vf5DUeo2J; Thu, 9 Jan 2014 16:55:39 +0100 (CET)
Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Str??der", Issuer "CA Cert Signing Authority" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 8154A60771; Thu, 9 Jan 2014 15:55:38 +0000 (UTC)
Message-ID: <52CEBEAE.5090701@stroeder.com>
Date: Thu, 09 Jan 2014 16:22:22 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
MIME-Version: 1.0
To: Mark R Bannister <dbis@proseconsulting.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>
In-Reply-To: <52CDB6B2.2080406@proseconsulting.co.uk>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040606010106030702000706"
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: Thu, 09 Jan 2014 15:56:01 -0000

Mark R Bannister wrote:
>> Exposing hashes should be a last resort for compatibility reasons only
>> and should be disabled by default with appropriate ACIs.

The problem with exposing a central {CRYPT} hash is that a central and single
password will be compromised even though newer systems might be capable of
using stronger authc mechs. Especially if you want to support old systems you
likely won't be able to use a stronger {CRYPT} hashing scheme.

=> I'd avoid that mess completely and I won't support any schema encouraging
this. At least your drafts should contain big ALARM notes in the security
considerations section.

> I don't suggest DBIS makes any mention of ACIs.  That's up to local rules &
> procedures, not something that could possibly be standardised.

>> My point of view is that using LDAP binds SHOULD be mandated for
>> authentication for any new client following any new schema, and exposing
>> hashes MUST be disabled by default, and explicitly enabled by admins
>> that needs backwards compatibility. We need to move up the security bar,
>> and you do that only with appropriate defaults, and new IETF work should
>> reflect that IMHO.
>>
>> Simo.

+1 to Simo's comment.

> I don't think LDAP binds can be mandated, we can only strongly recommend it. 
> Given the migration path I have already described, I find it highly unlikely
> that people will be able to move to LDAP binds and move off CRYPT immediately,

If your customers have old legacy systems which they won't change at all then
simply let them run them in a isolated environment with all the old cruft
around they need for those systems. Sooner or later they have to migrate
anyway because systems are running out-of-service (e.g. will not receive
security updates anymore).

IMO any new standard should focus on getting the near future right.

Ciao, Michael.