A trackside router's TACACS+ traffic crosses a cable an attacker can tap and modify; without the shared secret, what can they still change in the body?

## Why a keystream is malleable The classic TACACS+ transport masks the body by XOR against a `pseudo_pad`. That construction has a property people consistently underestimate: **an attacker who changes the ciphertext changes the plaintext in a controlled way, without ever learning either.** If `c = p XOR k`, then `c XOR d = (p XOR d) XOR k` for any `d` the attacker chooses. The receiver unmasks with the same `k` and gets `p XOR d`, and nothing in the protocol notices. The only thing standing between that property and a chosen substitution is knowing `p` at the offset you want to change. That is the role of **known plaintext**, and this protocol supplies it generously: the body layouts are published, several leading fields are one-octet enumerations with a handful of plausible values, and the common values are common precisely because they are the deployed ones. ## The lever, stated as arithmetic For one octet at a known offset: 1. The attacker observes the masked octet, `observed`. 2. They assume the plaintext, `known` — for `authen_method` in an authorization REQUEST from a device doing device-administration AAA, that is `TAC_PLUS_AUTHEN_METH_TACACSPLUS := 0x06`. 3. `pad_octet = observed XOR known` recovers the pad at that offset **exactly**, for that packet. 4. `forged = desired XOR pad_octet` re-masks whatever value they want, here `TAC_PLUS_AUTHEN_METH_LINE := 0x03`. 5. They write `forged` back and forward the packet. No other octet is touched, the shared secret is never recovered, and MD5 is not attacked at all. The attacker has borrowed one octet of the sender's own pad. ## Why the receiver does not notice The one consistency check the classic transport performs is a length reconciliation: after the body is unmasked, the component lengths declared inside it are summed and compared with the `length` field in the cleartext header, and a mismatch means the packet **MUST** be discarded and an ERROR signalled. That check is the reason a wrong shared secret is detected at all. It does nothing here. Replacing one one-octet enumeration with another one-octet enumeration changes no declared length, so the sums still reconcile and the packet is processed as valid. This is worth saying out loud, because a common wrong answer is that tampering corrupts the packet and the receiver drops it. | What the obfuscation stops | What it does not stop | |---|---| | A passive observer reading the body without the secret | A modification whose plaintext the attacker can predict | | Nothing else on the integrity axis | Replay of a recorded packet | | — | Offline guessing of the secret from a capture | | — | Chosen-plaintext sharpening of both of the above | ## Why this particular field is the specification's example `authen_method` tells the device-administration server how the user was authenticated. The specification is explicit that it is informational and not to be used in policy evaluation, but the reason Section 10.3 singles it out is a deployment habit rather than a protocol rule: **authorizing everything typed on a locally attached line is common**, so a policy that would refuse a command arriving with one method value approves it under another. The attacker does not need to guess which octet or what masks it, because known plaintext tells them both with certainty. One octet, one XOR, and every command goes through. ## What this does and does not require of the attacker - **Required:** a position on the path where packets can be modified in flight, not merely observed. On a cable run between unattended trackside sites that is a physical-access problem, and the specification's own advice is to assume an attacker with access to the data stream can read and modify everything. - **Required:** knowledge of the body layout and a confident guess at one plaintext octet. - **Not required:** the shared secret, any weakness in MD5's collision or preimage resistance, or the ability to read the rest of the body. ## What actually removes it Nothing inside the obfuscation does — the specification states the protocol offers no meaningful integrity, and integrity cannot be retrofitted into an XOR pad. The remedy is a transport that authenticates every byte: RFC 9887 carries TACACS+ inside TLS 1.3 on a separate well-known port, where record protection is authenticated and an in-flight modification breaks the record rather than being delivered. Short of that, the honest mitigation is to treat the path as hostile — keep it physically and topologically narrow, use a dedicated key per client so one break does not travel, and accept that an attacker on the wire can rewrite what the server is asked.