MAC Authentication - Bad Idea?
Greetings, Still a newbie, but getting there... (Alan, do you ever sleep?) I have been asked to implement MAC authentication for a local service provider with a Canopy radio network and MikroTik routers. No, really. I was able to test this and received Accept-Accept after placing the MAC address in the UserName (Password is ""), but had to set Auth-Type := Accept. I haven't found much in the way of documentation regarding MAC authentication in some of the "dated" books I have on Radius and 802.1x, nor in the FreeRadius docs. The goal is to provide for different classes of service, bandwidth management, accounting, etc. I imagine some of this can be done through vendor specific attributes to dynamically configure the routers (VLANs, data rates, priority queues and such), based on which group a user belongs. Dumb question #1: Just because you can do a thing, it doesn't mean you should. Can someone give me the "you idiot" speech and talk me out of this? Deploying client certificates to every device in their network seems an administrative nightmare. Using usernames/passwords doesn't make sense since most devices will always be connected. In the days of dial-up, users understood having to "login" to connect. Today, not so much. So, are there better alternatives? Or am I still just a clueless newbie? Thanks for your patience, Jim
Jim Rice wrote:
Still a newbie, but getting there... (Alan, do you ever sleep?)
In a word: no.
I have been asked to implement MAC authentication for a local service provider with a Canopy radio network and MikroTik routers. No, really.
I was able to test this and received Accept-Accept after placing the MAC address in the UserName (Password is ""), but had to set Auth-Type := Accept.
Hmm... that's probably not the best way to do it, but if it works... I'd like to write a "MAC auth howto" guide for NAS implementors. It will mostly say "you're doing it wrong". Which isn't much of surprise, I guess.
I haven't found much in the way of documentation regarding MAC authentication in some of the "dated" books I have on Radius and 802.1x, nor in the FreeRadius docs.
It all depends on what the NAS sends, unfortunately. And every NAS sends something different.
The goal is to provide for different classes of service, bandwidth management, accounting, etc. I imagine some of this can be done through vendor specific attributes to dynamically configure the routers (VLANs, data rates, priority queues and such), based on which group a user belongs.
Dumb question #1: Just because you can do a thing, it doesn't mean you should. Can someone give me the "you idiot" speech and talk me out of this?
Do MAC auth. Really. It's not hard, and it's useful. The main thing is to normalize the MACs from the NAS before you look them up in the DB. Again, every NAS sends something different.
Deploying client certificates to every device in their network seems an administrative nightmare. Using usernames/passwords doesn't make sense since most devices will always be connected. In the days of dial-up, users understood having to "login" to connect. Today, not so much.
So, are there better alternatives? Or am I still just a clueless newbie?
Do MAC auth. Wait 2-3 years, upgrade to 802.1X everywhere. Alan DeKok.
Thanks, Alan. The MikroTik routers can be configured to send a variety of MAC address formats, the default is XX:XX:XX:XX:XX:XX It can also be set to include the same MAC address in the Password field, instead of NULL, but I do not see any added benefit to that.
but had to set Auth-Type := Accept.
Hmm... that's probably not the best way to do it, but if it works...
Is there a best (or better) way? Do I need to be concerned with MAC spoofing? Thanks again, Jim
What about ppp based auth? Many providers in the US still use this for xDSL service. If the CPE supports it, it's usually transparent to the users. G -----Original Message----- From: freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org [mailto:freeradius-users-bounces+ggatten=waddell.com@lists.freeradius.org] On Behalf Of Jim Rice Sent: Wednesday, February 02, 2011 1:15 PM To: FreeRadius users mailing list Subject: Re: MAC Authentication - Bad Idea? Thanks, Alan. The MikroTik routers can be configured to send a variety of MAC address formats, the default is XX:XX:XX:XX:XX:XX It can also be set to include the same MAC address in the Password field, instead of NULL, but I do not see any added benefit to that.
but had to set Auth-Type := Accept.
Hmm... that's probably not the best way to do it, but if it works...
Is there a best (or better) way? Do I need to be concerned with MAC spoofing? Thanks again, Jim - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
We implemented MAC authentication with netreg at http://netreg.sourceforge.net. We used DHCP/DNS/HTTP piece from netreg. It's essence is DHCP/DHS/HTTP on one server. Basically there will be a vlan we called sandbox with ip helper-address pointing to sandbox.foo.edu. The DHCP is configured to have DNS pointing to sandbox.foo.edu too. bind is configured to resolve everything to sandbox.foo.edu. HTTP is configured with dynamic webpage as explained later on. The logic is like the following if (mac not in your database ) { send back a sandbox vlan #user open any webpage will get redirected to single server } else if (mac in your database) { if (user blocked ) { sendback sandbox VLAN } send back regular vlan name with additional attribute as you want } On the web server, if you are here, you are either unregistered or registered but blocked. We have dynamic webpage to do the following things #mac not registered #user webpage to get IP, then use IP to get MAC from DHCP lease file if (MAC not in database ) { webportal of login with (ldap, ssh, ftp) backend, mac address will be populated in the database. } #mac in database but blocked else { display the mac is blocked and call helpdesk } We use this to gain a lot of knowledge/experience on dot1x, and are now moving toward 802.1x. Schilling On Wed, Feb 2, 2011 at 2:15 PM, Jim Rice <jmrice6640@yahoo.com> wrote:
Thanks, Alan.
The MikroTik routers can be configured to send a variety of MAC address formats, the default is XX:XX:XX:XX:XX:XX
It can also be set to include the same MAC address in the Password field, instead of NULL, but I do not see any added benefit to that.
but had to set Auth-Type := Accept.
Hmm... that's probably not the best way to do it, but if it works...
Is there a best (or better) way?
Do I need to be concerned with MAC spoofing?
Thanks again,
Jim
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Thanks for the tip, Schilling. We wanted to provide a "splash page" for unauthenticated access attempts. This helps to answer a whole other list of questions on "how" to do that. Jim --- On Wed, 2/2/11, schilling <schilling2006@gmail.com> wrote:
From: schilling <schilling2006@gmail.com> Subject: Re: MAC Authentication - Bad Idea? To: "FreeRadius users mailing list" <freeradius-users@lists.freeradius.org> Date: Wednesday, February 2, 2011, 11:32 AM We implemented MAC authentication with netreg at http://netreg.sourceforge.net. We used DHCP/DNS/HTTP piece from netreg. It's essence is DHCP/DHS/HTTP on one server. Basically there will be a vlan we called sandbox with ip helper-address pointing to sandbox.foo.edu. The DHCP is configured to have DNS pointing to sandbox.foo.edu too. bind is configured to resolve everything to sandbox.foo.edu. HTTP is configured with dynamic webpage as explained later on.
The logic is like the following if (mac not in your database ) { send back a sandbox vlan #user open any webpage will get redirected to single server } else if (mac in your database) { if (user blocked ) { sendback sandbox VLAN } send back regular vlan name with additional attribute as you want }
On the web server, if you are here, you are either unregistered or registered but blocked. We have dynamic webpage to do the following things #mac not registered #user webpage to get IP, then use IP to get MAC from DHCP lease file if (MAC not in database ) { webportal of login with (ldap, ssh, ftp) backend, mac address will be populated in the database. } #mac in database but blocked else { display the mac is blocked and call helpdesk }
We use this to gain a lot of knowledge/experience on dot1x, and are now moving toward 802.1x.
Schilling
On Wed, Feb 02, 2011 at 11:15:13AM -0800, Jim Rice wrote:
Do I need to be concerned with MAC spoofing?
It's easy to do, so it will probably happen; this risk is weighed against providing a service which is easy for your customers to use. What happens if two people try to use the same MAC address simultaneously on your wireless network? I suspect it will break service for both of them, which means that it's actually not very useful for freeloading. They'd have to coordinate to use it at different times. You could also look for simultaneous users in your RADIUS accounting logs. Regards, Brian.
On shared medium, I don't *think* dupe macs will cause much problem, unless maybe a congestion algorithm tweaks traffic to/from that mac. I'm not an expert in that area, just speaking from experience. ----- Original Message ----- From: Brian Candler [mailto:B.Candler@pobox.com] Sent: Wednesday, February 02, 2011 01:53 PM To: FreeRadius users mailing list <freeradius-users@lists.freeradius.org> Subject: Re: MAC Authentication - Bad Idea? On Wed, Feb 02, 2011 at 11:15:13AM -0800, Jim Rice wrote:
Do I need to be concerned with MAC spoofing?
It's easy to do, so it will probably happen; this risk is weighed against providing a service which is easy for your customers to use. What happens if two people try to use the same MAC address simultaneously on your wireless network? I suspect it will break service for both of them, which means that it's actually not very useful for freeloading. They'd have to coordinate to use it at different times. You could also look for simultaneous users in your RADIUS accounting logs. Regards, Brian. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font>
I think it depends on the OS, if a OS is trusting and accepts everything up the stack from Layer 2 if the MAC address matches it could start to get confused and cause all sorts of issues. If the device keeps some kind of state table for connections and rejects all others there may not be to much of an issue. Naturally in the switched environment it would not work at all. As far a Mac auth, we do that here as well, basically for printers and such and as you stated you just enter the MAC address for the password then push out the tunnel Group ID, tunnelmediumtype and tunnel-type. Of course this is on a switched network but for our Wireless it works remarkably similar yet again we use username/password authentication on that. We do not have to worry to much about session hijacking or MAC spoofing on the wireless side because we use WPA2 with AES and dot1x on the auth side. One thing you may want to do is have a default unprotected vlan that is the default network, have it go directly web page with instructions on connecting with a secure connection. If you care anything about your users/customers I would say at least offer them some kind of protection, it is just to easy to sniff unprotected wireless networks. -- Brett Littrell Network Manager MUSD CISSP, CCSP, CCVP, MCNE
On Wednesday, February 02, 2011 at 12:00 PM, in message <8860_1296676852_4D49B7F4_8860_589_1_D9B37353831173459FDAA836D3B43499AF0FA683@WA PMBXV0.waddell.com>, Gary Gatten <Ggatten@waddell.com> wrote: On shared medium, I don't *think* dupe macs will cause much problem, unless maybe a congestion algorithm tweaks traffic to/from that mac. I'm not an expert in that area, just speaking from experience.
On Wed, Feb 02, 2011 at 02:00:52PM -0600, Gary Gatten wrote:
On shared medium, I don't *think* dupe macs will cause much problem, unless maybe a congestion algorithm tweaks traffic to/from that mac. I'm not an expert in that area, just speaking from experience.
Layer 1 ------- I have little experience with radio, and if it's a single radio cell with omnidirectional antenna it might not make much difference (*). Layer 2 ------- With switches: they learn which port "owns" the MAC address, and then only send traffic to the latest seen port. If it keeps changing, there will be substantial packet loss. Layer 3 ------- If two people are on the same IP address then of course that will mess things up royally, so one will have to manually choose a different one. Now, if two different IPs share the same MAC address, it will usually work unless one of the devices has IP forwarding enabled. If they do, then when terminal A sees frames for B's IP address will forward them to its default route. The router will then re-send the packet to B, and hence you will get a storm of duplicate packets (multiplied by the TTL). Regards, Brian. (*) If the radio station has multiple antennas to beam the signal in the correct direction, I imagine it might not work well if it sees the same client in two places at once.
Jim Rice wrote:
The MikroTik routers can be configured to send a variety of MAC address formats, the default is XX:XX:XX:XX:XX:XX
Which isn't the format recommended by the RFCs <sigh>.
It can also be set to include the same MAC address in the Password field, instead of NULL, but I do not see any added benefit to that.
There isn't much benefit... but both are bad ideas.
but had to set Auth-Type := Accept. Hmm... that's probably not the best way to do it, but if it works...
Is there a best (or better) way?
Not really, unfortunately.
Do I need to be concerned with MAC spoofing?
Of course. Alan DeKok.
participants (7)
-
Alan Buxey -
Alan DeKok -
Brett Littrell -
Brian Candler -
Gary Gatten -
Jim Rice -
schilling