Summary

  • RFC 3112 encoded a password-derived value as a scheme, scheme information and authentication value. Its matching rule could say TRUE, FALSE or Undefined, but that answer described a comparison—not an authenticated LDAP association.
  • The RFC explicitly required Bind for authentication. It also allowed multiple stored values, so a writer who added one accepted secret could create a second way in without disabling the user's known password.

A true answer in the wrong state machine

An LDAP client submits a password to a matching rule. The server selects a stored value, reads its scheme and salt, derives the expected result and returns TRUE. The secret matched. Yet the client is not authenticated.

That apparent contradiction is the most important sentence in RFC 3112. Published as an Informational document in May 2001, the LDAP Authentication Password Schema created a structured alternative to keeping the actual password in the userPassword form assumed by the LDAP specifications of its moment. It defined stored values, matching rules, a capability attribute and an auxiliary object class. Then, after making password testing convenient, it told clients not to treat a successful test—whether through Compare or Search—as sufficient to gain access. The Bind operation still had to be used.

Two protocol machines had answered two different questions. The matching rule answered whether one asserted string agreed with at least one stored authentication value under its declared scheme. Bind answered whether the server accepted an authentication exchange for this LDAP association. Later access control answered what the resulting authorization identity could do. An application beyond the directory still had to decide whether a requested business action succeeded.

Compress those transitions into a single “login succeeded” event and the evidence becomes unusable. A match can be logged without a Bind. A Bind can succeed while one operation remains forbidden. A permitted directory read can occur while an application transaction later fails. RFC 3112 matters because it left the seams visible.

The stored value carried its method

The schema represented each value as three case-sensitive components separated by dollar signs: scheme, authInfo and authValue. The scheme named the method. The information field commonly carried a base64-encoded salt. The final field commonly carried base64-encoded material derived from the password.

That self-description addressed a real operational problem. A directory could contain values made by different mechanisms and a server could say which mechanisms it understood. RFC 3112 defined MD5 and SHA1; private or implementation-specific mechanisms were to use an X- prefix or an assigned object identifier. The root DSE could expose supportedAuthPasswordSchemes, allowing a client or operator to discover the scheme names the server claimed to support.

But representation did not become policy merely because it was explicit. A root-DSE advertisement did not prove which scheme an authentication process selected, which entry contained which value, whether its salt was unique, whether the value had been written by an authorized actor or whether a protected channel surrounded the operation. Support was capability evidence, not an execution trace.

The distinction is sharper in hindsight. RFC 3112's MD5 and SHA-1 schemes digested a password concatenated with a salt. The salt had to be at least 64 bits, and implementations had to accept salts up to 128 bits. Those were the document's historical definitions. They are not contemporary password-storage advice. Later work made iteration count and derivation cost explicit, and RFC 9106 specified a memory-hard Argon2 function, preferring Argon2id for password hashing and password-based key derivation.

The later standards do not rewrite the 2001 record; they show why a scheme name and its parameters must be preserved rather than paraphrased as “hashed securely.”

Equality, password testing and authentication were separate

RFC 3112 defined two matching rules whose similar names conceal different evidentiary roles. authPasswordExactMatch compared the three encoded components. It returned true if one stored value carried the same scheme, information and authentication value as the asserted structured value. That was equality between representations.

authPasswordMatch accepted an asserted password through an extensible-match filter. The server applied each stored value's scheme and returned true when one or more values matched, false when all tested values failed, and undefined when it could not complete the comparison. That was a test of an asserted secret under stored instructions.

Neither answer described the identity of the human at the keyboard. A true result did not show who controlled the channel or whether the requester was entitled to test the value. False did not say whether the entry named the intended person, whether the correct scheme was selected or whether another authentication store existed. Undefined was not wrong-password evidence at all; it preserved the difference between a negative comparison and the inability to decide.

The protocol's insistence on Bind kept those uncertainties from silently acquiring more authority. LDAP Bind supplies the state transition for the association. RFC 4511 later described a successful Bind response as the authentication result, while RFC 4513 made the next distinction explicit: the authorization identity used for access decisions can be derived from the authentication identity or, with an appropriate mechanism, be a separately asserted identity that the server must permit the client to assume.

Thus even Bind success was not universal permission. Authentication answered who the server accepted for this association. Authorization answered what that identity could do to this object through this operation. The business service using LDAP still owned its own action. A password match sat at the beginning of that chain, not at its end.

Several values meant several possible doors

authPassword could hold multiple values. For a selected scheme or set of schemes, RFC 3112 advised a server to use all relevant values and consider the asserted password valid if any one matched. This could support transitions between storage schemes, overlapping credentials or administrative policy. It also made the write history security-critical.

The RFC named the attack plainly. Someone who obtained write access could store an additional value without disabling the user's true password. The victim could continue to sign in normally. A simple availability check would show no lockout and no reset. The extra credential could remain a quiet second door.

A final entry snapshot cannot reconstruct that event. It can show two values exist, not who added each one, which policy approved it, whether a password-modify operation generated it, what values were replaced, or when the server began accepting it. Evidence therefore has to follow mutations: add, replace and delete; writer identity; authorization result; value fingerprint; scheme; parameter provenance; replication; and retirement.

