An attacker patches a laptop into an 802.1X access port: what passes before authentication, and what does that cost you?
answer
- one physical port, two logical ones
- one channel is always open, but only for one thing
- the attacker gets silence, not a rejection
- everything without a supplicant sees the same silence
basics
~20 sOnly EAPOL. The port's uncontrolled channel carries 802.1X frames; DHCP, ARP and everything else are dropped until authentication authorizes the controlled channel. Anything with no supplicant - imaging, headless kit - therefore sees a dead socket.
solid answer
~40 sAn 802.1X authenticator treats one physical port as two logical ones. The uncontrolled channel forwards EAPOL only, so the switch can ask `who are you?` and relay the answer to the policy server. The controlled channel, which carries actual user traffic, stays unauthorized until that exchange succeeds. An attacker who plugs in gets no DHCP lease, no ARP replies, no route to anything - the socket looks dead, which is exactly the point. The price is that every legitimate device with no supplicant sees the same dead socket: PXE and bare-metal imaging, headless appliances, and any endpoint whose supplicant starts after DHCP has already given up. So enabling 802.1X is never just a switch config change; it is an inventory exercise plus a documented exception path, and someone has to own that list.
go deeper
Be ready to say plainly that only EAPOL passes before authentication, and that everything else - DHCP included - is dropped. Name one legitimate device that this breaks.
Explain the controlled/uncontrolled split, who starts the exchange, and how identity-request timers can race a client's DHCP timeout and produce a support ticket.
Show that you would inventory access ports in a non-enforcing mode first, and that you can state what an authorized port does and does not prove about the device now using it.
Own the tradeoff between how long the port waits and how much traffic gets pushed onto weaker fallback paths, and be clear who signs off on the permanent exception list.
## Two logical ports on one wire 802.1X calls the switch the **authenticator**, the endpoint the **supplicant**, and the policy server the **authentication server**. The authenticator models each access port as two logical ports: - **Uncontrolled port** - always open, but only for EAPOL (EAP over LAN, the layer-2 carrier for the authentication conversation). Depending on platform, a few link-local control protocols such as LLDP, CDP or STP also ride here. - **Controlled port** - carries everything the user cares about (DHCP, ARP, IP). It sits in the *unauthorized* state and forwards nothing until the exchange succeeds. On link-up the authenticator sends an EAP-Request/Identity, or the supplicant announces itself with EAPOL-Start. The authenticator relays the EAP conversation to the policy server, and only on a success does it flip the controlled port to *authorized*. ## What the attacker actually experiences This is the defensive value, and it is worth being precise about it. Someone who walks in and patches a laptop into a wall socket does not get a `denied` message; they get nothing. No DHCP offer, no ARP resolution, no gateway. A self-assigned link-local address and silence. The port is physically up and logically closed, which is a genuinely different posture from a filtered-but-live port, because there is no reachable service to probe at all. What it does **not** give you: once the port is authorized, it is a pipe. The authenticator does not re-derive trust per frame, and it does not know how many devices sit behind whatever answered. Authorization proves that *a* credential was accepted on that port at some moment - not that the device sending traffic now is the one that presented it. ## The bill you pay for it Every device that cannot speak EAPOL is now, by design, unreachable: | Case | What breaks | |---|---| | PXE / bare-metal imaging | Firmware with no supplicant cannot get an address, so the build never starts | | Headless appliances, sensors, older printers | No supplicant at all; they simply never come up | | Slow supplicants | The OS supplicant starts after DHCP has timed out, so the user sees `no network` even though auth eventually succeeds | | Wake-on-LAN and out-of-band management | Traffic to a sleeping or pre-boot host is dropped at the closed controlled port | | A visitor or contractor with a laptop you do not manage | Nothing works, and the helpdesk hears about it | So the real deliverable is not the `dot1x` line in a port template. It is an inventory of what lives on access ports, an exception path for the things that can never authenticate (a separate design decision with its own containment cost), and timer choices that give the supplicant room to answer before the client's own DHCP client despairs. ## Timers are part of the security decision Two timers dominate the first week of any rollout: how long the authenticator waits for an identity response before it gives up on 802.1X, and how many times it retries. Set them long and every unauthenticated device sits in the dark for a noticeable time, and users reboot in frustration. Set them short and slow supplicants get pushed onto whatever fallback you built, which is the weaker path. Neither setting is `right`; the tradeoff is between user-visible delay and how readily traffic lands on the softer branch of your design. ## Rolling it out without owning an outage The standard sequence is to run the port template in a non-enforcing mode first - the switch performs the full exchange and logs the verdict, but authorizes the port regardless. That produces the inventory you should have had: which MACs never attempt EAPOL, which fail, which succeed after a long delay. Only then do you flip enforcement, closet by closet, with someone named who owns the phone that rings. ## Interview-grade summary Before authentication, an 802.1X port forwards EAPOL and nothing else. That is what makes an opportunistic plug-in useless, and it is also what makes the rollout an inventory and exception-management project rather than a config push.
- Why do users report `no network` even on ports where authentication eventually succeeds?Because the client's DHCP attempt and the 802.1X exchange race each other. If the supplicant starts late, or the authenticator's identity-request retries stretch the exchange past the DHCP client's own timeout, the stack gives up and self-assigns before the controlled port opens. The fix is timer alignment plus a supplicant that triggers a DHCP renew on authorization, not loosening the admission rule.
- Does an authorized 802.1X port tell you the device sending traffic is the one that authenticated?No. It tells you a credential was accepted on that port at some point. The authenticator does not validate each frame against the session, so anything sharing that link - a device behind a phone, or something spliced in downstream - inherits the authorization. Closing that gap needs per-frame protection, not a stronger authentication method.
- What should you do before turning enforcement on across a floor?Run the same port template in a non-enforcing mode that performs the exchange, logs the verdict and authorizes anyway. That produces the real inventory: which endpoints never send EAPOL, which fail, which are just slow. Enforcement then becomes a scheduled change with a known exception list and a named owner, rather than a discovery exercise conducted through the helpdesk queue.
It is a locked lobby door with an intercom. The intercom always works; the door never opens until someone answers it. Anyone who cannot speak into an intercom is left outside too.
saying these in an interview costs you the question
- Says the port allows DHCP so the client can get an address first
- Thinks an unauthenticated device lands in a guest VLAN by default
- Claims 802.1X blocks EAPOL too until the user logs in
- Treats enabling 802.1X as a switch config change with no inventory work
- Assumes an authorized port means exactly one trusted device is present