Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01

Michael Ströder <michael@stroeder.com> Fri, 15 March 2013 22:08 UTC

Return-Path: <michael@stroeder.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D64FF11E80A5 for <ldapext@ietfa.amsl.com>; Fri, 15 Mar 2013 15:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.224
X-Spam-Level:
X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uR63SqHm3yGC for <ldapext@ietfa.amsl.com>; Fri, 15 Mar 2013 15:08:27 -0700 (PDT)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id A841621F896B for <ldapext@ietf.org>; Fri, 15 Mar 2013 15:08:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 5D1C3603D4; Fri, 15 Mar 2013 23:08:24 +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 cneKPtxLaAdE; Fri, 15 Mar 2013 23:08:16 +0100 (CET)
Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by srv1.stroeder.com (Postfix) with ESMTPS id 9F83160327; Fri, 15 Mar 2013 22:08:14 +0000 (UTC)
Message-ID: <51439BCF.3080802@stroeder.com>
Date: Fri, 15 Mar 2013 23:08:15 +0100
From: Michael Ströder <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2
MIME-Version: 1.0
To: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
References: <5103F924.2070800@stroeder.com> <CABBgLkcnK7WfthFOBD5Esfz+g1izcKoGgtxzKKDntc0i=E7LOQ@mail.gmail.com> <510782A6.7050209@stroeder.com> <3ED81CD8-59DA-482E-8AFA-C68E53A62067@isode.com> <51410020.4020800@stroeder.com> <20130315125326.GA22595@slab.skills-1st.co.uk>
In-Reply-To: <20130315125326.GA22595@slab.skills-1st.co.uk>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms070507030405080406050602"
Cc: "ldap@umich.edu" <ldap@umich.edu>, ldapext <ldapext@ietf.org>
Subject: Re: [ldapext] [ldap] Re: draft-stroeder-hashed-userpassword-values-01
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.12
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, 15 Mar 2013 22:08:28 -0000

Andrew Findlay wrote:
> On Wed, Mar 13, 2013 at 11:39:28PM +0100, Michael Ströder wrote:
> 
>> http://www.ietf.org/internet-drafts/draft-stroeder-hashed-userpassword-values-01.txt
> 
> In section 3 Implementation Issues, the 4th paragraph talks
> about checking the syntax of the storage scheme. This
> certainly has to be done, but I am a bit worried by the last
> sentence:
> 
> 	Any value which do not adhere to this syntax MAY be treated as
> 	clear-text password by the DSA when processing a LDAP simple
> 	bind request or LDAP compare request.
> 
> This is probably what most servers actually do, but it does
> mean that any unrecognised schemes or badly-formatted values
> effectively become clear-text passwords. Not a good failure
> mode...

I know that this sounds kinda problematic but what is the actual risk?
The risk depends on how predictable the incorrect value is.

It would be good to know how the various server implementors handle this.

Also see this in the context with the paragraph following the above citation:

   Servers MAY provide local configuration items to limit the set of
   hash schemes to be processed and for completely disabling use of
   clear-text passwords in attribute 'userPassword'.

The "MAY provide" here sounds too weak from a security perspective but using
SHOULD would be too strong. Maybe it could be replaced by a lower-cased
"should consider to provide".

> This is another case where the use of standard-setting words
> like MAY and SHOULD sits uneasily with the informational
> status of the document.

Agreed.

> From a security perspective I would
> prefer something like this:
> 
> 	Any value which does not have correct syntax SHOULD be
> 	treated as a value that can never match any password
> 	asserted by a user.

The condition "does not have correct syntax" cannot be resolved because the
syntax definition starts with:

   userpasswordvalue = cleartext-password / ( prefix hashed-password )

> On the other hand, as a description of current practice it may
> be better to say:
> 
> 	The treatment of values with incorrect syntax is
> 	defined by the server implementation. Administrators
> 	should be aware that servers may treat such values as
> 	clear-text passwords, thus removing the benefit of
> 	hashing entirely. Values using storage schemes not
> 	known to the server may have the same effect.

That's better.
But I'm not sure whether administrator is a usual term in this type of documents.

Ciao, Michael.