Re: authmeth: passwords in the clear

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga writes:
>At 08:53 AM 2/28/2004, Hallvard B Furuseth wrote:
>>authmeth-10 says:
>>
>>> 11. General Requirements for Password-based Authentication
>>> (...)
>>>   To mitigate the security risks associated with the use of passwords, 
>>>   a server implementation MUST implement a configuration that at the 
>>>   time of authentication or password modification, requires: 
> (...)
>>
>>This should only apply to cleartext passwords, not e.g. modifications of
>>attributes that contain encrypted passwords.
> 
> I concur that this particular section should be limited to
> cleartext passwords used in authentication.  

I didn't say that (that it should only be about authentication).  I
agree that a "MUST" is too strong for other operations than
authentication.  However, it really is the same issue - protecting
passwords - for other operations.  I suggest a paragraph at the end of
this section that it is RECOMMENDED that the configuration in question
treats other operations that contain cleartext passwords, such as
passwords modifications, the same way.  Or if not:

> I think other "uses" of cleartext passwords (such as modification)
> should be address in documents detail specific mechanisms (e.g.,
> LDAP Password Modify Operation) and/or password schema.

Then most password-related operations and password attributes will end
up with different ways to treat passwords vs. protection mechanisms, and
the server may have to implement them all.  Whatever we do, I'd prefer a
single section in [Authmeth] or [Protocol] which suggests how to deal
with passwords in non-bind operations.  Then the Password Modify
Operation, the userPassword definition and so on could refer to that if
they wish.

> (And,
> aside from some very general guidance, issues associated with
> gateways, caching proxies, chaining servers, and/or replicas
> should be addressed in documents discussing such these things.)

Yes.  Maybe such general guidance should be included in the section
about passwords in non-bind LDAP operations.

-- 
Hallvard