Summary

  • RFC 9813 makes PSK Identity the lookup key for a TLS-PSK RADIUS client relationship, but the identity arrives in cleartext from a peer that has not yet proved possession of the corresponding secret. It selects a candidate record; it is not authentication.
  • A defensible client receipt keeps source-range admission, identity validation, client-table generation, PSK verification, RADIUS-layer integrity, per-client policy, resumption context and delivered network access as joined but separate states.

The old RADIUS client table had a simple key. A packet arrived from an IP address. The server used that address to find a client definition, recovered the associated shared secret and checked the packet. The address did two jobs at once: it located the relationship and helped describe where the request was permitted to originate.

That model becomes ambiguous when addresses move or are shared. A branch appliance may obtain a different address. Several access controllers may sit behind one NAT gateway. Two independent clients can therefore appear under one public address, while one client can appear under several addresses over time. An IP address still helps bound exposure. It no longer names the relationship precisely enough.

RFC 9813, published in July 2025 as Best Current Practice 243, addresses that transition for RADIUS over TLS and DTLS. Its operational move is easy to state: with TLS-PSK, the PSK Identity replaces source IP as the client identifier, and the PSK replaces the old shared secret as proof of TLS-layer authenticity and shared trust. The difficult part is everything the word “replaces” does not erase.

The source address remains a filter. The identity remains untrusted until the secret is verified. The TLS PSK remains distinct from the RADIUS shared secret used by the encapsulated protocol. The selected client record can carry local permissions. A completed TLS handshake still does not say that the RADIUS request was authorized, that a network access server executed the result or that a user received the intended service.

RFC 9813 is therefore not merely guidance on choosing a stronger secret. It is a design for moving a lookup key without moving all authority into that key.

The old client table used the address as the key

The document describes the conventional RADIUS/UDP arrangement as a logical client table. Each client definition includes at least a source IP address and a shared secret. The incoming address selects the row. The secret then authenticates the RADIUS packet. Site-local policy can hang from the same row: one client may be a Wi-Fi access point, another a VPN concentrator; one may send accounting requests that another is not permitted to send.

This is already more than a password file. The table is a relationship map. It says which peer may arrive from where, which credential proves the relationship and which application behavior belongs to it.

The limitations are structural. If source address is the primary key, NAT compresses several relationships into one visible value. Dynamic addressing makes a stable relationship appear to change identity. A wide address range can restore reachability but weakens the precision of the selector. Copying one client row for every possible address creates administrative state that quickly drifts.

TLS does not make those facts disappear. It gives the server a different candidate selector and a cryptographic proof, while the network location remains useful as an independent constraint.

The new selector arrives before authentication

A PSK Identity is not the PSK. It is the handle that tells a server which candidate secret and policy record to try. That ordering is unavoidable: before the server can verify the secret, it must know which secret is relevant.

The client sends that handle in the TLS exchange. RFC 9813 emphasizes two consequences. First, the identity is visible in cleartext, so a meaningful username can disclose affiliation. An opaque user portion, possibly arranged as a Network Access Identifier, can reduce unnecessary disclosure. Second, the peer supplying the value is still unauthenticated. A syntactically plausible identity can be invented by anyone who can reach the listener.

This distinction is the heart of the mechanism. A found row proves only that the selector matched stored state. It does not prove that the sender owns that row. PSK verification supplies the next receipt. Source-range policy supplies another. The relationship becomes acceptable only when all required checks agree.

An operations dashboard that records “known identity” as “authenticated client” has moved the old source-IP mistake into a new column. It has mistaken address-book success for proof.

Validate before the identity touches another system

RFC 9813 treats the raw identity as hostile input. It may be malformed UTF-8, contain embedded NUL octets, carry metacharacters meaningful to SQL, LDAP, REST or a shell-backed tool, or exploit an implementation willing to accept the TLS maximum of 65,535 octets. Passing it directly to a database query turns a protocol selector into an attack surface.

The safe pipeline is narrow. Bound the length. Classify the identity namespace. Validate the configured representation. Escape values for the actual lookup interface or reject them. Close the TLS connection when validation fails. Only then may the normalized value select a candidate client row.

