[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Draft: Additional Security Considerations for Use of LDAP Directories
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.