Re: DBIS - new IETF drafts

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.

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext