Wired 802.1X EAPoL supplicant on ISR WAN port

Hi all,

I'm looking for suggestions to enable 802.1X supplicant authentication on a Cisco ISR WAN port.

Scenario:

• My college dorm provides internet access through ethernet ports in every room and requires users to authenticate on the network. When a port comes up, and an endpoint sends a DHCP Discover, the dorm switch - a Cisco C2960X - sends an 802.1X-2010 EAPoL packet requesting identity. A DHCP lease and unmetered internet access are offered when a supplicant successfully authorizes the port using EAP-PEAP-MSCHAPv2 with username and password. IEEE 802.1AE/"MACsec" security is not deployed.
• If no credentials are provided in 5 seconds, the switch sends an 802.1X EAP Failure packet and authorizes and assigns the port to a Webauth VLAN. New DHCP requests are now offered a lease, but all other traffic remains blocked except for DNS and web traffic. The latter is redirected to a web authentication portal; metered internet access is offered upon successful authentication in the portal.
• In any case, the switch only allows one (1) active DHCP lease per switch port. MAC addresses do not need to be registered beforehand. An official FAQ document suggests the use of a router to connect multiple devices, and this is not restricted by the terms of use.

Need: For the end-user, 802.1X authentication provides significant benefits over authentication in the web portal:

• Unmetered internet access. The web portal was introduced many years ago and is still, by far, most used to authenticate, even with its current downgraded status as a fallback method. 802.1X authentication was introduced recently, and due to its current low uptake, migrating metering has not been considered a priority as of today.
• Automated authentication management. Authentication completed on the web portal times out after a set amount of hours, requiring the end-user to authenticate using the portal again. 802.1X authentication times out as well, but renewal is seamlessly handled in the background by the supplicant. This is preferred when there are devices that always need to be reachable from outside the room.

Problem: My previous router, a Ubiquiti EdgeRouter 4, didn't support 802.1X supplicant natively in EdgeOS 2.0 but would allow external Debian packages to be installed, so I deployed wpa_supplicant to authenticate the router using 802.1X. Like the EdgeRouter, the current replacement device, a Cisco ISR1K router running IOS-XE version Fuji-16.09.04, also doesn't natively support 802.1X supplicant on the WAN port [1], and I'm stuck finding a simple and elegant method getting around this.

Ideas, from most elegant, to least:

1. Similar to the solution for EdgeOS, using the guest shell to install wpa_supplicant on IOS-XE. However, initial attempts to launch the guest shell with front panel connectivity crashed the router. Additionally, I'm not sure whether the non-root BusyBox environment suffices for a wpa_supplicant deployment.
2. Reversed LAN/WAN roles. Connect the supplicant-supporting LAN port to the dorm switch and connect the WAN port to my switch. While I think this can be done with heavy tweaking, I'm concerned that it would lead to a lot of undesired complications.
3. Several variations on the same theme involving a physical 802.1X supplicant device between the router and the switch - considered complicated and not elegant due to the need for a second always-on device.
   a) Inversed and beneficial "A Bridge Too Far" attack (DEF CON 19) [2]. Deploy a "SlimShim"/transparent MitM bridge [3] on a Linux device with two network interfaces between the router and the dorm switch. Spoof MAC address of one interface to that of the router, and filter relevant traffic using ebtables [4]. But instead of piggybacking on the authenticated device as the original attack demonstrated, use wpa_supplicant to authenticate and then let the router enjoy unrestricted access on the authorized switch port.
   b) Same as above but with a switch and a computer with wpa_supplicant. Involves caution as not all switches will pass 802.1X frames.
   c) Same as above but with another known 802.1X supplicant such as wpa_supplicant on an EdgeRouter.

[1]. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_8021x/configuration/15-mt/sec-user-8021x-15-mt-book/config-ieee-802x-pba.html#GUID-2C674232-26A2-42DC-A214-DFDB3BB73FCC
[2]. https://www.defcon.org/images/defcon-19/dc-19-presentations/Duckwall/DEFCON-19-Duckwall-Bridge-Too-Far.pdf
[3]. https://mkirby.org/mkblog/?p=403
[4]. https://ebtables.netfilter.org/