Cisco’s 'intuitive security' tool can’t handle MAC address randomization out-of-the-box
- Reference: 1600329489
- News link: https://www.theregister.co.uk/2020/09/17/cisco_isemac_randomization_warning/
- Source link:
A refresher: MAC addresses are unique identifiers assigned to network interface controllers, and are disclosed when devices communicate with each other on a network. MAC addresses were developed in more innocent times before we all started carrying networked devices around with us, and promiscuously connecting them to Wi-Fi hotspots and Bluetooth gizmos. Many of us make those connections without regard for the fact that it’s possible to track a device through space by following its MAC address from network to network.
The tech world wised up to this, and started to program devices to periodically randomize their MAC addresses so that the handhelds stopped leaving such easy-to-follow breadcrumb trails. The technique appeared in version 8 of both iOS and Android, in 2014 and 2017 respectively.
Which brings us to September 15, 2020, when Cisco [2]disclosed in a field notice that “Identity Services Engine MAC Address Lookup Might Fail with Android 10 and Apple iOS 14 Devices Due to the Use of MAC Randomization on the Mobile Client Devices.”
The field notice explains that unless ISE is fed policies to handle MAC address randomization, “previously provisioned mobile devices and the policies configured based on profiling identity groups might be incorrectly matched after the new MAC address randomization behavior takes effect.
“This could result in network connectivity disruption for these mobile devices.”
Cisco explains the cause of the problem as follows:
Even though the Android 10 and iOS 14 devices are set up to use randomized MAC addresses, when a wireless profile is created on the device the MAC address is always generated with the same random MAC address for the given wireless profile. This is true even when the wireless profile is deleted and recreated. However, when the dual-SSID BYOD flow is used, different MAC addresses will be generated for the onboarding SSID and the secured SSID. This causes a policy mismatch when using the precreated ISE BYOD Employee_EAP-TLS authorization rule.
This also impacts the single-SSID BYOD flow for devices that have been onboarded while running a previous version of iOS. Prior to iOS 14, the device uses a real MAC address for wireless access. However, upon upgrade to iOS 14, all existing wireless profiles will be updated to use random MAC addresses. Since the MAC address used during the previous version of iOS and after iOS 14 is different, authentication might fail if MAC address related conditions are used in conjunction with BYOD.
iOS 14, which became available today, therefore seems to be a part of the problem. But not all of it because ISE has [3]offered MAC randomization workarounds in March 2020 prior to version 14's official release.
Cisco’s latest field notice advises: “There is currently no large scale solution for the issues introduced by third-party MAC address randomization, only workarounds are available.” That workaround is detailed in the field notice, and has five steps; it doesn’t look horribly onerous.
The Register leaves it to our readers to decide if the need for a workaround represents “intuitive network security for the digital age.” ®
Get our [4]Tech Resources
[1] https://www.cisco.com/c/en_au/products/security/identity-services-engine/index.html
[2] https://www.cisco.com/c/en/us/support/docs/field-notices/706/fn70610.html
[3] https://community.cisco.com/t5/security-documents/random-mac-address-how-to-deal-with-it-using-ise/ta-p/4049321
[4] https://whitepapers.theregister.com/
True I suspect this will cause a problem with forescout and pulse NAC. Also maybe other network discovery tools which base the results on MAC addresses, as upto now its been about the only static fingerprint for networked devices. Oh and thinking of it, it will potentially cause problems with DHCP if for some reason you are assigning static IP addresses to iOS and Android devices, not commonly done but maybe for VIPs in large organisations. Assigning static IP addresses and allowing URL filtering rules and firewall rules based on an IP is easier than going down the whole rule of user authentication on devices or full blown NAC functionality.
Yet another elastoplast with unexpected consequences?
The whole purpose of MAC addresses (and indeed IP addresses) is reliable identification of devices - primarily for directing traffic of course, but with the beneficial spin-offs of providing a measure of confidence in the remote end of the connection being what you think it is and of a certain level of access control. This inevitably implies traceability, which is s good thing, unless abused. So it's the abuse, not the mechanism we should be trying to eliminate.
Randomising MAC addresses is a clumsy kludge solution to the abuse that has detrimental side effects. The fact that this kit is not good at handling the kludge is not ideal, but the abuse is the primary problem.
Re: Yet another elastoplast with unexpected consequences?
The whole purpose of MAC addresses (and indeed IP addresses) is reliable identification of devices
but as we all know, the side effect is that the likes of Google, Amazon, Facebook, NSA etc etc
can track you everywhere you go with that simple old MAC Address. With IPV6, it will be even easier as NAT'ing will be a thing of the past (or so I've been told)
The randomisation is an attempt to give those data slurpers one less tracking vector to use as the suck the life, sorry data out of your IT kit but yes it presents a who different set of problems when trying to secure a network.
Re: Yet another elastoplast with unexpected consequences?
Okay, can you explain how Google, Facebook and Amazon can track via a MAC address?
Re: Yet another elastoplast with unexpected consequences?
The MAC address is only seen in the layer 2 broadcast domain the host connects to.
As soon as the host requests a resource that is not available on the broadcast domain it resides on it sues IP addressing, and with each hop across the various networks the traffic goes, the source and destination MAC addresses will change (to be the ingress and egress interfaces MAC addresses of that layer 2 broadcast domain).
TL:DR
Which basically means:
Unless 'the likes of Google, Amazon, Facebook, NSA etc etc' own (of have access to) the AP you are connecting to, they're unlikely to see you MAC address.
The big issue here is connecting to your office environment and the supporting of that.
If you believe that someone with the resources of 'the likes of Google, Amazon, Facebook, NSA etc etc' would be using the MAC address to track you is ludicrous, I can see the argument about companies tracking you, but for a lot of public WiFi you need to register anyway!!!
In short, from a security perspective, yes it is better then nothing, but they should have an option to be able to set a MAC address for a SSID so that when you go to your trusted networks, such as work and home or VPN, it will cause less issues (and allow of the use of Dynamic ARP Inspection and other LAN security measures) and randomly set it for any network that you select to be 'public'.
The latter where being the default maybe?
Re: Yet another elastoplast with unexpected consequences?
Indeed. It's the OS vendors that need to address this. Fine, allocate different MAC addresses to different SSIDs, or allocate randomised SSIDs to certain stored network connection profiles, but they have to allow a fixed MAC for especially trusted networks.
Re: Yet another elastoplast with unexpected consequences?
But they do allow. At least in Android, you can still switch to the real device MAC address in the wireless network profile. Furthermore, if the device is company-issued, there are policies you can pre-apply to it (and I know this works in iOS as well) in order to not randomize the MAC address when connecting to company WiFi. For the public WiFis, I actually see it as a good thing, no reason to not randomize it. Same thing BTW goes with Windows 10, as it does the exact same thing now by default with every wireless connection.
If you need to set a security profile for a device or reserved DHCP then there are a few ways to do it.
You could use different SSIDs for different security profiles but you'll rapidly run out of these when you have multiple security profiles, you need to use client certificates to identify devices (not so easy if you aren't in direct control of the device) or you need to perform a user login for each network connection (but then how do you ensure that connection is valid as they move from AP to AP without excessive logins?).
So you need some kind of device identifier, and although MACs were never that secure they provided a "good enough" approach for that in certain circumstances as long as you understood the security risks.
If, to avoid tracking, you can't identify a device is the same device that you saw a minute ago, an hour ago, a week ago, etc then it does create a bit more of an issue for secure traversal of systems unless you have control of the device and can use client certificates. It's a tough nut to crack, but I'm not an expert in this area so I might be missing something.
Assuming one MAC per SSID "forever" on a device, then that's less of an issue?
Problems arise in corporate BOYD setups - so full enrollment needs to be completed on main network, not a separate setup network as the MAC address changes between the two. MAC address needed to associate user to device so can track problems/faults/access. Some of these systems will need wholesale changes to be able to do this?
Not just a Cisco issue, this is going to cause havoc for any vendor of Network Access Control that's keying the device off the MAC address
At least Apple backed away from their original proposal to periodically change the MAC address within an SSID. That would make managing wireless utterly horrific.