Phil Mayers <p.mayers <at> imperial.ac.uk> writes:
On 05/01/15 12:24, Nick Lowe wrote:
Do these switches or APs not use a Service-Type of Call-Check when performing MAC auth then? I would be barking at the vendor if that was missing.
No, they do not.
Indeed not. The initial request from these devices looks like this: ---- start packet capture ---- No. Time Source Destination Protocol Length 1 2014-12-01 10:39:32.199374 192.168.1.1 192.168.1.10 RADIUS 179 Access-Request(1) (id=5, l=137) Frame 1: 179 bytes on wire (1432 bits), 179 bytes captured (1432 bits) on interface 0 Ethernet II, Src: d4:d7:48:cc:12:bb (d4:d7:48:cc:12:bb), Dst: 64:70:02:00:0e:aa (64:70:02:00:0e:aa) Internet Protocol Version 4, Src: 192.168.1.1 (192.168.1.1), Dst: 192.168.1.10 (192.168.1.10) User Datagram Protocol, Src Port: 49205 (49205), Dst Port: 1812 (1812) Radius Protocol Code: Access-Request (1) Packet identifier: 0x5 (5) Length: 137 Authenticator: 542300005b6100000c620000093c0000 [The response to this request is in frame 2] Attribute Value Pairs AVP: l=6 t=NAS-IP-Address(4): 192.168.1.1 AVP: l=6 t=NAS-Port-Type(61): Ethernet(15) AVP: l=6 t=NAS-Port(5): 50 AVP: l=14 t=User-Name(1): c82a1437e57c AVP: l=10 t=Acct-Session-Id(44): 05000009 AVP: l=19 t=Called-Station-Id(30): D4-D7-48-CC-12-BD AVP: l=19 t=Calling-Station-Id(31): C8-2A-14-37-E5-7C AVP: l=19 t=EAP-Message(79) Last Segment[1] AVP: l=18 t=Message-Authenticator(80): 54999f6bb3769ecfd65a71d3dfb08400 ---- end packet capture ----
It's been a while since I looked, but doesn't it incur another round-trip?
Yep. Plain MAC-auth is two packets only: 1) Access-Request, followed by either 2) Access-Accept or Access-Reject. The EAP dialog is four packets: 1) Access-Request 2) Access-Challenge 3) Access-Request 4) Access-Accept or Access-Reject. Why interpret the Tunnel-Filter-Group-ID returned later only when a full EAP dialog has taken place? (Which was the initial problem.) In fact the switches correctly react to an Access-Accept or Access-Reject, but don't set the VLAN correctly without EAP. In fact I have a call open with Cisco about this, and it would now be great if I had some strong arguments why using EAP here is just sick, or why some things only work with EAP while the rest also works out-of-the-box. But they can always say "hey, we believe it is a valid approach, and we documented it like this, so what's the problem?". Maybe one can nail them with an RFC but I haven't found anything yet. I believe one strong argument is that their own IOS devices use MAC auth ("bypass") as plain RADIUS MAC authentication. Currently, for whoever encounters this in the future, I have solved the situation on the radius server like this (in the site definition): ---- start unlang ---- authorize { ... if (EAP-Message) { eap Cleartext-Password := "%{User-Name}" } } else { update control { Auth-Type := Accept } } update reply { Tunnel-Type := VLAN Tunnel-Medium-Type := IEEE-802 Exec-Program-Wait = "/usr/bin/php /home/nac/test2b.php %{NAS-IP-Address} %{NAS-Port} %{User-Name}" } ... } ---- end unlang ---- (I accept everything, I only want the correct VLAN to be set, which potentially is a "blackhole" VLAN.)