Summary

  • A valid RADIUS Change-of-Authorization or Disconnect request authenticates an accepted protocol hop. It does not by itself prove that the sender may act for the tenant, that the selectors identify exactly one current session, or that the requested change is supported by the access device.
  • A defensible control chain joins the original access and accounting record to the proxy route, NAS, live-session key, exact requested attributes, replay identity, ACK or NAK, installed policy and observed traffic. RADIUS/1.1 improves protected transport; it does not collapse those decisions into one signal.

One name, two sessions

The opening is an illustrative operations case, not a reported incident. A subscriber has a laptop on an office wireless network and a phone on a visited network. Both sessions carry the same user name. Their access servers, accounting session identifiers, attachment points and current policies differ.

A policy system decides to restrict the laptop after a risk signal. It sends a correctly protected CoA-Request containing the user name and a new filter. The receiving access system finds two active records. If it applies the filter to both, it turns a weak selector into cross-session authority. If it chooses the newest record, it invents a rule that the sender never expressed. If it rejects the ambiguous request, it preserves the boundary between a message that arrived validly and a session that has been uniquely authorized for change.

That boundary is the subject of this article. RADIUS dynamic authorization is useful precisely because it can alter a live service after the initial login. The same economy makes mistakes consequential: the device does not repeat the user's authentication ceremony before changing a filter, VLAN, rate limit or connection state. It acts on the control relationship, session evidence and local rules available at that moment.

The packet names several different objects

RFC 5176 separates the Dynamic Authorization Client, which originates a CoA-Request or Disconnect-Request, from the Dynamic Authorization Server that receives it. The receiver can be a network access server or a proxy. A NAS provides the actual service. Each instance of service is a session, and one user may hold several sessions in parallel or in sequence.

These distinctions prevent a common compression error. A RADIUS client address is not a subscriber. A NAS is not a session. A user name is not a unique current attachment. A shared secret or authenticated TLS peer names a protocol relationship, not the complete business authority behind every requested action.

Disconnect and CoA also do different work. A Disconnect-Request terminates selected session context. A CoA-Request changes authorization applicable to selected context. Disconnect is therefore not a harmless fallback when a narrower change fails. It destroys state and can interrupt work that the original decision never intended to touch.

Selection is part of authorization

The protocol permits multiple session-identification attributes. Acct-Session-Id is especially useful because it can connect the live action to an earlier accounting record. NAS port, called and calling station identifiers, assigned address information and other fields can further narrow the target. RFC 5176 recommends including User-Name or Chargeable-User-Identity for authorization protection, but neither becomes globally unique merely by appearing in the packet.

The correct question is not whether every field looks familiar. It is how many current sessions the complete selector resolves to on the receiving system. Zero matches, one match and multiple matches are different decision states. Error-Cause values such as Session Context Not Found and Multiple Session Selection Unsupported exist because ambiguity cannot be converted safely into a guessed target.

The join must also retain provenance. The accounting record that created an identifier needs its NAS, tenant or realm, user identity, start epoch and relevant assignment attributes. A session identifier copied without that context can collide after a restart, be reused on another device, or refer to state that has already ended. Local lookup is not clerical preparation for authorization. It is one of authorization's decisive checks.

Sender permission is narrower than packet validity

Historic RADIUS dynamic authorization uses the UDP source address to select a shared secret. A valid authenticator therefore shows that the packet is consistent with a configured client and secret on that hop. It does not prove that a human approved the change, that the client is entitled to act for this tenant, or that an intermediary left the request unchanged before protecting the next hop.

RFC 5176 openly describes the problem in shared access infrastructure: an organization able to send dynamic authorization to a common NAS may otherwise affect another organization's users. A reverse-path check can narrow that power by asking whether the request arrived from an authorized client for the relevant route. Per-client secrets, network filtering and protected transport further reduce unintended senders. None replaces the tenant and session decision.

RFC 8559 makes the reverse path more explicit for roaming. The home network records Operator-Name and, where supplied, an opaque Operator-NAS-Identifier created by the visited network. A later CoA follows the operator realm toward the visited network, not the user's home realm as though authentication traffic were simply running backward. The visited network resolves its opaque token to the internal NAS, removes inter-proxy signalling and sends the final locally meaningful request.

That procedure assigns useful authority without pretending it is end to end. A proxy can see and modify the RADIUS information it processes, then protect a new hop. The protocol's integrity boundary is hop by hop. The evidence record must therefore name the path and each delegated intermediary rather than attribute the final packet directly to an unseen administrator.

The requested change must remain atomic and local

