skip to content

Your fleet still runs obfuscated TACACS+ on TCP port 49 — how do you decide whether to move device administration to the RFC 9887 TLS 1.3 transport, and what does it cost?

level: principalimportance: should knowfreq 28%

answer

  1. exposure decides, not the mechanism
  2. separate port, no upgrade in place
  3. TLS 1.3 only, mutual certificates
  4. the flag's meaning inverts over TLS
  5. certificate lifecycle on every device

basics

~20 s

Decide on exposure, not principle: the obfuscation gives no integrity, no replay protection and no forward secrecy wherever the path is reachable. RFC 9887 moves TACACS+ onto TLS 1.3 at TCP port 300 with mutual certificate authentication — and a certificate lifecycle on every device.

solid answer

~50 s

Frame it as which links you would be content for an attacker to read and rewrite. A locked row in a data centre is a different answer from cable runs between unattended trackside sites. Where the exposure is real, the obfuscation cannot be improved into adequacy — there is no integrity to add — so the question becomes whether you can operate the replacement. RFC 9887 requires TLS 1.3 as a minimum with earlier versions forbidden, a distinct well-known port (`TCP port 300`, service name `tacacss`), a handshake that begins immediately on connect with upgrade-in-place forbidden, mandatory support for certificate-based mutual authentication, and server identity validated per RFC 9525 using DNS-ID, IP-ID or SRV-ID but never URI-ID. The bill is a certificate lifecycle on hardware you visit rarely, a per-site cutover because there is no in-place upgrade, and a mixed estate for as long as some devices cannot speak it.

go deeper

for a junior

Recall that the classic transport and the TLS transport are separate, on separate ports, and that one is not an option you switch on inside the other.

for a middle

List what the TLS transport mandates — TLS 1.3 minimum, its own well-known port, an immediate handshake, mutual certificate support — and explain why none of it is negotiated in band.

for a senior

Show you have run the cutover in your head: clocks, naming, certificate renewal on rarely visited hardware, and a rollback that leaves the old transport configured until the new one is proven.

for a principal

Own the sequencing and the bill: which exposure classes justify the spend, what the mixed estate costs while it lasts, and what you knowingly accept on links that will never move.

