Which three simple-bind mechanisms does RFC 4513 separate, and why is an unauthenticated bind the dangerous one?

middlemust knowfreq 50%

answer

three, not two
count the length of both fields
the middle one proves nothing
empty password, non-empty name
a SHOULD, not a prohibition

basics

~20 s

RFC 4513 separates three mechanisms of simple bind by the lengths of two fields: anonymous (zero-length name and password), unauthenticated (a DN with a zero-length password), and name/password. The unauthenticated one can return success (0) for a DN nobody proved.

solid answer

~50 s

A simple bind is not one mechanism but three, and RFC 4513 tells them apart purely by the lengths of name and the simple [0] value. Zero and zero is the anonymous authentication mechanism: the client claims nothing. Non-zero and non-zero is the name/password authentication mechanism: a bind DN and that entry's password. Between them sits the unauthenticated authentication mechanism — a real DN with a zero-length password — which proves nothing at all and can still be answered success (0). That is the dangerous one: a shop-floor terminal whose password field came back empty sends the operator's DN with nothing after it, and a caller that checks only the result code records a successful login for a person who typed nothing. RFC 4513 says servers SHOULD by default fail such requests with unwillingToPerform (53) — a SHOULD, not a protocol-level prohibition.

A simple bind is not one mechanism but three, and RFC 4513 tells them apart purely by the lengths of `name` and the `simple [0]` value. Zero and zero is the **anonymous authentication mechanism**: the client claims nothing. Non-zero and non-zero is the **name/password authentication mechanism**: a bind DN and that entry's password. Between them sits the **unauthenticated authentication mechanism** — a real DN with a zero-length password — which proves nothing at all and can still be answered `success (0)`. That is the dangerous one: a shop-floor terminal whose password field came back empty sends the operator's DN with nothing after it, and a caller that checks only the result code records a successful login for a person who typed nothing. RFC 4513 says servers **SHOULD** by default fail such requests with `unwillingToPerform (53)` — a SHOULD, not a protocol-level prohibition.

code

pseudocode · 15 lines

pseudocode

function classify_simple_bind(request)
    name_len = length(request.name)
    pass_len = length(request.simple)          -- the simple [0] octet string

    if name_len = 0 and pass_len = 0
        return "anonymous authentication mechanism"

    if name_len > 0 and pass_len = 0
        return "unauthenticated authentication mechanism"

    if name_len > 0 and pass_len > 0
        return "name/password authentication mechanism"

    -- a zero-length name with a password is none of the three
    return "reject"

go deeper

for a junior

Recall that a simple bind carries a DN and a password, and that both fields can legitimately be empty. Knowing that an empty password is a separate case, not automatically a failure, is the takeaway.

for a middle

Explain the classification by field lengths and name all three mechanisms. Be able to say why the unauthenticated one can return success (0) and what a client must check beyond the result code.

for a senior

Demonstrate the diagnosis: a login path reporting success for an empty password, identical client code behaving differently against two directories, and the client-side guard that makes the request unbuildable.

for a principal

Weigh leaving the unauthenticated mechanism enabled for legacy callers against turning it off estate-wide, and say how you would find every client that depends on it before you do.

Three mechanisms wearing one name

"Simple bind" sounds like a single thing: put a DN in name, put a password in simple [0], send it. RFC 4513 splits it into three distinct authentication mechanisms, and the whole distinction is carried by the lengths of those two fields — there is no separate flag on the wire saying which one you meant.

mechanism	`name`	`simple [0]` value	what a `success (0)` proves
anonymous authentication mechanism	zero length	zero length	nothing; the client asked for no identity
unauthenticated authentication mechanism	non-zero (a DN)	zero length	nothing, although a DN was named
name/password authentication mechanism	non-zero (a DN)	non-zero	the client presented that entry's password

The first and third are unsurprising. The second is the one interviews are really asking about, because it is the only place in the protocol where the request looks like an authentication and the outcome is not one.

Why the middle row is dangerous

Consider a press-operator shift directory reached from three places: shop-floor terminals, a shift-planning service, and a night supervisor's laptop. A terminal collects a name and a password, maps the name to a DN, and sends a simple bind. Now suppose the password field is empty — the operator pressed enter early, a keypad was unplugged, a form serialised a missing value as an empty string. The terminal sends a real DN with a zero-length password. If the directory answers success (0), a caller that checks only the result code has just recorded a successful login for a person who proved nothing.

