Summary

  • RFC 5387 allowed authentication to be asymmetric across network and application layers, but required channel binding at both endpoints. The direction of trust and the topology of verification are different design choices.
  • Without bilateral binding, a forwarding proxy can concatenate two separately protected IPsec security associations. Each leg may be encrypted and internally valid while the supposed end-to-end peer relationship is false.

The room with two green locks

Imagine an incident review in which both operators bring persuasive evidence. The client team shows that its IPsec security association negotiated successfully. The server team shows the same. Packets on each leg had integrity protection. No unprotected fallback appeared in the trace. Every local dashboard displays a green lock.

Then the packet capture reveals three machines, not two. An on-path system terminated one association from the client and created another to the server. It relayed the higher-layer exchange between them. Neither local IPsec check was necessarily wrong. What failed was the unrecorded inference that two protected legs constituted one protected channel between the intended application endpoints.

RFC 5387, published in 2008 as an Informational description of Better-Than-Nothing Security, names this compositional problem with unusual precision. An IPsec security association ends at the network-layer peer that created it. The application session has its own endpoints. If those layers are meant to act as one channel, the application needs evidence that its peer relationship is bound to the exact lower-layer security association it is using.

The distinction matters far beyond IPsec. Organizations routinely accept local proofs and silently promote them into system-wide conclusions. A supplier signed an artifact; therefore the deployed binary must be that artifact. Two registries contain the same name; therefore they refer to the same legal object. Two services mutually use TLS; therefore a message preserved its principal across a broker. Each conclusion needs a join receipt. Otherwise the controls are green on both sides of a gap.

Authentication direction is a policy choice

Not every service authenticates both parties in the same way. A public server may prove its identity while accepting anonymous clients. A storage system may authenticate a user at the application layer while the server presents a network-layer credential. A protocol can authenticate one direction at one layer and the opposite direction at another.

RFC 5387 explicitly described symmetric and asymmetric modes. Stand-Alone BTNS could omit conventional IKE authentication at both ends or at only one. Channel-Bound BTNS could then join higher-layer authentication to those network-layer associations. In an asymmetric CBB case, one-way client authentication above IP might be complemented by server authentication in IKE. The result could amount to mutual authentication, but the two directions would be established at different layers.

That architecture is not automatically incoherent. It may match the identities that each layer can actually understand. The application knows users, accounts or service principals. IKE knows the credentials and identifiers available to IPsec policy. Forcing both layers to repeat the same authentication can create additional configuration, repositories and failure modes without adding an independent decision.

The danger begins when the deliberate asymmetry of authentication is used to justify asymmetric evidence about the channel. RFC 5387 draws the opposite line: authentication can be one-way, but channel binding must be applied at both ends to prevent a man-in-the-middle attack. Both endpoints have to exchange and verify the binding values. One party's assertion that it saw a protected channel does not prove what the other party saw.

Authority direction and evidence topology are separate. A one-way door can be legitimate. The audit of which doorway both parties used must still reconcile on both sides.

Two secure associations can compose into a false channel

IPsec can provide confidentiality, integrity, anti-replay protection and other services for packets carried by an SA. Those guarantees are scoped to that association. They do not, by themselves, name the higher-layer peer or prove that one SA observed at one endpoint is the same end-to-end relationship observed at the other.

RFC 5387's forwarding-proxy example exposes the gap. An attacker establishes SA A with the client and SA B with the server. It decrypts traffic arriving on one association, forwards the higher-layer bytes, and protects them again on the other. The client sees a valid SA to the proxy. The server sees a valid SA to the proxy. If application authentication is simply passed through, the application principals may even authenticate successfully to each other while the intermediary retains access to the traffic.

The attack is not refuted by saying that both SAs used strong algorithms. Strong encryption can protect the wrong boundary perfectly. Nor is it refuted by showing two successful handshakes. The disputed claim is the join: that the higher-layer client and server share one lower-layer channel without an intermediary.

Channel binding supplies evidence for that join. RFC 5387 describes incorporating information from SA creation that uniquely identifies an SA pair into higher-layer authentication. RFC 5056 generalizes the model: application peers verify that they observe the same channel-binding data. If a proxy has created two separate lower-layer channels, the values differ and the bound authentication fails.

This is why a generic label such as “IPsec protected” is insufficient evidence. The receipt needs to identify the channel instance, not merely the technology. A certificate, IP address or protocol name can remain the same across multiple channels. Later channel-binding work for TLS likewise distinguishes values with precise uniqueness properties. A category is not an instance.

A connection latch makes the promise operational

RFC 5387 did not treat a channel as a one-time handshake screenshot. It described an IPsec channel as a packet flow whose peer identity and quality of protection remain the same for the flow's lifetime. Connection latching associates the higher-layer connection with those security properties.

RFC 5660 later standardized this idea more concretely. A latch watches Security Policy Database and Security Association Database changes that could violate the application's original requirements. Its required parameters include the type of protection, transport or tunnel mode, quality of protection, local identity and peer identity. If the latch can no longer be maintained, the upper layer needs a synchronous warning and a decision before traffic silently continues under different conditions.

