EAP used for plain MAC authentication?

[Marki]

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.)