The failure has three properties that make it survive review:

It is invisible in the client's own logic. No branch was skipped and no exception was thrown; the bind was answered successfully.
It is invisible in the wire shape. The request is a well-formed BindRequest with a valid DN. Only the length of one octet string distinguishes it.
It depends on the server, not the client. Whether it succeeds is a directory-side policy decision, so the same client code behaves differently against two deployments.

What the specification actually says — and does not

This is the part to state precisely, because overstating it is itself a defect. RFC 4513 is explicit about the risk and recommends against it in both directions:

Clients SHOULD be built so that a user cannot select this mechanism merely by leaving a password box empty, and SHOULD disallow an empty password in a name/password interface.
Servers SHOULD by default fail a bind of the unauthenticated mechanism, and the specification names unwillingToPerform (53) as the result code for it.

Both are SHOULD, not MUST NOT. There is no protocol-level prohibition: a conforming directory may accept an unauthenticated bind, and some deployments do, deliberately, because something old depends on it. An answer that says "the protocol forbids it" teaches a false certainty and will be corrected by anyone who has read the section. The honest statement is: the specification warns about it, recommends that servers disallow it by default, and leaves the door open.

What the anonymous mechanism is for

The first row is not a defect; it is a deliberate way to say "I am nobody". A client uses it to read what an unauthenticated caller may read — the supportedSASLMechanisms a server advertises, for instance, before deciding how to authenticate properly. It is also how a client discards an identity on a live session, since receipt of any BindRequest resets the session's state.

Note that this is a third distinct meaning of "anonymous" in a single area, and they are worth keeping apart:

the anonymous authentication mechanism of simple bind — the zero/zero request above;
the unauthenticated authentication mechanism — a DN with no password, which is not the same thing, though both leave the caller unproven;
SASL ANONYMOUS — a named SASL mechanism, selected through sasl [3], not through the simple choice.

Defending against the middle row

The protocol-side defences are short and worth naming in an interview:

Reject before sending. A client that refuses to build a simple bind with a non-empty name and a zero-length password can never produce the request at all.
Do not trust the result code alone. success (0) answers "was the request processed", not "which mechanism was it". The client knows which mechanism it sent; it should check that too.
Prefer a mechanism where the empty case is not representable. A SASL mechanism named through sasl [3] has no equivalent slip, because there is no field whose emptiness silently reclassifies the request.

And one limit, said once: a name/password simple bind on an unprotected connection sends that password in the clear, because simple [0] is an octet string with nothing over it.