Normalization must not silently merge two administrative identities. If preparation rules change case, Unicode form or display representation, the stored canonical form and comparison rule need a version. Otherwise a software upgrade can alter which row a string selects without changing the visible configuration. The receipt should preserve the raw input hash, validation result, normalized lookup value, rule version and selected record identifier.

Logging also needs restraint. The raw value may contain sensitive affiliation and malicious bytes. A useful rejection record can retain bounded hashes, reason codes, observed source range and parser generation without copying an attacker-controlled string into every downstream log and alert system.

The client table is a relationship record

RFC 9813's logical TLS-PSK table can bind allowed network ranges, PSK Identity, the associated PSK, alternative TLS credentials and flags requiring client certificates. The existing RADIUS client policy still matters after the TLS layer succeeds.

That makes the row closer to a contract than to a global identity. The same appliance may have a different relationship with two RADIUS servers. A failover pair may share some policy and keep separate secret material. A service operator may decide that one class of client can send accounting messages but cannot originate another request type. The identifier should point to the particular client-server relationship whose secret and policy are being tested.

This is why RFC 9813 requires implementations to support a unique PSK and identity for every possible client-server relationship, even if local policy chooses reuse. Uniqueness is not decorative hygiene. It makes compromise revocable at the edge of one relationship, lets last-seen evidence identify a dormant client and prevents one secret from becoming an invisible trust group.

The shared layer can require the capability. Local administrators decide the topology and rotation cost. That is a useful instance of Minimum Initial Specification: strict common mechanics without pretending that a standards document knows every operator's maintenance window or device estate.

NAT and mobility separate address from client

RFC 9813 still requires an allowed network-range check before the server examines a PSK Identity. Traffic from outside all configured ranges is rejected early. After selecting a client record, the server can perform a second address check against the ranges allowed for that particular relationship.

Those are different filters. The first protects the listener and TLS stack from unnecessary exposure. The second asks whether this authenticated relationship is permitted from the observed location. A global range can overlap several client ranges without making them the same policy.

Within those bounds, servers must support multiple PSK identities at one source address and one identity appearing from different addresses. The address has not become irrelevant; it has become one coordinate instead of the primary name.

That division matters in investigations. A successful network-range check says the connection originated inside an allowed prefix as observed by the server. It does not identify the client behind NAT. A successful PSK check says the peer possessed a symmetric secret assigned to a candidate relationship. It does not prove which physical device held the secret or whether the source network was uncompromised. Together they narrow the claim without manufacturing certainty.

A TLS PSK is not the RADIUS shared secret

RFC 9813 is unusually explicit about vocabulary because migration interfaces invite reuse. The RADIUS shared secret authenticates parts of the RADIUS protocol. The TLS PSK authenticates the TLS relationship. One value must not be used for both roles, and implementations must reject attempts to configure the same value in both fields.

The separation is also temporal. The same PSK must not cross TLS 1.3 and earlier protocol versions. TLS 1.3 binds PSKs differently to the key derivation function; RFC 9258 defines an import mechanism that can derive version-, KDF- and context-bound keys. A convenient “site secret” copied into every field would erase those boundaries and let a weakness in one use contaminate another.

This is a lifecycle problem disguised as a form design problem. Interfaces should name the TLS PSK and RADIUS shared secret separately, expose their non-secret identifiers and generations, and prevent accidental equality without logging the secret material. Inventory must answer which relationships and protocol versions depend on each credential generation.

The TLS PSK affects the channel. It does not change the RADIUS packet encoding inside the channel. A green handshake therefore cannot replace the RADIUS message checks or the application's authorization decision.

One relationship, one blast radius

Symmetric credentials have a special authority shape. Both parties know the secret. If a client configuration is exposed, the attacker may be able to impersonate not only the client but also the server. RFC 9813 therefore discourages TLS-PSK across unrelated organizations, where a shared secret makes the institutional boundary itself ambiguous.

Reuse increases the number of principals who can produce the same proof. One PSK across twenty clients may make deployment easy, but an observed successful handshake can no longer distinguish which copy was used. Revoking one compromised client requires changing nineteen innocent ones or accepting continued exposure. Logs that name only the identity can look precise while the underlying secret is communal.

