Summary

  • RFC 4422 separates the identity proved by credentials from the identity a client asks to act as; the server must validate both the credentials and that act-as relationship.
  • A successful SASL exchange can establish session state or a security layer, but the application protocol and local policy still decide what the identity may do next.

The dangerous comfort of a green result

Authentication systems tend to compress their answer for human consumption. A protocol emits success, an interface shows a check mark, and an audit log records a principal. Each is useful. Together they invite a larger inference: if the system knows who is present, the person must be entitled to the service. RFC 4422 refuses that compression.

SASL is a framework between connection-oriented application protocols and replaceable authentication mechanisms. That middle position matters. A mechanism can describe how credentials are tested. An application protocol can describe how the exchange is carried and how the resulting identity affects its state. Neither component can silently inherit all the policy of the other.

The result is an intentionally modest success. It may mean that the exchange completed and the server accepted the requested identity relationship. It may also activate a negotiated data-security layer. It does not mean that every mailbox, command, dataset or administrative function has become available. A later denial may be the system working correctly.

One exchange, two identities

The sharpest line in the framework is the distinction between an authentication identity and an authorization identity. The first is associated with the credentials: the identity whose secret, certificate, ticket or other material is being verified. The second is the identity the client asks to act as.

Those identities often coincide, which is why the distinction is easy to miss. If a client leaves the authorization-identity string empty, it asks to act as the identity the server associates with the credentials. But SASL also accommodates delegation and proxy authorization. A process can authenticate as one principal while requesting authority to operate as another.

The server therefore has two checks to make. It must verify the credentials and determine the authentication identity. It must separately decide whether that identity may act as the requested authorization identity. Failure of either check makes the exchange fail. This is not semantic fussiness. It prevents valid credentials from becoming an automatic delegation instrument.

Even the accepted authorization identity is narrower than it sounds. It is an identity in the application protocol's authorization state, not a universal bundle of permissions. The right to assume a name does not itself enumerate the actions, resources, quotas or conditions attached to that name.

The application profile carries the missing meaning

SASL does not pretend that one framework can dictate the identity model of every protocol. RFC 4422 requires each application profile to specify how mechanisms are offered and selected, how challenges and responses travel, what non-empty authorization identities mean, when a security layer begins, how other layers are ordered, and what repeated authentication does to existing state.

That division makes replaceability possible. A protocol can adopt a newer mechanism without redesigning every application message. A mechanism can improve credential resistance without learning the semantics of mailboxes, directories or collaborative rooms. The price of that modularity is an obligation: implementers and operators must not treat the seam as if it contained policy that was never specified.

Local mapping remains important too. The character string seen on the wire may be normalized, mapped to an internal principal, connected to groups and then evaluated against a resource rule. A clean SASL transcript cannot by itself prove that every one of those mappings is current or correct.

SMTP shows the boundary without dissolving it

SMTP AUTH offers a precise example. RFC 4954 assigns 235 2.7.0 Authentication Succeeded to the successful AUTH command. The result associates an authorization identity with the SMTP session. It says what happened to that command and that session; it is not a receipt for a later message.

The distinction becomes especially visible when the exchange negotiates a security layer. SMTP state is reset, earlier capability knowledge is discarded, and the client should issue EHLO again. A green authentication result can therefore be followed by a deliberate return to an earlier application state. The protocol still has more work to do.

Mail acceptance, relay policy, recipient checks, content controls, queues and final delivery sit beyond that one reply. This article is not using SMTP to relitigate delivery semantics. The narrower point is that an application profile turns SASL state into one input among several, not into an all-purpose outcome code.

The framework can authenticate nobody

RFC 4505 makes an even more revealing contrast. Its ANONYMOUS mechanism deliberately lets a user gain restricted access without establishing or disclosing an identity. Optional trace information may accompany the login, but the specification warns that the trace string is not authenticated and can be falsified.

So the mere presence of a named SASL mechanism and a completed exchange tells an analyst too little. One must ask what that mechanism claims, which identity—if any—it establishes, and what restrictions the application applies. A log parser that turns every SASL success into “verified user” destroys information the standards carefully preserved.

Stronger proof does not write the policy

RFC 7677 later registered SCRAM-SHA-256 and SCRAM-SHA-256-PLUS. It strengthened a replaceable part of the authentication exchange by using SHA-256 and addressing channel-binding conditions. That is real security improvement. It still does not decide who may read a particular mailbox or issue a privileged command.

This distinction is useful during upgrades. Replacing a weak mechanism can reduce credential exposure, replay or channel-confusion risk. It cannot repair an overbroad group assignment, a stale proxy rule or an application that confuses session identity with resource entitlement. Cryptographic assurance and authorization correctness meet at the decision point, but they are not substitutes.

What evidence should accompany “success”

An operator investigating a disputed action needs more than the final SASL outcome. The useful record includes the mechanism selected, whether channel binding or a security layer applied, the authentication identity after server-side mapping, the requested and accepted authorization identity, the policy decision that permitted the act-as relationship, and the later application authorization result.

These fields should remain distinguishable. If a product stores only a single “user” value, incident responders may be unable to tell whether credentials were stolen, delegation was too broad, identity mapping was stale, or a resource policy granted too much. A concise success flag is good protocol machinery and poor forensic completeness.

For user interfaces, the same restraint applies. “Signed in as” can truthfully describe session identity. “You can access” requires an authorization decision about a concrete resource or operation. Blurring those phrases teaches users to interpret identity proof as permission—and makes later denials look like bugs rather than policy.

Sources