Re: [ldapext] DBIS - new IETF drafts

[Mark R Bannister <[e-mail]>]

On 09/01/2014 15:22, Michael Ströder wrote:
> 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.

As long as we have a solution to make migration to DBIS straightforward 
and without forcing everybody to change their passwords and without 
forcing legacy NIS clients to require upgrading, then I'm with you.

>
>> 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.

Can all LDAP servers on the market today use a CRYPT-style password to 
serve a bind request?  If so, it's easy to mandate this.  If not, it 
won't be mandatory.

>
>> 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.

This is where we differ a lot.  You would throw away the past to build 
the future (ironically something that Howard seems to be accusing me 
of).  I, on the other hand, am all about building bridges between the 
past and the future so that we don't cut anybody out.  Everyone should 
be able to make use of DBIS, right now, without pain.  Flick a switch, 
you're on DBIS, then slowly make improvements once you're on a better 
framework.  That's the philosophy, and I'll happily battle hard and feel 
lots of pain now convincing everybody that you can't ignore the past, if 
it means users of DBIS in the future don't have to feel any pain.

Best regards,
Mark.