## Three mechanisms wearing one name "Simple bind" sounds like a single thing: put a DN in `name`, put a password in `simple [0]`, send it. RFC 4513 splits it into **three distinct authentication mechanisms**, and the whole distinction is carried by the lengths of those two fields — there is no separate flag on the wire saying which one you meant. | mechanism | `name` | `simple [0]` value | what a `success (0)` proves | |---|---|---|---| | anonymous authentication mechanism | zero length | zero length | nothing; the client asked for no identity | | unauthenticated authentication mechanism | non-zero (a DN) | zero length | nothing, although a DN was named | | name/password authentication mechanism | non-zero (a DN) | non-zero | the client presented that entry's password | The first and third are unsurprising. The second is the one interviews are really asking about, because it is the only place in the protocol where **the request looks like an authentication and the outcome is not one**. ## Why the middle row is dangerous Consider a press-operator shift directory reached from three places: shop-floor terminals, a shift-planning service, and a night supervisor's laptop. A terminal collects a name and a password, maps the name to a DN, and sends a simple bind. Now suppose the password field is empty — the operator pressed enter early, a keypad was unplugged, a form serialised a missing value as an empty string. The terminal sends a **real DN with a zero-length password**. If the directory answers `success (0)`, a caller that checks only the result code has just recorded a successful login for a person who proved nothing. The failure has three properties that make it survive review: 1. **It is invisible in the client's own logic.** No branch was skipped and no exception was thrown; the bind was answered successfully. 2. **It is invisible in the wire shape.** The request is a well-formed `BindRequest` with a valid DN. Only the length of one octet string distinguishes it. 3. **It depends on the server, not the client.** Whether it succeeds is a directory-side policy decision, so the same client code behaves differently against two deployments. ## What the specification actually says — and does not This is the part to state precisely, because overstating it is itself a defect. RFC 4513 is explicit about the risk and recommends against it in both directions: - **Clients** SHOULD be built so that a user cannot select this mechanism merely by leaving a password box empty, and SHOULD disallow an empty password in a name/password interface. - **Servers** SHOULD by default fail a bind of the unauthenticated mechanism, and the specification names `unwillingToPerform (53)` as the result code for it. Both are **SHOULD**, not MUST NOT. There is no protocol-level prohibition: a conforming directory may accept an unauthenticated bind, and some deployments do, deliberately, because something old depends on it. An answer that says "the protocol forbids it" teaches a false certainty and will be corrected by anyone who has read the section. The honest statement is: *the specification warns about it, recommends that servers disallow it by default, and leaves the door open.* ## What the anonymous mechanism is for The first row is not a defect; it is a deliberate way to say "I am nobody". A client uses it to read what an unauthenticated caller may read — the `supportedSASLMechanisms` a server advertises, for instance, before deciding how to authenticate properly. It is also how a client **discards** an identity on a live session, since receipt of any `BindRequest` resets the session's state. Note that this is a third distinct meaning of "anonymous" in a single area, and they are worth keeping apart: - the **anonymous authentication mechanism of simple bind** — the zero/zero request above; - the **unauthenticated authentication mechanism** — a DN with no password, which is *not* the same thing, though both leave the caller unproven; - **`SASL ANONYMOUS`** — a named SASL mechanism, selected through `sasl [3]`, not through the simple choice. ## Defending against the middle row The protocol-side defences are short and worth naming in an interview: - **Reject before sending.** A client that refuses to build a simple bind with a non-empty `name` and a zero-length password can never produce the request at all. - **Do not trust the result code alone.** `success (0)` answers "was the request processed", not "which mechanism was it". The client knows which mechanism it sent; it should check that too. - **Prefer a mechanism where the empty case is not representable.** A SASL mechanism named through `sasl [3]` has no equivalent slip, because there is no field whose emptiness silently reclassifies the request. And one limit, said once: a name/password simple bind on an unprotected connection sends that password in the clear, because `simple [0]` is an octet string with nothing over it.

Does LDAP forbid the unauthenticated authentication mechanism of simple bind?
No. RFC 4513 warns about it, says clients SHOULD NOT let an empty password produce one, and says servers SHOULD by default fail it with `unwillingToPerform (53)`. Those are SHOULDs. A conforming directory may accept an unauthenticated bind, which is precisely why the defect keeps reappearing in clients that assume it cannot.
What does a caller actually get after an anonymous simple bind?
An anonymous authorization state on that session — the same state it had before binding. `success (0)` reports that the request was processed, not that anything became readable; what the session may see is still decided per entry and per attribute when each later request runs.
Why can a client not tell the three mechanisms apart from the response alone?
Because the response carries a result code, not the mechanism. All three can be answered `success (0)`, and nothing in a `BindResponse` echoes which field lengths the request had. The client is the only party that knows which mechanism it sent, so it is the party that must check.

saying these in an interview costs you the question

Treats an anonymous bind and an unauthenticated bind as the same thing
Says an empty password always makes a simple bind fail
Claims RFC 4513 forbids the unauthenticated mechanism outright
Reads success (0) as proof the named DN was authenticated
Thinks a zero-length name with a password is the anonymous form
Assumes the response tells the client which mechanism it used

Which three simple-bind mechanisms does RFC 4513 separate, and why is an unauthenticated bind the dangerous one?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Three mechanisms wearing one name

Why the middle row is dangerous

What the specification actually says — and does not

What the anonymous mechanism is for

Defending against the middle row

▾common follow-ups3 questions

▾red flags6 flags

Three mechanisms wearing one name

Why the middle row is dangerous

What the specification actually says — and does not

What the anonymous mechanism is for

Defending against the middle row

answer

go deeper