Draft: Additional Security Considerations for Use of LDAP Directories

[Rici Lake <rici@ricilake.net>]

Since I'm currently being paid to do work on security systems, I would 
hate for it to be thought that I don't take security seriously. I 
prepared the following over lunch; if the WG feels that it might be 
useful in some LDAP document, edited or otherwise, feel free to use it. 
(A few phrases were cribbed from RFC-2616, but most of the words are 
mine.)

Additional Security Considerations for Use of LDAP Directories

LDAP is a protocol for interchange of information between Directories 
and Directory Applications, including Directory clients. Like any 
generic data transfer protocol, it cannot and does not pretend to 
regulate the content of the data that is transferred. However, the 
following guidelines are provided for application developers, directory 
providers, and users of directory services.

Information stored in Directories is often used for authentication, 
authorisation and validation of principals and resources. In 
particular, attribute values in the Directory may be used as 
identification strings in other applications. Care must be taken to 
ensure interoperability of the Directory with such applications.

It is rare that an identifier string is simply an uninterpreted 
sequence of octets. Most applications impose syntactic limitations on 
identifier strings, provide canonical equivalence of different octet 
sequences, and in many cases reinterpret the identifier string as a 
more complex structure of individual components, each of which may have 
their own syntax and equivalence rules. Significant security problems 
can arise from the use of naive string comparison of such identifiers.

In particular, identifier strings SHOULD be stored in the Directory 
with Syntaxes and Matching Rules which precisely correspond to the 
Syntax and Matching Rules used by the other application(s) which use 
the same identifier strings. Failure to do so may result in incorrect 
authentication or authorisation decisions. For example, a resource with 
a case-insensitive name cannot be protected by an authorisation rule 
based on case-sensitive pattern matching. Similarly, case-insensitive 
matching of case-sensitive principal identities may result in a 
principal being granted access to a resource belong to a different 
principal.

Consideration should be given to representing identifier strings which 
are representations of complex abstract syntaxes in a form which more 
precisely captures the nature of the string. DistinguishedName syntax 
can be used, for example, in the same way that DNS names are 
represented as a sequence of dc attribute assertions. This may allow 
for customising syntax and matching rules of individual components of 
an identifier string.

Some information stored in Directories may be used for visual 
validation by human readers. Directory clients displaying such 
information SHOULD follow the guidelines provided in [UTR 36 Security 
Considerations for the Implementation of Unicode and Related 
Technology], particularly the section on visual spoofing. Common visual 
spoofing techniques such as bidi spoofing and substitution of 
homographs from other scripts can be avoided by restricting each 
individual component of an identifier string to a single script or 
providing some obvious visual clue when scripts are mixed within a 
component. Bidirectional ambiguity can be controlled with judicious use 
of explicit directionality markers surrounding components and/or the 
composite identifier string.

Some identifier strings may carry private or confidential information 
as part of the string itself. Even a Directory DistinguishedName may 
contain specific information about organizational structure or personal 
data about the user to which it pertains. Distribution of such 
information can be constrained by law in certain countries.