RFC 3062 had already defined an LDAP Password Modify extended operation. It allowed a server to identify a target under controlled rules, accept or generate a new password and choose its storage mechanism without treating an ordinary visible attribute write as the whole password lifecycle. RFC 3112 could be used with such a mechanism, but did not turn the stored field into a complete account-control system.

The server could also combine authPassword with userPassword or an external password store. Observing one attribute therefore did not establish the entire decision set. One matching value might be enough for a chosen path; its absence might not be enough to explain a failure; its removal might not revoke every other route.

A derived secret still behaved like a secret

RFC 3112 refused the comforting idea that a one-way derivation made the directory value safe to publish. It recommended protecting derived values as if they were clear-text passwords. Algorithm flaws, implementation errors and offline attacks could turn disclosure into access. Transfer of the values was strongly discouraged unless the underlying transport guaranteed confidentiality.

The same warning applied to the asserted password sent through authPasswordMatch. A matching rule carried an online guess to the server. Exposing it over an unprotected channel could disclose the password. Exposing the operation too freely could build a password oracle. The RFC instructed servers to take measures against such attacks.

Work cost added a second control problem. Some schemes can consume substantial CPU. That cost can make guessing more expensive, but it can also let untrusted clients spend the server's resources. Rate limits, concurrency budgets, timeouts and authenticated access to comparison therefore belong to the mechanism's operational meaning. A scheme can be cryptographically stronger and still be deployed with an availability failure.

This is why supportedAuthPasswordSchemes remained such narrow evidence. A server could advertise a costly or modern scheme yet select something else for one entry, accept an older overlapping value, expose comparison too broadly or fail to protect the channel. The proof required the exact request, selected values, server decision, channel state and resulting Bind—not a capability label.

The older userPassword story also changed

RFC 3112 presented authPassword against the 1997 LDAP model in which userPassword was intended for simple Bind and actual passwords were expected. That historical contrast should not be flattened into a timeless rule. RFC 4519 later revised the user-application schema and said userPassword values were not required to be clear text or even usable by Bind. Implementations and deployments developed their own tagged forms and storage behavior.

The change does not make RFC 3112 irrelevant. It makes the episode more precise. The document was one attempt to give password-derived data an explicit syntax and LDAP matching semantics at a moment when representation, authentication and directory schema were still being separated. Its enduring contribution is not the MD5 or SHA-1 construction. It is the refusal to let storage format, matching capability and session authentication collapse into one claim.

The status matters too. RFC 3112 was Informational. The RFC Editor record and IETF Datatracker establish its publication and history, not universal implementation. RFC 2251, RFC 2252 and RFC 2256 establish the protocol and schema context it addressed. RFC 2829 and RFC 4513 locate password authentication inside the wider security model. RFC 4511, RFC 4517 and RFC 4519 show the later protocol, matching and schema lineage. None of those records proves that a named directory ever enabled this schema.

What a trustworthy record would keep apart

Suppose an incident report says: “The password hash matched, so the user logged in.” RFC 3112 supplies a checklist for dismantling that sentence.

First identify the directory entry and preserve the exact stored values, including scheme names, salts or other scheme information, and creation history. Then preserve the Compare or Search request, the asserted value's protected-channel state, the access-control decision allowing the test, the result—including Undefined—and which values and schemes were actually evaluated. Next preserve the Bind request and response, the chosen authentication mechanism, the association on which it occurred, and the resulting authentication and authorization identities. Finally preserve the requested directory operation, its access-control result, and the downstream application's response.

Each record has a different custodian. Schema authors define representation. Server operators choose supported and enabled schemes. Directory writers create credential values. Authentication mechanisms establish association state. Access-control policy grants operations. Applications own business outcomes. No single successful bit can substitute for the chain.

RFC 3112's matching rule could correctly answer that a secret agreed with a stored value. Its historical sophistication was knowing when that answer had to stop. The password matched. Only Bind could say the directory had authenticated the association, and even Bind could not spend authority that the next policy had never granted.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3112.html
  2. https://www.rfc-editor.org/info/rfc3112
  3. https://datatracker.ietf.org/doc/rfc3112/
  4. https://www.rfc-editor.org/rfc/rfc2251.html
  5. https://www.rfc-editor.org/rfc/rfc2252.html
  6. https://www.rfc-editor.org/rfc/rfc2256.html
  7. https://www.rfc-editor.org/rfc/rfc2829.html
  8. https://www.rfc-editor.org/rfc/rfc3062.html
  9. https://www.rfc-editor.org/rfc/rfc4511.html
  10. https://www.rfc-editor.org/rfc/rfc4513.html
  11. https://www.rfc-editor.org/rfc/rfc4517.html
  12. https://www.rfc-editor.org/rfc/rfc4519.html
  13. https://www.rfc-editor.org/rfc/rfc8018.html
  14. https://www.rfc-editor.org/rfc/rfc9106.html