RFC 4513
Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms 🎀
Okay bestie, this is RFC 4513 💖, and it's giving LDAP authentication and security, which is the stuff that decides who gets to peek at a directory and how they prove it. It's a Standards Track doc from the Network Working Group, written by R. Harrison, Ed. (the editor 🫶) at Novell, Inc., and it dropped in June 2006. It's a huge deal because it obsoletes RFC 2251, RFC 2829, and RFC 2830 💅. So if you're still reading those old ones, you're reading outdated tea. ☕
Status of This Memo 📜
ngl, this part is just the official paperwork, but it's important. This document is an Internet standards track protocol spec for the Internet community, and it's asking for discussion and suggestions to make it better 🌸. If you want to know where this protocol stands in the official standardization status, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🧚. And the distribution of this memo is unlimited, so share it with everyone you know 💜.
Copyright Notice ©️
The notice says Copyright (C) The Internet Society (2006). Yep, that's the legal bit, and it's all there 🦋.
Abstract ✨
Okay so the abstract is the highlight reel, and it's SO good 🔥. This doc describes the authentication methods and security mechanisms of LDAP 👑. It details setting up Transport Layer Security (TLS) using the StartTLS operation 🔐, which is literally how you upgrade a connection to be secure.
It also covers the simple Bind authentication method, including anonymous, unauthenticated, and name/password mechanisms 🍓. Then there's the Simple Authentication and Security Layer (SASL) Bind method, which includes the EXTERNAL mechanism 💀. It's giving options, and every one of them has its own personality.
Then it gets into the authentication and authorization states a session with an LDAP server can move through, plus the actions that trigger those state changes 🌈. Basically, it's the "what's happening right now and why" map for your connection 🧚.
Last but not least, this document, together with the other documents in the LDAP Technical Specification (see Section 1 of the specification's road map) 🗺️, obsoletes RFC 2251, RFC 2829, and RFC 2830 🥹. So yeah, it's the main character update 👑.
Table of Contents 🗂️
Here's the full roadmap so you don't get lost, bestie 🫶:
Table of Contents
1. Introduction ....................................................4
1.1. Relationship to Other Documents ............................6
1.2. Conventions ................................................6
2. Implementation Requirements .....................................7
3. StartTLS Operation ..............................................8
3.1. TLS Establishment Procedures ..............................8
3.1.1. StartTLS Request Sequencing .........................8
3.1.2. Client Certificate ..................................9
3.1.3. Server Identity Check ...............................9
3.1.3.1. Comparison of DNS Names ...................10
3.1.3.2. Comparison of IP Addresses ................11
3.1.3.3. Comparison of Other subjectName Types .....11
3.1.4. Discovery of Resultant Security Level ..............11
3.1.5. Refresh of Server Capabilities Information .........11
3.2. Effect of TLS on Authorization State .....................12
3.3. TLS Ciphersuites ..........................................12
4. Authorization State ............................................13
5. Bind Operation .................................................14
5.1. Simple Authentication Method ..............................14
5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14
5.1.2. Unauthenticated Authentication Mechanism of
Simple Bind ........................................14
5.1.3. Name/Password Authentication Mechanism of
Simple Bind ........................................15
5.2. SASL Authentication Method ................................16
5.2.1. SASL Protocol Profile ..............................16
5.2.1.1. SASL Service Name for LDAP ................16
5.2.1.2. SASL Authentication Initiation and
Protocol Exchange .........................16
5.2.1.3. Optional Fields ...........................17
5.2.1.4. Octet Where Negotiated Security
Layers Take Effect ........................18
5.2.1.5. Determination of Supported SASL
Mechanisms ................................18
5.2.1.6. Rules for Using SASL Layers ...............19
5.2.1.7. Support for Multiple Authentications ......19
5.2.1.8. SASL Authorization Identities .............19
5.2.2. SASL Semantics within LDAP .........................20
5.2.3. SASL EXTERNAL Authentication Mechanism .............20
5.2.3.1. Implicit Assertion ........................21
5.2.3.2. Explicit Assertion ........................21
6. Security Considerations ........................................21
6.1. General LDAP Security Considerations ......................21
6.2. StartTLS Security Considerations ..........................22
6.3. Bind Operation Security Considerations ....................23
6.3.1. Unauthenticated Mechanism Security Considerations ..23
6.3.2. Name/Password Mechanism Security Considerations ....23
6.3.3. Password-Related Security Considerations ...........23
6.3.4. Hashed Password Security Considerations ............24
6.4. SASL Security Considerations ..............................24
6.5. Related Security Considerations ...........................25
7. IANA Considerations ............................................25
8. Acknowledgements ...............................................25
9. Normative References ...........................................26
10. Informative References ........................................27
Appendix A. Authentication and Authorization Concepts .............28
A.1. Access Control Policy .....................................28
A.2. Access Control Factors ....................................28
A.3. Authentication, Credentials, Identity .....................28
A.4. Authorization Identity ....................................29
Appendix B. Summary of Changes ....................................29
B.1. Changes Made to RFC 2251 ..................................30
B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30
B.1.2. Section 4.2.2 ("Authentication and Other Security
Services") .........................................30
B.2. Changes Made to RFC 2829 ..................................30
B.2.1. Section 4 ("Required security mechanisms") .........30
B.2.2. Section 5.1 ("Anonymous authentication
procedure") ........................................31
B.2.3. Section 6 ("Password-based authentication") ........31
B.2.4. Section 6.1 ("Digest authentication") ..............31
B.2.5. Section 6.2 ("'simple' authentication choice under
TLS encryption") ...................................31
B.2.6. Section 6.3 ("Other authentication choices with
TLS") ..............................................31
B.2.7. Section 7.1 ("Certificate-based authentication
with TLS") .........................................31
B.2.8. Section 8 ("Other mechanisms") .....................32
B.2.9. Section 9 ("Authorization Identity") ...............32
B.2.10. Section 10 ("TLS Ciphersuites") ...................32
B.3. Changes Made to RFC 2830 ..................................32
B.3.1. Section 3.6 ("Server Identity Check") ..............32
B.3.2. Section 3.7 ("Refresh of Server Capabilities
Information") ......................................33
B.3.3. Section 5 ("Effects of TLS on a Client's
Authorization Identity") ...........................33
B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33Part 1 is wrapped up, bestie 🎀✨. Next up we dive into the actual sections, so stay tuned 🦋💅
1. Introduction ✨
okay so LDAP [RFC4510] is a seriously powerful protocol for accessing directories 🗂️💖. You can search, retrieve, and manipulate directory content, and it comes with a whole rich set of security functions to keep things locked down 🔐.
it's vital that these security functions work together across ALL LDAP clients and servers on the Internet 🌐, so there has to be a minimum set of security functions that every implementation claiming LDAP conformance has in common 🫶.
so the basic threats to an LDAP directory service include (but are not limited to) these baddies 😈:
(1) Getting into directory data you shouldn't be able to see, through data-retrieval operations 👀.
(2) Sneaking a peek at directory data by watching what other people are accessing 👀.
(3) Snatching reusable client authentication information by spying on other people's access 🕵️.
(4) Messing with directory data you're not allowed to change ✏️.
(5) Messing with configuration information you're not allowed to change ⚙️.
(6) Denial of Service: hogging resources (usually way more than anyone needs) on purpose so everyone else gets locked out 🚫.
(7) Spoofing: tricking a user or client into thinking information came from the directory when it really didn't, either by changing data in transit or redirecting the client's transport connection 🎭. It's also tricking a user or client into sending privileged information to a hostile entity that's pretending to be the directory server, and tricking a directory server into believing information came from a particular client when it actually came from a hostile entity. Not it 💀.
(8) Hijacking: an attacker takes the wheel of a protocol session that's already up and running 🚗💨.
okay the sorting here is so important 🧠. Threats (1), (4), (5), (6), (7), and (8) are active attacks. Threats (2) and (3) are passive attacks.
Threats (1), (4), (5), and (6) are due to hostile clients. Threats (2), (3), (7), and (8) are due to hostile agents on the path between client and server, or hostile agents posing as a server (e.g., IP spoofing) 🕸️.
LDAP offers the following security mechanisms, and this is the glow-up list ✨:
(1) Authentication by means of the Bind operation. The Bind operation provides a simple method that supports anonymous, unauthenticated, and name/password mechanisms, plus the Simple Authentication and Security Layer (SASL) method, which supports a wide variety of authentication mechanisms 🪪.
(2) Mechanisms to support vendor-specific access control facilities. LDAP does not offer a standard access control facility, so that part's up to the vendor 🤷♀️.
(3) Data integrity service by means of security layers in Transport Layer Security (TLS) or SASL mechanisms 🛡️.
(4) Data confidentiality service by means of security layers in TLS or SASL mechanisms 🤫.
(5) Server resource usage limitation by means of administrative limits configured on the server 🚦.
(6) Server authentication by means of the TLS protocol or SASL mechanisms 🪞.
LDAP may also be protected by means outside the LDAP protocol, e.g., with IP layer security [RFC4301] 🧱.
experience has shown that just letting implementations pick and choose which security mechanisms they'll support is NOT a strategy that leads to interoperability 🙃. Without mandates, clients keep getting written that don't support any security function the server supports, or worse, they only support mechanisms that give inadequate security for most situations 💀.
it's desirable to let clients authenticate using a variety of mechanisms, including ones where identities are represented as distinguished names [X.501][RFC4512], in string form [RFC4514], or as used in different systems (e.g., simple user names [RFC4013]) 🪪🌈. Some authentication mechanisms send credentials in plain text, and/or don't provide data security services, and/or are open to passive attacks. So to keep things secure and interoperable, it's necessary to identify a mandatory-to-implement mechanism for establishing transport-layer security services 🔒💜.
the set of security mechanisms provided in LDAP and described in this document is meant to cover the security needs of a wide range of deployment scenarios while still giving a high degree of interoperability among various LDAP implementations and deployments 🎀.
1.1. Relationship to Other Documents
this document is an integral part of the LDAP Technical Specification [RFC4510] 🧩.
this document, together with [RFC4510], [RFC4511], and [RFC4512], obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions) and 4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1 summarizes the substantive changes made to RFC 2251 by this document 📜.
this document obsoletes RFC 2829 in its entirety. Appendix B.2 summarizes the substantive changes made to RFC 2829 by this document 📜.
Sections 2 and 4 of RFC 2830 are obsoleted by [RFC4511]. The remainder of RFC 2830 is obsoleted by this document. Appendix B.3 summarizes the substantive changes made to RFC 2830 by this document 📜🦋.
1.2. Conventions
the key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 📖✨.
the term "user" means any human or application entity that's accessing the directory using a directory client. A directory client (or client) is also known as a directory user agent (DUA) 🙋♀️.
the term "transport connection" refers to the underlying transport services used to carry the protocol exchange, as well as the associations established by those services 🚚.
the term "TLS layer" refers to the TLS services used in providing security services, as well as the associations established by those services 🔐.
the term "SASL layer" refers to the SASL services used in providing security services, as well as the associations established by those services 🔑.
the term "LDAP message layer" refers to the LDAP Message (PDU) services used in providing directory services, as well as the associations established by those services 💌.
the term "LDAP session" refers to the combined services (transport connection, TLS layer, SASL layer, LDAP message layer) and their associations 🎀.
in general, security terms in this document are used consistently with the definitions provided in [RFC2828]. On top of that, several terms and concepts relating to security, authentication, and authorization are presented in Appendix A of this document. The formal definitions of these terms are outside the scope of this document, but understanding them is a prerequisite for much of the material here, so readers who are new to security concepts are encouraged to review Appendix A before reading the rest 📚🫶.
2. Implementation Requirements 📋
LDAP server implementations MUST support the anonymous authentication mechanism of the simple Bind method (Section 5.1.1) 🙌.
LDAP implementations that support any authentication mechanism other than the anonymous authentication mechanism of the simple Bind method MUST support the name/password authentication mechanism of the simple Bind method (Section 5.1.3), and MUST be capable of protecting this name/password authentication using TLS as established by the StartTLS operation (Section 3) 🔐💅.
implementations SHOULD disallow the name/password authentication mechanism by default when suitable data security services aren't in place, and they MAY provide other suitable data security services for use with this mechanism 🚫🔒.
implementations MAY support additional authentication mechanisms. Some of these are discussed below 🧩.
LDAP server implementations SHOULD support client assertion of authorization identity via the SASL EXTERNAL mechanism (Section 5.2.3) 🪪.
LDAP server implementations that support no authentication mechanism other than the anonymous mechanism of the simple bind method SHOULD support use of TLS as established by the StartTLS operation (Section 3). (Other servers MUST support TLS per the second paragraph of this section.) 🌸
implementations supporting TLS MUST support the TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the latter ciphersuite is recommended to encourage interoperability with implementations conforming to earlier LDAP StartTLS specifications 🧁💜.
3. StartTLS Operation 🦋
The Start Transport Layer Security (StartTLS) operation defined in Section 4.14 of [RFC4511] gives you the ability to establish TLS [RFC4346] in an LDAP session ✨.
the goals of using TLS with LDAP are to ensure data confidentiality and integrity, and to optionally provide authentication. TLS expressly provides these capabilities, but the authentication services of TLS are available to LDAP only in combination with the SASL EXTERNAL authentication method (see Section 5.2.3), and then only if the SASL EXTERNAL implementation chooses to make use of the TLS credentials 🔐🫧.
3.1. TLS Establishment Procedures
this section describes the overall procedures that clients and servers must follow for TLS establishment. These procedures take into consideration various aspects of the TLS layer, including discovery of the resultant security level and assertion of the client's authorization identity 📝💕.
3.1.1. StartTLS Request Sequencing
a client may send the StartTLS extended request at any time after establishing an LDAP session, EXCEPT:
- when TLS is already established on the session,
- when a multi-stage SASL negotiation is in progress on the session, or
- when there are outstanding responses for operation requests previously issued on the session.
as described in [RFC4511], Section 4.14.1, a (detected) violation of any of these requirements results in a return of the operationsError resultCode 🚨.
client implementers should make sure they strictly follow these operation sequencing requirements to prevent interoperability issues 🧐. Operational experience has shown that violating these requirements causes interoperability issues, because race conditions can keep servers from detecting some violations due to factors like server hardware speed and network latencies 🏎️💨.
there's no general requirement that the client have or have not already performed a Bind operation (Section 5) before sending a StartTLS operation request. However, where a client intends to perform both a Bind operation and a StartTLS operation, it SHOULD first perform the StartTLS operation, so that the Bind request and response messages are protected by the data security services established by the StartTLS operation 🔐🎀.
3.1.2. Client Certificate
if an LDAP server requests or demands that a client provide a user certificate during TLS negotiation, and the client doesn't present a suitable user certificate (e.g., one that can be validated), the server may use a local security policy to decide whether TLS negotiation still completes successfully 🪪🤔.
if a client that has provided a suitable certificate subsequently performs a Bind operation using the SASL EXTERNAL authentication mechanism (Section 5.2.3), the server may use information in the certificate to identify and authenticate the client 🕵️♀️💖.
3.1.3. Server Identity Check ✨
okay bestie, this is where the client gets to be a detective 🕵️♀️ to stop man-in-the-middle attacks, the client MUST verify the server's identity, the one shown in the server's Certificate message 🔒. we call the client's idea of who the server is (usually the identity it used to set up the transport connection) the "reference identity" 🎀.
the client figures out what type the reference identity is (like a DNS name or an IP address 🌐), then compares it against each subjectAltName value of that same type until something matches 💅. once there's a match, the server's identity is verified and the check is totally done ✨. different subjectAltName types get matched in different ways, so Sections 3.1.3.1 - 3.1.3.3 explain how to compare each kind 🦋.
the client may map the reference identity to a different type before comparing 👀. mappings can be done for every subjectAltName type the reference identity can be mapped to, but the reference identity should only be mapped to types where the mapping is either inherently secure (like pulling the DNS name out of a URI to compare with a dNSName) or done in a secure manner (like using DNSSEC, or user- or admin-configured host-to-address/address-to-host lookup tables) 🔐.
the server's identity can also be verified by comparing the reference identity to the Common Name (CN) [RFC4519] value in the leaf Relative Distinguished Name (RDN) of the subjectName field of the server's certificate 📜. this comparison uses the DNS name comparison rules from Section 3.1.3.1, below, except that no wildcard matching is allowed 🚫. the CN is existing practice, but it's deprecated, and Certification Authorities are encouraged to provide subjectAltName values instead 🙈. also, the TLS implementation may represent DNs in certificates according to X.500 or other conventions, so some X.500 implementations order the RDNs left-to-right (most significant to least significant) instead of LDAP's right-to-left convention 🧩.
if the server identity check fails, user-oriented clients SHOULD either notify the user (clients may let the user keep going with the LDAP session in this case) or close the transport connection and indicate that the server's identity is suspect 🚨. automated clients SHOULD close the transport connection and then return or log an error saying that the server's identity is suspect, or both 🤖.
beyond this check, clients should be prepared to do further checking to make sure the server is authorized to provide the service it's been asked for 👑. the client may need to lean on local policy information to make that call 💜.
3.1.3.1. Comparison of DNS Names 🌸
if the reference identity is an internationalized domain name, conforming implementations MUST convert it to the ASCII Compatible Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490] before comparing it with subjectAltName values of type dNSName 🌍. specifically, conforming implementations MUST do the conversion from Section 4 of RFC 3490 like this:
- in step 1, the domain name SHALL be considered a "stored string";
- in step 3, set the flag called
UseSTD3ASCIIRules; - in step 4, process each label with the
ToASCIIoperation; and - in step 5, change all label separators to
U+002E(full stop).
after the "to-ASCII" conversion, the DNS labels and names MUST be compared for equality according to the rules in Section 3 of RFC3490 🎀.
the * (ASCII 42) wildcard character is allowed in subjectAltName values of type dNSName, but only as the left-most (least significant) DNS label in that value 🌟. this wildcard matches any left-most DNS label in the server name. so the subject *.example.com matches the server names a.example.com and b.example.com, but it does NOT match example.com or a.b.example.com 🙅♀️.
3.1.3.2. Comparison of IP Addresses 🧚
when the reference identity is an IP address, the identity MUST be converted to the "network byte order" octet string representation [RFC791][RFC2460] 🔢. for IP Version 4, as specified in RFC 791, the octet string contains exactly four octets. for IP Version 6, as specified in RFC 2460, the octet string contains exactly sixteen octets 💫. that octet string then gets compared against subjectAltName values of type iPAddress, and a match happens if the reference identity octet string and the value octet strings are identical 💖.
3.1.3.3. Comparison of Other subjectName Types 🦋
client implementations MAY support matching against subjectAltName values of other types, as described in other documents ✨.
3.1.4. Discovery of Resultant Security Level 🔐
after a TLS layer is established in an LDAP session, both parties each independently decide whether or not to keep going, based on local policy and the security level they achieved 👀. if either party decides the security level is inadequate for it to continue, it SHOULD remove the TLS layer immediately after the TLS (re)negotiation has completed (see [RFC4511], Section 4.14.3, and Section 3.2 below) 🙅♀️. implementations may reevaluate the security level at any time, and upon finding it inadequate, should remove the TLS layer 💅.
3.1.5. Refresh of Server Capabilities Information 🌈
after a TLS layer is established in an LDAP session, the client SHOULD discard or refresh all information it got about the server before TLS negotiation started, as long as it didn't get that info through secure mechanisms 🧹. this protects against man-in-the-middle attacks that may have messed with any server capabilities info retrieved before the TLS layer was installed 🛡️.
the server may advertise different capabilities after installing a TLS layer. in particular, the value of supportedSASLMechanisms may be different after TLS is installed. specifically, the EXTERNAL and PLAIN [PLAIN] mechanisms are likely to be listed only after a TLS layer has been installed 🔑.
3.2. Effect of TLS on Authorization State 🎀
establishing, changing, and/or closing TLS may cause the authorization state to move to a new state 🦋. this is discussed further in Section 4 ✨.
3.3. TLS Ciphersuites 💜
several issues should be considered when picking TLS ciphersuites for a given situation 🧐. these include:
- the ciphersuite's ability to provide adequate confidentiality protection for passwords and other data sent over the transport connection. client and server implementers should recognize that some TLS ciphersuites provide no confidentiality protection at all, while other ciphersuites that do provide it may be vulnerable to being cracked by brute force, especially with ever-increasing CPU speeds that cut the time needed to pull off those attacks 💀.
- client and server implementers should carefully weigh the value of the password or data being protected against the level of confidentiality protection the ciphersuite provides, to make sure the protection is actually appropriate 🧠.
- the ciphersuite's vulnerability (or lack of it) to man-in-the-middle attacks. ciphersuites vulnerable to man-in-the-middle attacks SHOULD NOT be used to protect passwords or sensitive data, unless the network configuration is such that the danger of a man-in-the-middle attack is negligible 🚨.
- after a TLS negotiation (initial or subsequent) is completed, both protocol peers should independently verify that the security services provided by the negotiated ciphersuite are adequate for the intended use of the LDAP session. if they're not, the TLS layer should be closed 🫶.
4. Authorization State ✨
every LDAP session has an associated authorization state 🌸. this state is made up of lots of factors, like what (if any) authentication state has been established, how it was established, and what security services are in place 💅. some factors may be determined and/or affected by protocol events (e.g., Bind, StartTLS, or TLS closure), and some may be determined by external events (e.g., time of day or server load) ⏰.
while it's often convenient to view authorization state in simple terms (as we often do in this technical specification), like "an anonymous state," it's worth noting that authorization systems in LDAP implementations commonly involve many factors that interrelate in complex ways 🧩.
authorization in LDAP is a local matter 🏠. one of the key factors in making authorization decisions is the authorization identity. the Bind operation (defined in Section 4.2 of [RFC4511] and discussed further in Section 5 below) lets information get exchanged between the client and server to establish an authorization identity for the LDAP session 🔑. the Bind operation may also be used to move the LDAP session to an anonymous authorization state (see Section 5.1.1) 👻.
when the session is first established, it has an anonymous authorization identity 🫧. among other things, this means the client does not need to send a BindRequest in the first PDU of the LDAP message layer 🙌. the client may send any operation request before performing a Bind operation, and the server MUST treat it as if it had been performed after an anonymous Bind operation (Section 5.1.1) 🎀.
when the server receives a Bind request, it immediately moves the session to an anonymous authorization state 💫. if the Bind request is successful, the session moves to the requested authentication state with its associated authorization state. otherwise, the session stays in an anonymous state 🌷.
other events, both internal and external to LDAP, may also move the authentication and authorization states to an anonymous one 🌙. for instance, establishing, changing, or closing data security services may move things to an anonymous state, or the user's credential information (e.g., certificate) may have expired 🥀. the first is an example of an event internal to LDAP, and the second is an example of an event external to LDAP 🧠.
5. Bind Operation 🌈
the Bind operation ([RFC4511], Section 4.2) lets authentication information get exchanged between the client and server to establish a new authorization state 🔐.
the Bind request typically specifies the desired authentication identity. some Bind mechanisms also let the client specify the authorization identity 🪪. if the authorization identity isn't specified, the server derives it from the authentication identity in an implementation-specific manner 🛠️.
if the authorization identity is specified, the server MUST verify that the client's authentication identity is permitted to assume (e.g., proxy for) the asserted authorization identity 🕵️♀️. the server MUST reject the Bind operation with an invalidCredentials resultCode in the Bind response if the client is not so authorized 🚫💀.
5.1. Simple Authentication Method 💖
okay so the simple authentication method of the Bind Operation gives you three authentication mechanisms 🦋:
- An anonymous authentication mechanism (Section 5.1.1).
- An unauthenticated authentication mechanism (Section 5.1.2).
- A name/password authentication mechanism using credentials consisting of a name (in the form of an LDAP distinguished name [RFC4514]) and a password (Section 5.1.3).
5.1.1. Anonymous Authentication Mechanism of Simple Bind 🌸
an LDAP client can use the anonymous authentication mechanism of the simple Bind method to explicitly set up an anonymous authorization state. it does this by sending a Bind request with a name value of zero length and choosing the simple authentication option with a password value of zero length. zero-length everything, very minimalist 🙈
5.1.2. Unauthenticated Authentication Mechanism of Simple Bind 🍓
an LDAP client can also use the unauthenticated authentication mechanism of the simple Bind method to set up an anonymous authorization state. the move is sending a Bind request with a name value (a distinguished name in LDAP string form [RFC4514] of non-zero length) and choosing the simple authentication option with a password value of zero length.
the distinguished name the client sends is meant for trace purposes only, like logging 📝. it isn't authenticated or validated in any way, and that includes checking whether the DN points to a real directory object. it also must not be used, directly or indirectly, for authorization. so it's basically a label, not an ID card 🙅♀️
unauthenticated Bind operations can cause some serious security problems (see Section 6.3.1). the sneaky part is that people doing Name/Password Authentication might accidentally send an empty password, and then badly built clients end up asking for unauthenticated access without anyone meaning to. 😭
so here's the safety checklist 🫶. clients SHOULD be built so that a user has to pick the Unauthenticated Authentication Mechanism some way other than typing an empty password. clients SHOULD also block an empty password input in a Name/Password Authentication user interface. and servers SHOULD, by default, fail Unauthenticated Bind requests with a resultCode of unwillingToPerform. 💅
5.1.3. Name/Password Authentication Mechanism of Simple Bind 🔥
an LDAP client can use the name/password authentication mechanism of the simple Bind method to set up an authenticated authorization state. the client sends a Bind request with a name value (a distinguished name in LDAP string form [RFC4514] of non-zero length) and picks the simple authentication option with an OCTET STRING password value of non-zero length.
servers that map the DN from the Bind request to a directory entry with one or more passwords tied to this mechanism will compare the password the client presented against that set. if it matches any member of the set, it's valid. ✨
the result codes tell the story 📖:
invalidDNSyntaxmeans the DN in the name value is syntactically invalid.invalidCredentialsmeans the DN is syntactically correct but not valid for authentication, or the password isn't valid for that DN, or the server otherwise considers the credentials invalid. 💀successmeans the credentials are valid and the server is willing to provide service to the entity those credentials identify. 👑
the server's behavior is undefined for Bind requests that use the name/password mechanism with a zero-length name value and a non-zero-length password value. so nobody can really predict what happens there, and that's giving chaos 🌪️
the name/password authentication mechanism of the simple Bind method is not suitable for authentication in environments without confidentiality protection. no protection, no password party 🔒
5.2. SASL Authentication Method 🎀
the sasl authentication method of the Bind Operation gives you access to facilities for using any SASL mechanism. that covers authentication mechanisms and other services too, like data security services 🧚
5.2.1. SASL Protocol Profile 🦋
LDAP lets you authenticate via any SASL mechanism [RFC4422]. but LDAP already has native anonymous and name/password (plain text) authentication methods, so the ANONYMOUS [RFC4505] and PLAIN [PLAIN] SASL mechanisms are typically not used with LDAP. we already have those vibes built in 🌈
each protocol that uses SASL services is required to supply certain information that profiles how SASL is exposed through that protocol ([RFC4422], Section 4). this section explains how LDAP meets each of those profiling requirements. ✨
5.2.1.1. SASL Service Name for LDAP 📛
the SASL service name for LDAP is "ldap", and it's registered with the IANA as a SASL service name. official, iconic 👑
5.2.1.2. SASL Authentication Initiation and Protocol Exchange 🌸
SASL authentication starts with a BindRequest message ([RFC4511], Section 4.2) that has these parameters 🧾:
- The version is
3. - The AuthenticationChoice is
sasl. - The mechanism element of the SaslCredentials sequence contains the value of the desired SASL mechanism.
- The optional credentials field of the SaslCredentials sequence MAY be used to provide an initial client response for mechanisms that are defined to have the client send data first (see [RFC4422], Sections 3 and 5).
in general, a SASL authentication exchange is a back-and-forth of server challenges and client responses. what goes inside them depends on the SASL mechanism. so for some mechanisms, the client might need to answer one or more challenges by sending BindRequest messages multiple times 🔁. a challenge shows up when the server sends a BindResponse message with the resultCode set to saslBindInProgress. that basically means "send me a new BindRequest with the same SASL mechanism so we can keep going" 💬.
from the LDAP message layer's point of view, challenges and responses are opaque binary tokens of arbitrary length. LDAP servers use the serverSaslCreds field (an OCTET STRING) in a BindResponse message to send each challenge. LDAP clients use the credentials field (an OCTET STRING) in the SaslCredentials sequence of a BindRequest message to send each response. heads up: LDAP isn't text based, and unlike some Internet protocols that use SASL, it does not Base64-transform these values 🙅♀️
clients sending a BindRequest with the sasl choice selected SHOULD send a zero-length value in the name field. servers receiving a BindRequest with the sasl choice selected SHALL ignore any value in the name field. 🫶
a client can abort a SASL Bind negotiation by sending a BindRequest with a different value in the mechanism field of SaslCredentials, or with an AuthenticationChoice other than sasl. ✋
if the client sends a BindRequest with an empty string in the SASL mechanism field, the server MUST return a BindResponse with a resultCode of authMethodNotSupported. this lets the client abort a negotiation if it wants to try again with the same SASL mechanism. 🔄
the server says the SASL challenge-response exchange is finished by responding with a BindResponse whose resultCode value is not saslBindInProgress. 🏁
the serverSaslCreds field in the BindResponse can carry an optional challenge along with a success notification, for mechanisms that are defined to have the server send extra data alongside a successful completion. bonus data, bestie 🎁
5.2.1.3. Optional Fields 🍬
as covered above, LDAP gives you an optional field for an initial response in the message that starts the SASL exchange. it also gives you an optional field for extra data in the message that reports the authentication outcome. since the mechanism-specific content in these fields can be zero length, SASL requires protocol specifications to explain how an empty field is told apart from an absent one. 🧐
zero-length initial response data is told apart from no initial response data in the starting message (a BindRequest PDU) by whether the SaslCredentials.credentials OCTET STRING (of length zero) is present in that PDU. if the client doesn't plan to send an initial response with the BindRequest that starts the SASL exchange, it MUST omit the SaslCredentials.credentials OCTET STRING, rather than including a zero-length OCTET STRING. no sneaky empty placeholders 🙅♀️
zero-length additional data is told apart from no additional response data in the outcome message (a BindResponse PDU) by whether the serverSaslCreds OCTET STRING (of length zero) is present in that PDU. if a server doesn't plan to send additional data in the BindResponse that reports the outcome, the server SHALL omit the serverSaslCreds OCTET STRING, rather than including a zero-length OCTET STRING. 🎯
5.2.1.4. Octet Where Negotiated Security Layers Take Effect 🔐
SASL layers take effect after the server sends, and the client receives, the final BindResponse in the SASL exchange with a resultCode of success. ✅
once a SASL layer that provides data integrity or confidentiality services takes effect, it stays in effect until a new layer is installed. the switch happens at the first octet after the final BindResponse of the Bind operation that installed the new layer. so a failed or non-SASL Bind doesn't mess with an established SASL layer. stable, reliable, very main character 💜
5.2.1.5. Determination of Supported SASL Mechanisms 🔍
clients can figure out which SASL mechanisms a server supports by reading the 'supportedSASLMechanisms' attribute from the root DSE (DSA-Specific Entry) ([RFC4512], Section 5.1). if that attribute has values, they list the mechanisms the server supports in the current LDAP session state. 📋
LDAP servers SHOULD allow all clients -- even ones with an anonymous authorization -- to retrieve the 'supportedSASLMechanisms' attribute of the root DSE both before and after the SASL authentication exchange. the after-part is there so the client can spot possible downgrade attacks (see Section 6.4 and [RFC4422], Section 6.1.2). sneaky attackers, we see you 👀
because SASL mechanisms provide critical security functions, clients and servers should be configurable to specify which mechanisms are acceptable and allow only those to be used. clients and servers must also confirm that the negotiated security level meets their requirements before they go ahead and use the session. 🛡️
5.2.1.6. Rules for Using SASL Layers 📜
when a SASL layer gets installed, the client SHOULD discard or refresh all information it got about the server before the SASL negotiation started, unless it got that information through secure mechanisms. clean slate energy ✨
if a lower-level security layer (such as TLS) is installed, any SASL layer SHALL be layered on top of it, no matter what order they were negotiated in. otherwise, the SASL layer and other security layers act independently. for example, if both a TLS layer and a SASL layer are in effect, removing the TLS layer doesn't affect the SASL layer's ongoing service. they're besties, but they don't need each other 🧚♀️
5.2.1.7. Support for Multiple Authentications 🌷
LDAP supports multiple SASL authentications as defined in [RFC4422], Section 4. as many rounds as you need, no cap 💅
5.2.1.8. SASL Authorization Identities ✨
okay so some SASL mechanisms let clients ask for a specific authorization identity for the LDAP session ([RFC4422], Section 3.4) 🫶 but whether the current authentication identity is actually allowed to have that identity is a matter of local policy, so the server gets the final say 💅. An authorization identity is a string of UTF-8 [RFC3629] encoded [Unicode] characters that follows this Augmented Backus-Naur Form (ABNF) [RFC4234] grammar 🦋:
authzId = dnAuthzId / uAuthzId
; distinguished-name-based authz id
dnAuthzId = "dn:" distinguishedName
; unspecified authorization id, UTF-8 encoded
uAuthzId = "u:" userid
userid = *UTF8 ; syntax unspecifiedwhere the distinguishedName rule is defined in Section 3 of [RFC4514] and the UTF8 rule is defined in Section 1.4 of [RFC4512] 🌸
The dnAuthzId choice is for asserting an authorization identity as a distinguished name, which gets matched using the distinguishedNameMatch matching rule ([RFC4517], Section 4.2.15) 💜 There is no requirement that the asserted distinguishedName value be an entry that actually exists in the directory, so don't assume it does 🙈
The uAuthzId choice lets clients assert an identity that is not in distinguished name form 💖 The userid is only defined as a sequence of UTF-8 [RFC3629] encoded [Unicode] characters, and anything beyond that is a local matter 🧚 For example, the userid could identify a user of a specific directory service, be a login name, or be an email address 💅 A uAuthzId SHOULD NOT be assumed to be globally unique 😭 To compare uAuthzId values, each uAuthzId value MUST be prepared as a "query" string ([RFC3454], Section 7) using the SASLprep [RFC4013] algorithm, and then the two values are compared octet-wise 🔥
The grammar above is extensible 🌈 The authzId production may be extended to support additional forms of identities, and each form is told apart by its unique prefix (see Section 3.12 of [RFC4520] for registration requirements) ⭐
5.2.2. SASL Semantics within LDAP 🎀
Implementers should take care to keep the semantics of SASL specifications intact when they handle data that means something different in the LDAP protocol 🫶 Don't let your guard down here, bestie 😭
For example, the SASL DIGEST-MD5 authentication mechanism [DIGEST-MD5] uses an authentication identity and a realm that are syntactically simple strings, and semantically they're just plain username [RFC4013] and realm values 🍓 These are not LDAP DNs, and there is no requirement that they be represented or treated as DNs ✨
5.2.3. SASL EXTERNAL Authentication Mechanism 🦋
A client can use the SASL EXTERNAL ([RFC4422], Appendix A) mechanism to ask the LDAP server to authenticate it and set up a resulting authorization identity, using security credentials that were exchanged at a lower security layer (like TLS authentication) 🔐 If the client's authentication credentials were never established at a lower security layer, the SASL EXTERNAL Bind MUST fail with a resultCode of inappropriateAuthentication 💀 This leaves the LDAP session in an anonymous state (Section 4), but the state of any installed security layer is unaffected, so your encryption is still there 🫶
A client may either ask for its authorization identity to be automatically derived from the authentication credentials exchanged at a lower security layer, or it may explicitly provide the authorization identity it wants 👑 The first is called an implicit assertion, and the second is called an explicit assertion 💜
5.2.3.1. Implicit Assertion 🌸
An implicit authorization identity assertion is made by sending a Bind request of the SASL form using the EXTERNAL mechanism name, without the optional credentials field (found within the SaslCredentials sequence in the BindRequest) 🧚 The server derives the client's authorization identity from the authentication identity supplied by a security layer (for example, a public key certificate used during TLS layer installation), according to local policy 🦋 How this actually happens is implementation specific, so it's up to each implementation 🙈
5.2.3.2. Explicit Assertion 💅
An explicit authorization identity assertion is made by sending a Bind request of the SASL form using the EXTERNAL mechanism name, with the credentials field (found within the SaslCredentials sequence in the BindRequest) ✨ The value of the credentials field (an OCTET STRING) is the asserted authorization identity, and it MUST be constructed as documented in Section 5.2.1.8 🎀
6. Security Considerations 🔥
Security issues show up all throughout this document 💀 The unsurprising conclusion is that security is an integral and necessary part of LDAP, so no cap, it's not optional 👑 This section covers a bunch of LDAP-related security considerations, so pay attention 🫶
6.1. General LDAP Security Considerations 🌈
LDAP itself does not provide any security or protection from people accessing or updating the directory by means other than the LDAP protocol 😭 For example, a database administrator could inspect the server's database files directly 🙈
Sensitive data can show up in almost any LDAP message, and disclosing it may be subject to privacy laws or other legal regulation in many countries 🍓 Implementers should take appropriate measures to protect sensitive data from being disclosed to unauthorized entities 💖
A session where the client has not established data integrity and privacy services (for example, via StartTLS, IPsec, or a suitable SASL mechanism) is open to man-in-the-middle attacks that can view and modify information in transit 💀 Client and server implementers SHOULD take measures to protect sensitive data in the LDAP session from these attacks by using the data protection services discussed in this document 🔐 Clients and servers should be able to be configured to require these protections ✨ A resultCode of confidentialityRequired means the server needs stronger data confidentiality protection before it can perform the requested operation 🫶
Access control should always be applied when reading sensitive information or updating directory information 💅
Various security factors, including authentication and authorization information and data security services, may change during the course of the LDAP session, or even while a particular operation is being performed 🌸 Implementations should be robust in how they handle changing security factors 🦋
6.2. StartTLS Security Considerations 🔐
All of the security gained from the StartTLS operation comes from TLS itself 🧚 The StartTLS operation on its own doesn't provide any additional security 🙈
How secure TLS actually is depends directly on both the quality of the TLS implementation used and how that implementation is used 💜 Also, a man-in-the-middle attacker can remove the StartTLS extended operation from the 'supportedExtension' attribute of the root DSE 😭 Both parties SHOULD independently ascertain and consent to the security level achieved once TLS is established, and before they start using the TLS-protected session 💀 For example, the security level of the TLS layer might have been negotiated down to plaintext 🔥
Clients MUST either warn the user when the security level achieved does not provide an acceptable level of data confidentiality and/or data integrity protection, or be configurable to refuse to proceed without an acceptable level of security 🫶
As stated in Section 3.1.2, a server may use a local security policy to decide whether to successfully complete TLS negotiation 👑 Information in the user's certificate that is originated or verified by the certification authority should be used by the policy administrator when configuring the identification and authorization policy 🌈
Server implementers SHOULD allow server administrators to choose whether and when data confidentiality and integrity are required, and also choose whether authentication of the client during the TLS handshake is required 🎀
Implementers should be aware of, and understand, the TLS security considerations discussed in the TLS specification [RFC4346] ✨
6.3. Bind Operation Security Considerations 🍓
This section covers several security considerations for LDAP authentication via the Bind operation 💖
6.3.1. Unauthenticated Mechanism Security Considerations 💀
Operational experience shows that clients can (and frequently do) misuse the unauthenticated authentication mechanism of the simple Bind method (see Section 5.1.2) 😭 For example, a client program might decide to grant access to non-directory information just because a Bind operation succeeded 🙈 LDAP server implementations may return a success response to an unauthenticated Bind request 💅 This can wrongly leave the client thinking the server has authenticated the identity represented by the distinguished name, when in reality an anonymous authorization state has been established 🔥 Clients that use the results of a simple Bind operation to make authorization decisions should actively detect unauthenticated Bind requests (by verifying that the supplied password is not empty) and react appropriately 🫶
6.3.2. Name/Password Mechanism Security Considerations 🔐
The name/password authentication mechanism of the simple Bind method discloses the password to the server, and that's an inherent security risk 💀 There are other mechanisms, such as SASL DIGEST-MD5 [DIGEST-MD5], that don't disclose the password to the server 👑
6.3.3. Password-Related Security Considerations 🔐
okay so LDAP lets a single entry have multiple values for a password attribute 👀 bestie, if the system is supposed to give each entry exactly one password, admins need controls that actually enforce that. no loopholes 🙅♀️
sending clear text passwords (or any other unprotected credentials) over open networks is a hard no 🚫 when the transport can't guarantee confidentiality. LDAP implementations SHOULD NOT turn on support for these by default 💀 unless the session is protected by TLS or some other data confidentiality and integrity mechanism. default-on is how people get hacked, periodt
sending passwords in the clear (for authentication or for changing them) is a seriously risky move 😭 you can dodge that by using SASL mechanisms [RFC4422] that never send the password in the clear, or by negotiating transport or session layer confidentiality before any password value gets sent. ✨
to keep passwords safe, a server that supports any password-based mechanism that sends passwords in the clear MUST support a policy mechanism. this policy has to require one of the following at the time of authentication or password modification:
- A TLS layer has been successfully installed.
OR
- Some other data confidentiality mechanism that protects the password value from eavesdropping has been provided.
OR
- The server returns a resultCode of
confidentialityRequiredfor the operation (i.e., name/password Bind with password value, SASL Bind transmitting a password value in the clear, add or modify including auserPasswordvalue, etc.), even if the password value is correct.
servers can also add policy mechanisms that lock down or otherwise protect accounts when the server notices that an account's password was sent in the clear 🛡️ that's giving protective big sister energy 🫶
6.3.4. Hashed Password Security Considerations 🧂
some auth mechanisms (like DIGEST-MD5) send a hash of the password, and that hash can be vulnerable to offline dictionary attacks 😬 implementers should be careful to protect those hashed values in transit with TLS or another confidentiality mechanism. hash is not a free pass, bestie 💅
6.4. SASL Security Considerations 🕵️♀️
this one is spicy. until data integrity service is installed on an LDAP session, an attacker can change the values sent back for the supportedSASLMechanisms attribute 😱 and downgrade the list so only the weakest mechanism is left. yikes 💀
to catch this, the client can grab the SASL mechanisms the server offers both before and after data integrity service is installed. if the protected list (the one fetched after integrity was installed) has a stronger mechanism than the earlier list, the client should assume the earlier list was tampered with 🚨 in that case, it is recommended that the client close the underlying transport connection and then reconnect to reestablish the session. start fresh, no drama 🫧
6.5. Related Security Considerations 📚
more security considerations for the auth methods and mechanisms in this document also apply. go check [RFC4422], [RFC4013], [RFC3454], and [RFC3629] 🤓 they've got the deeper lore ✨
7. IANA Considerations 🗂️
IANA has updated the LDAP Protocol Mechanism registry 💜 this document and [RFC4511] are the official technical spec for the StartTLS (1.3.6.1.4.1.1466.20037) extended operation. very iconic of them 👑
IANA has also updated the LDAP LDAPMessage types registry 🧚 this document and [RFC4511] are the definitive spec for the bindRequest (0) and bindResponse (1) message types.
IANA updated the LDAP Bind Authentication Method registry too 🎀 this document and [RFC4511] are the definitive spec for the simple (0) and sasl (3) bind authentication methods.
last one: the LDAP authzid prefixes registry got an update 🌸 this document is the definitive spec for the dn: (dnAuthzId) and u: (uAuthzId) authzid prefixes. main character energy 💖
8. Acknowledgements 🫶
this document combines info from RFC 2251, RFC 2829, and RFC 2830 🧩 RFC 2251 came out of the Access, Searching, and Indexing of Directories (ASID) Working Group. RFC 2829 and RFC 2830 came out of the LDAP Extensions (LDAPEXT) Working Group. so many people made this possible, iykyk 🥹
this document is a product of the IETF LDAP Revision (LDAPBIS) working group 🌈
9. Normative References 📖
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.1", RFC 4346, March 2006.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
June 2006.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): Technical Specification Road Map", RFC
4510, June 2006.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): String Representation of Distinguished
Names", RFC 4514, June 2006.
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
2006.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
Protocol (LDAP): Schema for User Applications", RFC
4519, June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
(IANA) Considerations for the Lightweight Directory
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-
5), as amended by the "Unicode Standard Annex #27:
Unicode 3.1" (http://www.unicode.org/reports/tr27/) and
by the "Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.10. Informative References 🔍
[DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism", Work in Progress,
March 2006.
[PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in
Progress, March 2005.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC
2828, May 2000.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4505] Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505,
June 2006.Appendix A. Authentication and Authorization Concepts 🧠
this appendix is non-normative ✨
this appendix defines the basic terms, concepts, and how they relate to each other when it comes to authentication, authorization, credentials, and identity 🫧 these concepts are what make it possible to describe how different security approaches get used in client authentication and authorization.
A.1. Access Control Policy 🚪
an access control policy is a set of rules that protects resources, usually based on what persons or other entities accessing those resources are allowed to do 💅 security objects and mechanisms like the ones described here let you write those policies and enforce them.
A.2. Access Control Factors 🎯
when a request is being processed by a server, it can be linked to a bunch of security-related factors 👀 the server uses these to decide whether to process the request and how. these are called access control factors (ACFs). they might include source IP address, encryption strength, the type of operation being requested, time of day, etc.. some factors belong to the request itself, some belong to the transport connection the request came through, and some (like time of day) are "environmental" 🌤️
access control policies are written in terms of access control factors. for example, "a request having ACFs i,j,k can perform operation Y on resource Z" 🧁 which ACFs a server makes available for this is implementation specific.
A.3. Authentication, Credentials, Identity 🪪
authentication credentials are the evidence one party gives another to prove who they are (say, a user) when they're trying to set up a new authorization state with the other party (usually a server) 🔑 authentication is the whole process of generating, sending, and verifying those credentials, and therefore verifying the identity they claim. an authentication identity is the name presented in a credential ✨
there are lots of forms of authentication credentials, and the form depends on which authentication mechanism the parties negotiated 🦋 X.509 certificates, Kerberos tickets, and simple identity and password pairs are all examples. also, an authentication mechanism may restrict which forms of authentication identities can be used with it 💜
A.4. Authorization Identity 🎀
okay so an authorization identity is one kind of access control factor 💅 It's the name of the user or other entity asking for stuff to get done. Access control policies are usually written in terms of these, like "entity X can perform operation Y on resource Z" 🔐
The authorization identity of an LDAP session is usually basically the same as the authentication identity the client showed, but it doesn't have to be 👀 SASL lets clients name an authorization identity that's different from the authentication identity their credentials prove. That's how proxy servers can log in with their own credentials and still ask for the access privileges of whoever they're proxying for 🦋 [RFC4422]
It's also kinda messy with things like TLS, because the identity TLS gives you might not match the authorization identities a server uses in its access control policy 😭 So the server needs a server-specific mapping to get from one to the other. How a server builds and checks an authorization identity out of the credentials a client gives it is implementation specific, so each server handles that its own way ✨
Appendix B. Summary of Changes 🌈
This appendix is non-normative.
This appendix sums up the big changes made to RFC 2251, RFC 2829 and RFC 2830 🧚 On top of the specific changes listed below, you should know there are tons of general editorial changes too, compared to the original documents. Those include:
- The stuff from RFC 2251 Sections 4.2.1 and 4.2.2, RFC 2829 (everything except Sections 2 and 4), and RFC 2830 got squished together into one document 🍓
- That combined material got reorganized and edited a lot, so related topics are grouped, the flow is smoother, and the intent is clearer ✨
- Changes were made all over the text to line up with the definitions of LDAP protocol layers and IETF security terminology 🌸
- The security considerations from both documents got big updates and additions based on current operational experience 🔥
B.1. Changes Made to RFC 2251 💜
This section sums up the substantive changes this document made to Sections 4.2.1 and 4.2.2 of RFC 2251. Extra substantive changes to Section 4.2.1 of RFC 2251 are also written up in [RFC4511] 🎀
B.1.1. Section 4.2.1 ("Sequencing of the Bind Request")
- Paragraph 1: Removed the sentence, "If at any stage the client wishes to abort the bind process it MAY unbind and then drop the underlying connection". The Unbind operation still allows this behavior, it's just not written down explicitly anymore 🙈
- Clarified that the session moves to an anonymous state as soon as the BindRequest PDU is received, and that it only moves to a non-anonymous state if and when the Bind request succeeds 💖
B.1.2. Section 4.2.2 ("Authentication and Other Security Services")
- RFC 2251 says anonymous authentication MUST be performed using the simple bind method. This specification defines the anonymous authentication mechanism of the simple bind method and requires all conforming implementations to support it. Other authentication mechanisms that produce anonymous authentication and authorization state may also be implemented and used by conforming implementations 🦋
B.2. Changes Made to RFC 2829 🌷
This section sums up the substantive changes made to RFC 2829.
B.2.1. Section 4 ("Required security mechanisms")
- The name/password authentication mechanism (see Section B.2.5 below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as LDAP's mandatory-to-implement password-based authentication mechanism. Implementations are encouraged to keep supporting SASL DIGEST-MD5 [DIGEST-MD5] 👑
B.2.2. Section 5.1 ("Anonymous authentication procedure")
- Clarified that anonymous authentication involves a name value of zero length and a password value of zero length. The unauthenticated authentication mechanism was added to handle simple Bind requests with a name value of non-zero length and a password value of zero length 🌈
B.2.3. Section 6 ("Password-based authentication")
- See Section B.2.1.
B.2.4. Section 6.1 ("Digest authentication")
- Since the SASL-DIGEST-MD5 mechanism isn't mandatory to implement anymore, this section is now historical and wasn't included in this document 📜 RFC 2829, Section 6.1, still documents the SASL DIGEST-MD5 authentication mechanism ✨
B.2.5. Section 6.2 ("'simple' authentication choice under TLS encryption")
- Renamed the "simple" authentication mechanism to the name/password authentication mechanism, because that name describes it better 💅
- The use of TLS got generalized to line up with the definitions of LDAP protocol layers. TLS establishment is now its own independent topic, and it works for all authentication mechanisms and other security layers 🫶
- Removed the implication that the userPassword attribute is the only place password values for authentication get stored. There's no longer any implied requirement for how or where passwords are stored on the server for authentication 🔐
B.2.6. Section 6.3 ("Other authentication choices with TLS")
- See Section B.2.5.
B.2.7. Section 7.1 ("Certificate-based authentication with TLS")
- See Section B.2.5.
B.2.8. Section 8 ("Other mechanisms")
- All SASL authentication mechanisms are now explicitly allowed within LDAP. That means the SASL ANONYMOUS and SASL PLAIN mechanisms are no longer ruled out for use within LDAP 🎉
B.2.9. Section 9 ("Authorization Identity")
- Specified matching rules for dnAuthzId and uAuthzId values. In particular, the DN value in the dnAuthzId form must be matched using DN matching rules, and the uAuthzId value MUST be prepared using SASLprep rules before it's compared octet-wise 🧠
- Clarified that uAuthzId values should not be assumed to be globally unique 🙅♀️
B.2.10. Section 10 ("TLS Ciphersuites")
- TLS ciphersuite recommendations aren't included in this specification anymore. Implementations must now support the
TLS_RSA_WITH_3DES_EDE_CBC_SHAciphersuite and should keep supporting theTLS_DHE_DSS_WITH_3DES_EDE_CBC_SHAciphersuite 🍓 - Clarified that anonymous authentication involves a name value of zero length and a password value of zero length. The unauthenticated authentication mechanism was added to handle simple Bind requests with a name value of non-zero length and a password value of zero length 💀
B.3. Changes Made to RFC 2830 🦢
This section sums up the substantive changes made to Sections 3 and 5 of RFC 2830. For summaries of changes to other sections, readers should check [RFC4511] 📚
B.3.1. Section 3.6 ("Server Identity Check")
- Substantially updated the server identity check algorithm so it's complete and robust. In particular, the algorithm now covers all the relevant values in the subjectAltName and subjectName fields, and matching rules are specified for each type of value. Mapped (derived) forms of the server identity may now be used when the mapping is done in a secure fashion 🛡️
B.3.2. Section 3.7 ("Refresh of Server Capabilities Information")
- Clients are no longer required to always refresh information about server capabilities after TLS establishment. This allows for situations where that information was obtained through a secure mechanism ⭐
B.3.3. Section 5 ("Effects of TLS on a Client's Authorization Identity")
- Establishing a TLS layer on an LDAP session may now cause the authorization state of the LDAP session to change 🦋
B.3.4. Section 5.2 ("TLS Connection Closure Effects")
- Closing a TLS layer on an LDAP session changes the authentication and authorization state of the LDAP session based on local policy. So implementations are not required to change the authentication and authorization states to anonymous when TLS closes 🌸
- Replaced references to RFC 2401 with RFC 4301 📝
Author's Address 🖊️
Roger Harrison
Novell, Inc.
1800 S. Novell Place
Provo, UT 84606
USA
Phone: +1 801 861 2642
EMail: roger_harrison@novell.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔍
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't say it has made any independent effort to identify any such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79 💅
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the results of an attempt to get a general license or permission for implementers or users to use these proprietary rights can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🦋
The IETF invites any interested party to tell it about any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📮
Acknowledgement 🫶
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA) ✨
📦 where this page comes from
- ietf: rfc4513 2006-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms