A switch spliced between the wall socket and an authenticated phone: why does the port stay authorized, and what stops it?

## The session's real lifetime Candidates usually describe 802.1X admission correctly and then assume the session is continuously verified. It is not. On a typical access port, an authorized session persists until one of a small set of events ends it: - **Link-down** - the dominant one, and the one everyone pictures - **A reauthentication that fails**, where one is configured or the policy server returned a session timeout with a reauthenticate action - **An inactivity timeout**, where the authenticator ages out a session whose address has gone quiet - **An explicit teardown initiated by the policy server** Most estates rely almost entirely on the first. That makes the authorization state a function of *the wall port's physical link*, not of the authenticated device's presence. ## The splice Put a small unmanaged switch inline: wall socket to the switch, switch to the phone and PC. Nothing about the authentication changes - the endpoints still authenticate, the sessions still come up. What changes is that the wall port's link is now terminated by the inserted switch, and it stays up regardless of what happens downstream. Unplug the phone: the phone's link drops, the wall port's does not. The attacker now has a live, already-authorized link with a free socket on it. Whether they get anything depends entirely on the host mode: | Host mode on the wall port | What the attacker's laptop gets | |---|---| | Multi-host | Full access with no authentication attempt at all | | Multi-domain / multi-auth | Its own address is challenged - but it can instead impersonate an address already authorized on that link | | Single-host | The port sees a second address and treats it as a violation | The uncomfortable middle row is the realistic one, because multi-domain or multi-auth is what a phone fleet forces on you. Session binding is to a source address, so the attacker's move is not `defeat authentication`, it is `use an address that already passed`. That is a much shorter piece of work, especially if they can knock the real device off first. ## Why the usual answers do not work **`Shorten the reauthentication timer.`** Reauthentication re-runs the exchange with whichever supplicant answers. A passive rider answers nothing and is not affected; an address-impersonating rider benefits from the real device still succeeding. A successful reauth proves a credential-holding device is still on that link - it says nothing about how many devices are there. Shorter timers do bound how long a *stale* authorization lasts after a legitimate device is genuinely gone, which is worth something, and they also multiply policy-server load across the estate. Bound the staleness, do not pretend it is presence detection. **`Limit the port to one address.`** Voice plus data already needs more than one, and an attacker who impersonates an authorized address does not add one. **`Detect the extra switch.`** Neighbour-discovery-based detection catches a manageable switch that announces itself, and a deliberately silent unmanaged one is exactly what will not be caught. Treat it as a hygiene signal, not a control. ## What actually closes it **802.1AE MACsec on the access link**, with keys derived from the successful 802.1X authentication via MKA. MACsec provides integrity and confidentiality hop by hop between the endpoint and the switch port. Two consequences follow: 1. Frames from a device that holds no key are simply not part of the secured association, so riding the session is not available. 2. A dumb switch spliced into the middle cannot participate. The link either fails to establish the secure association or the inserted device is visible as a break - the splice becomes an outage rather than a foothold, which is the outcome you want. The price is the honest part of the answer, and it is what separates a senior answer from a textbook one: - **Hardware.** Access switches need ASIC support at line rate; endpoints need supplicants that do MKA. In a mixed estate that is a refresh programme with a capital line, not a template edit. - **Coverage gaps become policy questions.** If half the fleet can do MACsec, you are running two port templates and someone must decide whether the non-capable half is accepted, segmented or replaced. - **Troubleshooting changes.** A link that once came up and passed traffic now has a key-agreement state to fail in, and the closet technician needs to know that. ## The sentence to land Admission is a moment; the session is a lease held open by link state. Any control that only re-runs admission re-tests the answering device, not the link. To make the link itself the thing you trust, you have to pay for per-frame protection on it.