## Frame the decision as exposure, not as principle The temptation is to argue the mechanism: MD5, a pad, obfuscation not encryption, therefore migrate. That argument is true and it does not size the work. The decision that holds up in a budget conversation is about **paths**: for each link the device-administration traffic crosses, would you accept an attacker on it reading every packet and rewriting the ones whose contents they can predict? The specification's own posture is that you should assume exactly that of anyone with access to the data stream. On a signalling estate whose trackside routers sit at the end of cable runs between unattended sites, the answer is no, and it is no for the whole class at once. In a locked row where the only path is a patch cable inside one cabinet, the answer can honestly be "not yet" — and that is where the migration budget buys least. ## What the replacement actually requires RFC 9887 is prescriptive, and the constraints are what make this a project rather than a setting: - **TLS 1.3 as a minimum**, with earlier versions forbidden. - **A distinct well-known port, TCP port 300**, with the IANA service name `tacacss`. It does not share TCP port 49. - **The handshake begins immediately on connect**; upgrade-in-place options are forbidden, so there is no starting in the clear and negotiating upward. - **Mandatory support for certificate-based mutual authentication** — both peers, not only the server. - **Server identity validated per RFC 9525**, using DNS-ID, IP-ID or SRV-ID; URI-ID must not be used. - **Mandatory support for the `server_name` extension**, so the client can name the service it intends to reach. - **Optional external PSKs of at least 16 octets**, which **MUST NOT** be the same values as the obfuscation shared secrets. - **Every packet MUST have `TAC_PLUS_UNENCRYPTED_FLAG` set to 1**, because the body genuinely is not obfuscated any more; a peer that receives one without it MUST error and terminate the session. That last point is the polarity inversion people trip over. On the classic transport the flag set means "unprotected, drop this". On the TLS transport it set means "correct". Any runbook, monitor or test that asserts on the flag has to know which transport it is looking at. ## What you gain, stated without overstatement - **Confidentiality that does not rest on one long-lived typed-in secret.** - **Integrity and replay protection at the record layer**, which is what removes the in-flight field substitution the obfuscation permits. - **Forward secrecy where the handshake uses an ephemeral key exchange** — the usual case, though the external-PSK option means it is worth naming which mode you run. - **Peer authentication by certificate in both directions**, which the shared secret only ever provided implicitly and weakly. ## The bill | Cost | What it means in the field | |---|---| | Certificate issuance and renewal | Every device becomes a certificate holder with an expiry, on hardware you may touch twice a year | | A trust anchor and its rotation | Something must distribute and eventually replace it on devices that are offline for long stretches | | Naming | Validation is by DNS-ID, IP-ID or SRV-ID, so a device with no stable name falls back to IP-ID and readdressing becomes a certificate event | | Cutover | No upgrade in place and a separate port, so each site is a scheduled change with a rollback plan, not a flag flip | | Time | Certificate validity windows are absolute, so a device with a badly wrong clock fails the handshake rather than degrading | | Mixed estate | Hardware that will never support it keeps the old transport, so two device-administration planes run side by side for a while | ## A defensible sequence 1. **Classify links by exposure**, not by site importance. The unattended run to a remote cabinet outranks the core. 2. **Establish whether both ends can speak it at all** — the server side and each device family — because that, not policy, sets the achievable scope. 3. **Move the most exposed class first**, one site at a time, with the old transport still configured until the new one is proven. 4. **Fix the clock and the naming before the certificates**, because both failures look like certificate failures and will burn a maintenance window. 5. **For what cannot move, narrow the obfuscated case as far as the specification allows**: a dedicated key per client, at least 32 characters from a good random source (RFC 4086), tracked lifetimes with rotation, and secrets never written to logs. ## What does not change The three exchanges, the argument-value pair vocabulary, the 12-byte header and the session model are the same protocol on either transport. This is a transport substitution rather than a redesign — which is the argument that makes it fundable, and also the reason nobody notices it has not been done.

  • Why must every TACACS+ packet set TAC_PLUS_UNENCRYPTED_FLAG on the RFC 9887 transport?
    Because the flag reports a fact about the body, and over TLS the body genuinely is not obfuscated — TLS protects it instead, and applying the MD5 pad underneath would add nothing. A peer receiving a packet without the flag set MUST error and terminate the session, so the two transports cannot be mixed by accident.
  • Which identity forms may a client use to validate the server's certificate?
    Under RFC 9525, DNS-ID, IP-ID or SRV-ID; URI-ID must not be used. Support for the `server_name` extension is mandatory so the client can state which service it intends to reach. Devices with no stable name in the naming service end up validated by IP-ID, which makes readdressing a certificate event.
  • Can an external PSK reuse the existing obfuscation shared secret?
    No. External PSKs are optional, must be at least 16 octets, and MUST NOT be the same values as the obfuscation shared secrets. Reusing one would tie the new transport's security to a value that may already be recoverable from years of captured traffic.
  • What is the honest interim position for hardware that will never support the TLS transport?
    Keep the obfuscated transport there and narrow it: a dedicated key per client, at least 32 characters from a good random source, tracked lifetimes with regular rotation, and secrets kept out of logs. Then plan on the assumption that those links are readable and modifiable.

saying these in an interview costs you the question

  • Says the TLS transport is negotiated on the existing TCP port 49.
  • Treats the migration as a server change with no device-side work.
  • Argues obfuscation is adequate because the management network is private.
  • Thinks the unencrypted flag must stay clear when running over TLS.
  • Plans to reuse the obfuscation shared secret as the TLS external PSK.
  • Expects forward secrecy from the existing shared-secret scheme.