On 29/08/15 14:36, Alan DeKok wrote:

For personal security and privacy, it's a good idea. The end device can still be identified via other means, but they're not as good / unique.

Their implementation is pretty good - sticky per SSID until the network is forgotten/reconfiged or "daily", randomised for probes to avoid geographical tracking. I think it's a non-issue for wireless network in general. *Those* clients should be using 802.1x anyway (but see below).

MAC auth was always a hack. People should use 802.1X instead.

True, but even on 802.11, there's plenty of kit that doesn't support 802.1x - games consoles, smart TVs and other entertainment boxes are a great example. In "dense" network environments e.g. student residences, you can either: 1. Deploy a separate WPA PSK SSID per-customer (!) and hand out the PSK manually - lots of beacon frames, horrible RF performance 2. Use a single WPA PSK SSID and key the PSK off the client MAC address 3. Don't use WPA 4. Don't let the devices on the network It's also worth pointing out that we're a long way from 802.1x being usable on wired networks in unmanaged/BYOD/public access areas - there's a bunch of caveats, ranging from wired 802.1x supplicants being disabled by default on most OSes (and wired ethernet lacking a link-layer handshake protocol like 802.11 to signal use of 802.1x) to switch vendors having terrible implementations e.g. "wait 3 EAP timeouts before fallback to MAC auth", which can be 60 seconds, in which time your old print server / CCTV device / BEMS/SCADA system has fallen silent and needs manual intervention. MAC auth in general will be around for a while I fear :o(

On 01/09/15 13:31, Alan DeKok wrote:

Yeah. The client sends a DHCP discover, and the switch ignores it... because it's waiting for EAP!

My suspicion is that most switch vendors hire engineers who know nothing about networks, and who don't use the equipment they're building.

The weird thing about this is that equipment varies dramatically in how it handles this. For example, the now-ancient 3Com 4400s handled this very well indeed; they treated non-EAP traffic as macauth, until the first EAP packet from a given source MAC, at which point they toggled a soft-state bit, making that MAC/port combo "EAP required", and clearing the state at link-down. Worked very well. Juniper handle this poorly - if you force macauth-only they macauth straight away, otherwise you wait NxM (N=configurable, M=EAP timeout) which is almost always longer than you want to wait for DHCP to complete on a non-EAP device :o/