Re: [ldapext] DBIS - new IETF drafts

Mark R Bannister <dbis@proseconsulting.co.uk> Fri, 10 January 2014 14:13 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 882551AE086 for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 06:13:50 -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 QegeNiV5zCgQ for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 06:13:49 -0800 (PST)
Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8AD1AE057 for <ldapext@ietf.org>; Fri, 10 Jan 2014 06:13:49 -0800 (PST)
Received: from host109-155-253-4.range109-155.btcentralplus.com ([109.155.253.4] helo=[192.168.1.68]) by mail11.atlas.pipex.net with esmtpa (Exim 4.71) (envelope-from <dbis@proseconsulting.co.uk>) id 1W1cqA-0003zV-Qm; Fri, 10 Jan 2014 14:13:39 +0000
Message-ID: <52CFFFFB.8060105@proseconsulting.co.uk>
Date: Fri, 10 Jan 2014 14:13:15 +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: Simo <s@ssimo.org>, =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= <michael@stroeder.com>
References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> <1389290636.27654.125.camel@pico.ipa.ssimo.org>
In-Reply-To: <1389290636.27654.125.camel@pico.ipa.ssimo.org>
Content-Type: text/plain; charset=UTF-8; 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:13:50 -0000

On 09/01/2014 18:03, Simo wrote:
> On Thu, 2014-01-09 at 16:48 +0100, Michael Ströder wrote:
>> Mark R Bannister wrote:
>>> Yes as you'll see from my recent reply to Simo, the case sensitivity issue was
>>> one of the problems I faced at a large installation,
>> This could be easily solved with RFC2307bis. Or not?
>>
>> In my deployments I simply define additional (OpenLDAP) constraints for those
>> attributes (e.g. to enforce lower-case 'uid' values).
>>
>> IMHO only re-defining the matching rules does not fully solve the case problem
>> anyway. Restricting to lower-case attribute values helps better.
>
> I'd go beyond this, supporting case-sensitive user names is actively
> harmful for various reasons.

UNIX is traditionally case sensitive.  I am currently working at a large 
installation where there is an important distinction between lower-case 
and upper-case user names.  This debate isn't just about user names 
anyway.  There are loads of NIS fields that were case sensitive, and 
UNIX isn't going to change.  They will always be case sensitive.  So 
trying to represent them in case insensitive fields is just, well, wrong.

> - Assuming users (and admins) should be able to distinguish based on
> case is wrong, we naturally consider the strings 'Admin' and 'admin' to
> be the same thing.

If you're used to Microsoft Windows, yes.  DBIS is not aimed at Microsoft.

> - Some systems are case-preserving (meaning they'll show you back the
> same case you entered, but are really case-insensitive and if you have
> to interoperate with them you cannot assume Admin and amdin to be
> different users, it could lead to serious security issues.
>
> - If we are in the legacy game, there are still systems that will simply
> accept only all caps names, like ADMIN. In these cases what do you map
> that to ? Admin ? admin? a third user called ADMIN ?
>
> And there are many other examples where really being case sensitive
> causes a lot more problem than it resolves.
> Due to these problems what we did in FreeIPA is to always create users
> in lower case and explicitly state we are case-preserving and
> insensitive. It is the only reasonable compromise IMHO.

NIS, RFC2307, RFC2307bis and DBIS are for UNIX.  UNIX is case 
sensitive.  It makes no sense to store data in a case insensitive 
fashion if the client expects it to be case sensitive.  Data loss or 
corruption will occur this way.

Best regards,
Mark.