The right inventory unit is the client-server relationship, not the string shown in an administration screen. Record owners on both sides, secret generation, identity generation, permitted source ranges, distribution channel, activation observations, last seen, overlap deadline and retirement. Never store the secret itself in the audit record; store a stable non-secret fingerprint or vault version that can join evidence without becoming a second credential store.

Rotation must retire an identity as well as a key

RFC 9813 recommends regular rotation without inventing a universal interval. Rotation has non-zero cost, and the balance between change cost and compromise cost belongs to the operator. But one rule is not optional: because the PSK is looked up by identity, the identity must change when the PSK changes.

That requirement prevents a misleading in-place update. If the row keeps the old identity while its secret changes, an operator cannot tell whether a failing client is stale, misconfigured or attacking the known name. Overlap becomes invisible. Rollback can restore the old key under the same selector without leaving an intelligible state transition.

A controlled rotation creates a new relationship generation. The server temporarily recognizes old and new identities under an explicit overlap policy. Clients are observed using the new generation. Dormant exceptions are named. The old identity is disabled, its last successful use is recorded and late attempts become actionable evidence. Distribution is not completion; retirement closes the change.

Last-seen tracking is useful but not self-executing truth. Silence may mean a stolen device, a retired device, an outage or a seasonal client. Automatic invalidation bounds risk only when the owner, inactivity threshold, exception process and recovery path are known. Otherwise a security control becomes an unowned availability switch.

Resumption creates a second identity namespace

TLS 1.3 session resumption also uses PSKs and identities, but those values are created by the TLS subsystem. They are not the administrator's static client names. RFC 9813 recommends against resumption for TLS-PSK because the benefit is small and the ambiguity is large.

Where mixed deployments require it, the server must distinguish the namespaces. It can make static identities recognizable as administrative UTF-8 forms and resumption tickets opaque, or maintain separate tables. An unknown value in both namespaces closes the connection. A collision must never let a ticket enter the static client table or let an untrusted static-looking string be accepted as authenticated resumption state.

Ticket validation is still not permanent authorization. The server must recover enough cached identity and policy from the original full handshake to make a new decision. If source address or another relevant input changed, the affected policy must be reevaluated. If the cache cannot be recovered securely, the server performs a full handshake. RFC 9813 also carries the TLS limit that resumption material and associated cache must not be held beyond seven days, even if a ticket advertises a longer life.

The operational receipt therefore records the original authentication generation, ticket namespace, cache generation, current source, reevaluated rules and decision. “Resumed” describes how the TLS state was recovered. It is not a waiver of current policy.

Evidence is a chain, not a client name

A mature RADIUS/TLS view should preserve at least these transitions:

  1. the connection arrived from an address inside a coarse allowed range;
  2. the PSK Identity passed bounded parsing and namespace checks;
  3. the normalized selector chose one versioned client relationship;
  4. the relationship permitted the observed source address;
  5. the negotiated TLS version, KDF and forward-secret exchange matched policy;
  6. the peer proved possession of the selected PSK;
  7. any resumption cache was authentic, current and sufficient for reevaluation;
  8. the RADIUS message passed its own protocol checks;
  9. the client-specific request policy accepted or rejected the request;
  10. the network access server executed an action; and
  11. the intended user or system observed the resulting service.

Each item can be true while a later item is false. The sequence is not bureaucratic padding. It is how an operator discovers whether an incident belongs to exposure filtering, parser behavior, credential custody, table drift, TLS negotiation, RADIUS policy, the access device or the service itself.

Running-Code Primacy supplies the test. A standards-compliant field and a configured row do not prove which generation the running server selected. That evidence comes from the live parser, credential lookup, handshake and policy engine. On Reality Layers explains why none of their receipts should be allowed to speak for all the others.

The result is a more honest meaning for identity. The IP address did not cease to matter. The PSK Identity did not become a person or a device certificate. It became the explicit selector for one relationship, surrounded by independent constraints and followed by cryptographic proof. RFC 9813 improves the system by making that handoff visible. Operators finish the job by keeping the handoff auditable.

Sources