skip to content

Three dozen field access devices share one RADIUS secret over UDP: what makes committing them to RADIUS over TLS a programme rather than a configuration change?

level: principalimportance: should knowfreq 30%

answer

  1. a second listener, not a setting
  2. the estate is in the field
  3. certificates bring a lifecycle with them
  4. TCP 2083, payload secret fixed to "radsec"
  5. Experimental status, and no flag day

basics

~20 s

RADIUS over TLS is a different transport on a different port, so it cannot be enabled on the existing listener: every access device must support it, hold a certificate with a renewal path, and be cut over individually, while the server runs both listeners for as long as the slowest device takes.

solid answer

~50 s

RADIUS over TLS (RFC 6614) is TCP port 2083, not UDP 1812, and the payload shared secret becomes the fixed literal `"radsec"` because the transport now does the work. That means there is no in-place upgrade: the server runs a second listener, and each access device moves when its own firmware, certificate and clock allow. Three costs dominate. **Capability**: field devices that cannot speak it need replacing, and that is a capital decision, not a change window. **Certificates**: you are adopting an issuance, renewal, revocation and clock-accuracy lifecycle per device, in places nobody visits. **Duration**: there is no flag day, so the UDP listener and its MD5 constructions stay live — and stay your real exposure — until the last device is off them. The interim controls are a long random per-device secret and `Message-Authenticator (80)` everywhere it can be carried.

go deeper

for a junior

The takeaway is direction, not detail: the answer to RADIUS's aging cryptography was to move the exchange onto TLS rather than to swap MD5 for a newer hash.

for a middle

Know that RADIUS over TLS is a different transport and port from UDP 1812, and that the payload shared secret becomes meaningless under it.

for a senior

Be able to sequence a cutover: two listeners, a device-capability inventory, a certificate lifecycle, and interim hardening that stays in force for the whole overlap.

for a principal

Own the trade-off out loud — capital cost against a recording nobody can date, an Experimental specification against a construction its own standards body warns about, and an end state defined as switching the old listener off.

## What is actually on offer Three documents matter, and their status is part of the decision. | Document | What it defines | Transport | Status | |---|---|---|---| | RFC 6614 | RADIUS over TLS | TCP port 2083 | Experimental | | RFC 7360 | RADIUS/DTLS | UDP port 2083 | Experimental | | RFC 9765 | RADIUS/1.1, negotiated by the ALPN name `"radius/1.1"` | over the TLS transports above | Experimental, April 2025 | RFC 6614 builds on RADIUS over TCP (RFC 6613). Under it the payload's shared secret is **fixed to the literal string `"radsec"`** — it is obsolete, because TLS supplies the confidentiality and integrity the secret used to approximate. RFC 9765 goes further and **removes the shared secret and every MD5-based construction outright**, updating RFC 2865, RFC 2866, RFC 5176, RFC 6613, RFC 6614 and RFC 7360. All three are **Experimental**, which is a fact to put in front of whoever signs the budget rather than one to discover during procurement. ## Why it is not a configuration change 1. **Different transport, different port.** UDP 1812 and TCP 2083 are separate listeners. You do not upgrade a deployment; you stand a second one up beside it and migrate into it. Anything that assumed one listener — a firewall rule set, a load balancer, a monitoring probe, a change freeze — is now two. 2. **The thing that must change is in the field.** The server side is the easy half. The devices are the estate: some will support the transport, some will need firmware nobody has tested on that hardware revision, and some will never support it and must be replaced on a capital cycle. 3. **You are adopting a certificate lifecycle, per device, in places nobody visits.** Issuance, distribution, renewal before expiry, revocation when a device is stolen, and an accurate clock so validity windows mean anything. A shared secret has none of these obligations, which is exactly why it survived for thirty years. 4. **There is no flag day.** Until the last device moves, the UDP listener stays up with its MD5 constructions and its one shared secret. The exposure you are migrating away from is the exposure you still have, for the whole duration. 5. **Trust decisions get harder, not simpler.** Under the shared secret a client is recognised by source address plus secret. Under TLS you must decide what makes a peer acceptable — which issuer, which identity in the certificate, what happens when a device is decommissioned — and that policy has to exist before the first cutover, not after. ## What to do in the meantime, and what it is worth - **A long, random, per-device secret.** It is the only remaining parameter against offline guessing, and per-device means one compromised device is not the whole estate. Note the constraint the protocol imposes: the secret is selected by source IP address, so clients sharing an address must share a secret. - **`Message-Authenticator (80)` on every packet the deployment can carry it on.** It closes on-path forgery and the collision attack against the `Response Authenticator`. It does **not** help against offline guessing — RFC 3579 §3.2 is explicit — so it buys integrity, not time. - **Verify that each device's `Request Authenticator` is genuinely unpredictable.** A repeated nonce undoes the password hiding regardless of secret strength, and this is firmware behaviour you cannot see from the server. - **Treat the exposure as a capture problem.** On a shared medium the question is not whether traffic can be recorded but who has recorded it already, and how long a secret must resist a recording made today. ## Sequencing the programme Run both listeners. Inventory devices by whether they can speak the transport at all, then by whether they can hold a certificate with a working renewal path. Move the highest-value sites first, not the easiest ones, because the point of the programme is exposure reduction rather than ticket count. Keep the UDP listener's controls current for the whole overlap — a migration that lets interim hardening lapse because "we are moving off it anyway" is worse than not starting. ## What you are not buying A transport change fixes the wire. It does not change which attributes a server returns, who may enrol a device, or what an access device does with an `Access-Accept (Code 2)`. It does not make an authorization model better, and it does not remove the need to know which devices exist. Being clear about that boundary is most of what makes the business case survive contact with a budget: the programme's deliverable is that a recording of your AAA traffic stops being useful, and nothing else.

  • Why does RADIUS over TLS fix the payload shared secret to the literal string "radsec"?
    Because the secret's jobs — hiding `User-Password (2)`, keying the reply digest — are now done by the TLS transport, but the packet format still has the fields that reference a secret. Fixing it to a known literal keeps the encoding legal while making clear that it carries no security value. RFC 9765 removes it entirely.
  • What do you tell an owner who asks to keep UDP for the devices that cannot be upgraded?
    That it is a legitimate answer with a named cost: those devices keep the full offline-guessing exposure, and their secret must be long, random and unique to each of them. Put them on a replacement schedule with a date, and keep `Message-Authenticator (80)` mandatory for them, so the exception is bounded rather than permanent.
  • Does the Experimental status of RFC 6614 and RFC 9765 argue against the migration?
    It argues for stating it rather than hiding it. Experimental describes the standards track position, not deployment maturity, and the alternative is a construction the specifications themselves warn about. The practical caution it justifies is interoperability testing between your server and each device model before committing to a vendor or a schedule.
  • What is the one measurable outcome that tells you the programme is done?
    That the UDP 1812 listener is switched off. Until then every gain is partial, because a single device left on the old transport keeps a shared secret in service and keeps a recording of that device's traffic worth guessing against.

saying these in an interview costs you the question

  • Calls it a configuration flag on the existing listener
  • Assumes TLS can be enabled on UDP port 1812
  • Forgets that certificates need renewal and an accurate clock
  • Says a longer shared secret makes migration unnecessary
  • Treats Experimental status as meaning unusable
  • Believes the transport change also fixes authorization policy