That is a richer control than “encryption enabled”. It turns a negotiated state into an invariant. The application can state that this flow must continue with the same peer and an acceptable protection class. Rekeying may replace the underlying SA without breaking the channel, but the transition must preserve the latched properties. A change is not harmless merely because a replacement SA also negotiated successfully.

The same reasoning applies to organizational workflows. If an approval moves from a ticket to a deployment, latch the principal, artifact digest, environment, permission scope and policy version. When one property changes, either prove an authorized transition or stop. A green replacement record must not inherit the old record's authority by visual similarity.

Detection can be correct and still be late

Channel-Bound BTNS changes when an intermediary is detected. With fully authenticated IKE, the attacker should fail during creation of the network-layer association. With CBB, unauthenticated IKE can succeed and SAs can be created. The mismatch emerges later when higher-layer authentication checks the channel binding.

That later failure is valuable. It prevents the system from accepting the proxy as the intended end-to-end channel. But RFC 5387 refuses to turn detection into a claim that nothing happened. Before the failure, the endpoint may have spent CPU and memory, allocated state and sent authentication messages. If the higher-layer method exposes passwords or password-derived material suitable for offline attack, detecting the proxy after disclosure is not an adequate design.

The acceptance question therefore has two parts. Did the binding fail when it should? What was exposed or consumed before it failed? A system that passes the first test can still fail the second.

For operators, this means resource limits and credential design belong to the channel-binding review. Unauthenticated association creation should have bounded cost. Higher-layer authentication should avoid revealing reusable or offline-testable secrets to an untrusted endpoint. Increased privileges should arrive only after the binding succeeds. Logs should distinguish “network association created” from “application channel authenticated”.

Executives often prefer one status light. The protocol has at least three states: protected association established, channel binding verified, application principal authorized. Collapsing them conceals the period in which cryptography is active but identity and composition remain unresolved.

Rekey is a transfer of evidence, not merely fresh keys

Every SA has a lifetime. Time or byte limits eventually cause replacement or termination. RFC 5387 notes that rekeying opens a small opportunity for an on-path attacker to step into the new association, especially when Stand-Alone BTNS removes conventional peer authentication.

The operational mistake is to treat the new SA as a routine continuation because it protects the same addresses or carries the same flow. Continuity of association is only invariant inside one SA unless another mechanism proves the transition. Connection latching and channel binding can provide that mechanism, but the higher layer must verify consistency of identities and authentication across the old and new associations.

This does not mean every rekey should interrupt an application. It means uninterrupted service must be an outcome supported by evidence, not the assumption that hides the transition. The receipt should name the old channel, new channel, preserved latch properties, binding verification, transition time and failure action.

The leadership analogue is succession. A new credential, vendor, registry operator or automated agent can inherit a task without automatically inheriting every authority claim attached to its predecessor. Preserve the invariant explicitly. Where the invariant cannot be proved, narrow the authority or require a new decision.

The bilateral test

A serious acceptance test starts with three hosts: an application client, an application server and a controlled forwarding proxy. Establish an honest direct session first. Capture the channel-binding value observed at each endpoint, the higher-layer authentication result and the latched peer and protection properties. Both endpoints should verify the same channel fact.

Next split the path. Let the proxy establish one valid IPsec association with the client and another with the server, then forward the higher-layer exchange. Do not weaken the algorithms. Do not inject malformed packets. The point is to show that two cryptographically healthy legs are still the wrong topology. Bound authentication must fail because the endpoints do not observe the same lower-layer channel.

Repeat the test with server-only authentication, client-only authentication, authentication at both ends and authentication divided across layers. The identity result may change by policy; the requirement for bilateral binding verification must not.

Then rekey during a long-lived flow. Preserve all required properties once and prove that the application continues. In a second run, change the peer identity or protection quality and verify that the latch breaks before further application data is accepted. Restart the higher-layer session and check that per-session channel binding runs again. If cross-session spoofing is in scope, test the cached latch rather than assuming it exists.

Record the negative path as carefully as success: which endpoint detected the mismatch, which state was destroyed, what application error surfaced, how much data crossed first and whether an operator can distinguish a binding failure from an ordinary login rejection.

The receipt that joins controls

RFC 5387 offers a compact rule for system design: never borrow an end-to-end conclusion from component-level success. Name the boundary each control protects. Where boundaries meet, create a separate evidence object for the join.

For a bound channel, that object contains the exact lower-layer channel identifier, the higher-layer session and endpoints, authentication direction, verification decision at both ends, latched protection properties and transition history. For a software supply chain, it may join source approval to a build digest and deployment identity. For a registry, it may join an operator instruction to the exact resource and publication event. For an AI workflow, it may join a principal, delegated scope, model action and external effect.

The join should fail closed when one side has no value, when values disagree or when the property changes without an authorized transition. Logging “binding supported” is not enough. Support is capability; a receipt proves execution.

This is the institutional lesson in Heng Lu's distinction between a bookkeeper and an authority. A component can maintain a useful local record without gaining power to declare the whole relationship true. The end-to-end claim belongs to the principals and the evidence that connects them, not to whichever intermediary operates the most impressive lock.

Sources