An IP phone with a PC daisy-chained behind it breaks single-host 802.1X: which host mode, and what does it cost?
answer
- two devices, one port, one authorization decision
- one mode asks once and then stops asking
- voice and data are separate domains, not one session
- the strongest mode is the one the phone breaks
basics
~20 sMulti-domain: the phone authenticates into the voice domain and the PC into the data domain, two sessions on one port. It costs single-host's guarantee that exactly one device is ever authorized there, and multi-host would cost far more.
solid answer
~40 sSingle-host authorizes one address and treats a second as a violation, so a phone with a PC behind it fails immediately. The tempting fix is multi-host, where the first successful authentication opens the port for every other address on it - that is the mode an attacker wants, because their laptop behind the phone never has to authenticate at all. The correct answer is multi-domain: exactly one voice device and one data device, each authenticating separately, with the policy server returning a voice authorization that lets the phone tag into the voice VLAN. Where a port may carry more than two endpoints, multi-auth makes every address authenticate independently. Either way you have given up the one-device-per-port guarantee, and you should be able to say what that costs.
go deeper
Know that a phone with a PC behind it puts two devices on one port, and that the strictest 802.1X host mode allows only one. Name multi-domain as the phone-plus-PC answer.
Explain all four host modes precisely, especially that multi-host authorizes the whole port after one success, and how the voice domain is signalled and authorized.
Justify picking the least permissive mode per port class, and state exactly which guarantee each step down surrenders and how an attacker uses it.
Argue the estate-wide position: whether phone fleets force multi-domain everywhere, what that weakens, and what you would fund to get the guarantee back.
## Why the phone breaks the simple case A desk phone with a PC plugged into its pass-through port is a two-device link on one switch port. The phone tags its own voice traffic into the voice VLAN - it learns which VLAN to use from LLDP-MED (or the older vendor discovery protocol) - and passes the PC's untagged frames through to the data VLAN. From the authenticator's viewpoint, two source addresses appear on one port. That is illegal under **single-host** mode, which authorizes exactly one address and treats any other as a security violation, typically dropping traffic or shutting the port. Single-host is the strongest posture 802.1X offers on an access port, and a phone fleet is the most common reason estates cannot use it. ## The four host modes, and what each surrenders | Host mode | Who must authenticate | Guarantee given up | |---|---|---| | Single-host | One device; a second is a violation | Nothing - but a phone breaks it | | Multi-host | The **first** device only; all others ride free | Everything: one success opens the port for any address | | Multi-domain | One voice device and one data device, separately | `Exactly one` becomes `exactly two, one per domain` | | Multi-auth | Every address, independently | The port may carry many authorized sessions | **Multi-host is the trap.** It reads like `several hosts are allowed`, and what it actually means is `after one host proves itself, the port stops asking`. An attacker who reaches any point on that link - a laptop plugged into the phone's pass-through port, or a small switch inserted in the run - inherits full authorization without sending a single EAPOL frame. Multi-host exists mostly for uplinks toward equipment you control, and putting it on a user-facing access port is the single most common way an 802.1X deployment ends up decorative. **Multi-domain** is the right answer for the phone case. Two sessions run on the port: the phone authenticates and the policy server returns an authorization marking it as a voice device, which permits it to use the tagged voice VLAN; the PC authenticates separately for the data VLAN. Each session is tracked with its own address, so removing one does not authorize the other. **Multi-auth** generalises this: every address on the port authenticates on its own account. It is the honest choice when a port might carry more than two devices - a small conference-room switch, a lab bench - and it is more permissive by shape, since the port may end up with several authorized sessions at once. ## What you have actually paid The moment you leave single-host, the port no longer promises `one authenticated device here`. It promises `each address I have seen was authenticated`, which is a strictly weaker statement for three reasons: 1. **Address-based session tracking is spoofable.** The authenticator binds a session to a source address, not to the frames themselves. An attacker who can knock a device off and impersonate its address is attacking a much shorter list than a credential. 2. **The voice domain is a trust decision, not just a VLAN.** Whatever authenticates into the voice domain gets to use the tagged voice VLAN. If the policy server's rule for that is weak, the voice domain becomes the easy door. 3. **You have created a second thing to get wrong.** Two vendors' switches, two defaults, two ways for a template drift to leave a closet in multi-host. ## What to say when asked `so which do you pick?` Pick the *least permissive mode that the actual devices on that port class require* - single-host where nothing is daisy-chained, multi-domain for phone-plus-PC, multi-auth only where a port genuinely carries more, and multi-host essentially never on a user-facing port. Then say the part interviewers are listening for: this is still admission at the moment of plug-in. None of these modes verifies that the traffic arriving now belongs to the session that was authorized; that requires per-frame protection on the link, which is a different control with a different price tag.
- Why is multi-host a poor choice on a user-facing access port?Because it authorizes the port, not the device. The first successful authentication opens the controlled channel for every other address on that link, so anything plugged in behind the authenticated endpoint gets full access without ever sending EAPOL. It converts 802.1X from an admission control into a one-time formality performed by whichever device booted first.
- What does the policy server have to return for the phone in multi-domain mode?An authorization that places the session in the voice domain, so the authenticator permits that address to use the tagged voice VLAN alongside the untagged data session. Without it the phone's session is treated as a data device and the second endpoint on the port is rejected, which looks like a switch bug and is actually a policy-side omission.
- If every address must authenticate in multi-auth, why is it still weaker than single-host?Because sessions are bound to source addresses. Multi-auth means each new address is challenged, not that frames are cryptographically tied to a session. An attacker who removes a device and takes its address is no longer facing an authentication decision, and the port now legitimately expects several endpoints, so an extra one is less anomalous.
saying these in an interview costs you the question
- Picks multi-host because `there are multiple hosts on the port`
- Thinks the phone and PC share one authentication session
- Believes the voice VLAN is exempt from 802.1X
- Claims multi-auth is as strong as single-host because everyone authenticates
- Assumes host mode also validates that later frames belong to the session