A uniquely selected session can still receive an invalid instruction. A CoA may carry a filter, VLAN, rate or vendor-specific operation that the NAS does not implement, cannot apply to this access method, or is not permitted for this tenant. RFC 5176 treats attributes at the final receiver as mandatory: if a requested authorization change cannot be carried out, the NAS rejects the request rather than claiming success for an undocumented subset.

The separation between selectors and actions must remain visible. A vendor-specific attribute may serve as session identification or as the requested change, but not both simultaneously. Otherwise the value that decides who is targeted also decides what happens, making audit and safe rejection almost impossible.

Some changes require lower-layer renegotiation. A new address or service property cannot become real merely because it fits inside a RADIUS attribute. Device type, access protocol and running implementation decide whether the operation is supported. Running code is the final compatibility witness: a broad controller catalogue cannot create a capability in a NAS that does not have it.

Retransmission is not a second decision

Dynamic authorization commonly uses a request-and-response exchange over a transport where loss and retry are possible. In historic UDP operation, an unchanged retry to the same server retains the source port, Identifier and Request Authenticator. If attributes change, the sender creates a new request identity. The receiver must detect duplicates over the relevant interval.

Where IPsec replay protection is absent, RFC 5176 recommends Event-Timestamp. Both sides compare it with an accepted freshness window, and a stale packet is discarded. Retransmission keeps the original timestamp. The duplicate-detection window and timestamp window therefore need the same boundary; otherwise a packet may be fresh enough to accept after the receiver has forgotten that it already executed it.

Freshness is useful but modest evidence. Event-Timestamp is not the time a manager approved a ticket, not a proof that the intended session still exists, and not an end-to-end signature over business context. It answers when the original protocol request was sent within the cooperating clocks' tolerance.

Response caching creates another audit trap. A server may return the cached ACK or NAK for a duplicate. Two received ACKs can then describe one execution. Counters should distinguish original requests, retransmissions, duplicates suppressed, cached responses and independent later decisions.

What RADIUS/1.1 changes—and what it leaves alone

RFC 9765 defines RADIUS/1.1 through ALPN name radius/1.1 and requires TLS 1.3 or later. When both peers negotiate it, TLS supplies connection authentication, confidentiality and integrity. Historic Request and Response Authenticator calculations are no longer used, and Message-Authenticator no longer authenticates a RADIUS/1.1 packet.

A four-octet Token replaces the old Identifier for matching requests with replies. New packets on a connection receive new Token values. An unchanged DTLS retransmission retains its Token, and duplicate handling is scoped to the connection. The same value on another connection is a different event.

This is a significant transport correction. It removes dependence on historic MD5-based packet protection for this mode and makes version choice explicit. It does not redefine the CoA and Disconnect packet codes, select a subscriber session, authorize a tenant crossing, or prove a filter reached hardware. Most application attributes retain their meaning.

Migration should therefore use two ledgers. The transport ledger records peer certificate validation, ALPN result, TLS version, connection identity and Token behavior. The authorization ledger records realm, NAS, tenant, session selector, requested change, local decision and effect. A green first ledger cannot be used to fill gaps in the second.

ACK is testimony, not the whole effect

CoA-ACK means the NAS reports successful change. CoA-NAK and Error-Cause explain a class of refusal. Those responses are indispensable, but the final proof sits beyond them.

The operator should compare pre-change and post-change live-session state, installed filters or VLAN, rate policy, accounting continuity and representative traffic. A correct ACK with unchanged device state is an enforcement defect. A changed session with a lost response is a transport-observation defect. A NAK after partial mutation is an atomicity defect. Combining them into a generic “CoA failed” alert loses the component that must be repaired.

The minimum evidence chain is: original access and accounting event; current session inventory; authorized sender and proxy path; exact request bytes or a privacy-safe fingerprint; request identity, Token and timestamp; selector cardinality; local capability and policy decision; ACK or NAK; installed state; observed packets; and a scoped reversal record. Each link answers a different question.

A bounded operational test

Build two simultaneous test sessions that deliberately share a tempting identifier while retaining distinct accounting session identifiers and NAS context. Send a narrow, authorized CoA that names exactly one. Prove that the selected policy changes, traffic follows it and the other session remains untouched.

Then remove the distinguishing field. The request should be rejected as ambiguous, not resolved through newest-session preference or incidental database order. Repeat the original packet and prove the effect is not executed twice. Send a stale timestamp, a request from the wrong authorized realm, an unsupported action and a packet routed to the wrong NAS. Each should fail at a named boundary with evidence that does not expose subscriber secrets.

Finally, exercise rollback as a scoped reverse authorization change using captured prior state. Do not call Disconnect a rollback unless termination was the original approved outcome. The safe test is not merely that a positive case works. It is that every nearby wrong authority is refused without touching the protected session.

Sources