EAP used for plain MAC authentication?
Hi there, I hope you don't mind if I ask something at first not directly related to freeradius. In fact, we have some of those Cisco SG series small-business switches on which we wanted to implement plain MAC address-based authentication just like with other Cisco IOS gear (Mac Auth Bypass) and also gear from other vendors like Extreme. Now, those Cisco SG devices are also capable of doing dynamic vlan assignment BUT they don't accept any VLAN in return unless a full EAP conversation has taken place, even when only in MAC-auth mode, not in 802.1x. The other gear has no problem accepting a Tunnel-Private-Group-ID attribute in plain mode. Is that something you would say they (Cisco) have to liberty to implement as they wish and I don't understand things clearly, or is it that they didn't understand things clearly when implementing a MAC-based authentication using 802.1x nevertheless. In fact the interesting part of their manual says this: --start quote-- MAC-based authentication is an alternative to 802.1X authentication that allows network access to devices (such as printers and IP phones) that do not have the 802.1X supplicant capability. MAC-based authentication uses the MAC address of the connecting device to grant or deny network access. In this case, the switch supports EAP MD5 functionality with the username and password equal to the client MAC address --end quote-- It's mainly that last sentence that I'm wondering about. In any case this is going to make my life more difficult, as I will have to treat those SG devices differently from all the other gear we have... Thanks for your opinion. Bye, Marki
On 03/01/15 23:16, jm+freeradiususer@roth.lu wrote:
In this case, the switch supports EAP MD5 functionality with the username and password equal to the client MAC address --end quote--
It's mainly that last sentence that I'm wondering about.
Yeah, a couple of vendors do that (Juniper, for example). A "MAC auth" request is sent as an EAP-MD5 request with the username and password as the MAC address. Personally I think this is idiotic at best, and insecure at worst. In particular, if the requests don't contain an attribute to distinguish between EAP-based MAC-auth and real user-based EAP - and some vendors don't - a real user can just set their username and password to their MAC address and waltz right in.
Hi,
Personally I think this is idiotic at best, and insecure at worst. In particular, if the requests don't contain an attribute to distinguish between EAP-based MAC-auth and real user-based EAP - and some vendors don't - a real user can just set their username and password to their MAC address and waltz right in.
tell me about it...we've got about 47 lines of unlang/script to stop that sort of thing :/ (we have a known set of switches/locations where MAB is in use) alan
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. While using an EAP type is rather pointless for MAC address authentication, there isn't an intrinsic problem doing so. I don't think it's idiotic. It's where an appropriate, discriminating Service-Type AVP is missing for CWP auth, MAC auth or something else that it is a problem and you have to shout at the NAS vendor to get it resolved. That's the idiotic part. (But let's not forget it's easy to spoof a MAC address on many devices.) There are other bigger fish to fry too, a bigger issue is where CWP authentication on an AP doesn't use a TLS-based EAP type while carrying user credentials. (While I don't use these personally, many others do. Yes there are other attacks against CWPs but this doesn't negate this.) Nick
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. As for barking at the vendor, in my experience you might as well bark at the moon for all the good it will do. I've wasted enough time with vendors over the last 15 years - they speak money only, I've never once succeeded in getting them to correct a design mis-step on technical grounds.
While using an EAP type is rather pointless for MAC address authentication, there isn't an intrinsic problem doing so. I don't think it's idiotic.
It's been a while since I looked, but doesn't it incur another round-trip?
On Mon, Jan 5, 2015 at 1:16 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
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.
As for barking at the vendor, in my experience you might as well bark at the moon for all the good it will do. I've wasted enough time with vendors over the last 15 years - they speak money only, I've never once succeeded in getting them to correct a design mis-step on technical grounds.
I pointed out to Aerohive that they were missing the Service-Type AVP on all but 802.1X authentication. It got fixed in a subsequent software release.
While using an EAP type is rather pointless for MAC address authentication, there isn't an intrinsic problem doing so. I don't think it's idiotic.
It's been a while since I looked, but doesn't it incur another round-trip?
Yes, you're right, but I think it's subjective if that pushes it in to idiotic territory - I normally reserve that classification for more serious things. I don't think that will tangibly negatively affect many environments. Nick
On 05/01/15 13:23, Nick Lowe wrote:
I pointed out to Aerohive that they were missing the Service-Type AVP on all but 802.1X authentication. It got fixed in a subsequent software release.
That's a welcome change from the norm then.
round-trip?
Yes, you're right, but I think it's subjective if that pushes it in to idiotic territory - I normally reserve that classification for more serious things.
I tend to be rather more critical in my assessment of vendors ;o)
On Mon, Jan 5, 2015 at 1:31 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote: On 05/01/15 13:23, Nick Lowe wrote:
I pointed out to Aerohive that they were missing the Service-Type AVP on
all but 802.1X authentication. It got fixed in a subsequent software release.
That's a welcome change from the norm then
It is probably atypical but it does mean that not all vendors are the same. I have had similar issues with HP in the past and got nowhere at all. I think it's worth trying though, and being persistent. Aerohive have actually been really responsive to the issues that I have raised: I also historically had problems where: - The User-Name AVP would get truncated to 31 characters. - A malformed Called-Station-ID attribute was sent after boot with an empty SSID component until the AP had fully initialized. - Acct-Multi-Session-Id AVP not sent in an ASCII/UTF-8 encoded value. These were fixed in a special build they got to me in a under a week, then rolled in to the next general release. They also added the Acct-Session-Id to the Accounting-On packet they were sending after I pointed out that this strictly broke the spec. In their upcoming 6.4r1 software release they should be fixing other things I've reported: - Framed-IP-Address accuracy/spoofing issue where an AP would use ARP and not DHCP snooped information only to populate the value. - Framed-IP-Address issue where an async Interim-Update would not be sent when DHCP snooped information became available, only picked up on the next regular accounting interval. - Event-Timestamp missing from Accounting-On and Start. Nick
On Jan 5, 2015, at 8:56 AM, Nick Lowe <nick.lowe@gmail.com> wrote:
On Mon, Jan 5, 2015 at 1:31 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 05/01/15 13:23, Nick Lowe wrote:
I pointed out to Aerohive that they were missing the Service-Type AVP on all but 802.1X authentication. It got fixed in a subsequent software release.
I’ve worked with 5-6 of the people at Aerohive. They’re competent.
It is probably atypical but it does mean that not all vendors are the same. I have had similar issues with HP in the past and got nowhere at all.
I’ve been at HP in front of their switch team, giving a presentation about why their product was broken. It took some time, but they fixed everything. It helps to have high-level contacts. Alan DeKok.
On 05/01/15 13:56, Nick Lowe wrote:
It is probably atypical but it does mean that not all vendors are the same. I have had similar issues with HP in the past and got nowhere at all.
I think it's worth trying though, and being persistent.
True. If we ever get one of these devices in production & on support, I might give it a whirl. It would be helpful to have a reference as to why unadorned EAP messages, without a Service-Type, are harmful. Anyone know of one?
On Jan 5, 2015, at 9:23 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
It would be helpful to have a reference as to why unadorned EAP messages, without a Service-Type, are harmful. Anyone know of one?
Nope. There is a “Service-Type = IEEE-802.1X”. That should be used for 802.1X. But not many vendors use it that I’ve seen. Perhaps a better solution would be to have a Service-Type dedicated to MAC authentication. Then it wouldn’t matter what authentication method was being used. Sadly, it’s too late for that. Alan DeKok.
On Mon, Jan 5, 2015 at 2:26 PM, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 5, 2015, at 9:23 AM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
It would be helpful to have a reference as to why unadorned EAP messages, without a Service-Type, are harmful. Anyone know of one?
Nope. There is a “Service-Type = IEEE-802.1X”. That should be used for 802.1X. But not many vendors use it that I’ve seen.
Perhaps a better solution would be to have a Service-Type dedicated to MAC authentication. Then it wouldn’t matter what authentication method was being used. Sadly, it’s too late for that.
Indeed, most vendors will just use a Service-Type of Framed. For MAC auth, assuming it is not being used for something else by a NAS, advice that Call-Check is the most appropriate Service-Type to use as the Calling-Station-Id contains the client MAC address may be helpful. Nick
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.)
Again, On Mon, Jan 5, 2015 at 8:17 PM, Marki <jm+freeradiususer@roth.lu> wrote:
In fact the switches correctly react to an Access-Accept or Access-Reject, but don't set the VLAN correctly without EAP.
I consider this a bug as there should be a separation of concerns here. It is totally unnecessary and a layering violation to couple to 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.
I don't have a problem with EAP being used for MAC auth. A NAS could, for example, use a fixed, constant username and password to perform MAC address authentication, only passing the MAC address in the Calling-Station-Id, instructing that this value should be authenticated using the Service-Type of Call-Check. This is useful as it means you can use a single directory account for MAC auth without having to mess around. I do want to see Cisco implement and support a fixed, constant username and password authentication for MAB in a future IOS release. (As an option.) If a Service-Type is missing, this is a bug where other authentication types are supported as it becomes awkward, hackish and potentially unreliable to discriminate between the type of service being used by a client. It becomes a broken NAS at this point. Nick
On Mon, Jan 5, 2015 at 8:41 PM, Nick Lowe <nick.lowe@gmail.com> wrote:
If a Service-Type is missing, this is a bug where other authentication types are supported as it becomes awkward, hackish and potentially unreliable to discriminate between the type of service being used by a client. It becomes a broken NAS at this point.
Meant to say: If a Service-Type is missing, this is a bug where other RADIUS authenticated service types are supported as it becomes awkward, hackish and potentially unreliable to discriminate between the type of service being used by a client. It becomes a broken NAS at this point. Nick
participants (6)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
jm+freeradiususer＠roth.lu -
Marki
-
Nick Lowe -
Phil Mayers