Slashdot Mirror


Using DHCP for Authentication?

gwhiteacre asks: "I have been asked to assist a small TelCo that has recently begun acting as an ISP for it's customers having DSL and Cable connections. They currently use the DHCP config file as their authentication database. They add/del/mod the mac address in the config file for each change, stop and start the dhcpd, and are rapidly discovering that this is not a scalable or sustainable approach. I have spent several days researching alternate forms of DSL/cable authentication and am not finding much. My current 'best thoughts' are to put a wrapper around DHCP to intercept the request, check a database, and then call dhcpd. Has anyone dealt with this or a similar issue, and can point me in a good or alternate direction."

8 of 69 comments (clear)

  1. PPP by dago · · Score: 5, Insightful

    See the subject.

    It can assign ip adress, includes secure scheme for authentifications, well implemented, easily integrated with radius for more advanced stuff (DB, accounting, ...). It works over almost anything (ethernet, atm, ...).

    --
    #include "coucou.h"
  2. Just add the features you need to dhcpd by ChadN · · Score: 4, Insightful

    Well, I have to infer a lot of what you want, but why not just hack on the dhcpd source to make it more scalable? Allow it to automatically process updates of the config file, using some locking method to keep things sane (or check a database that you control, for updates)

    I'm assuming the main performance issue to address is the shutdown/update/startup cycle, which you could eliminate. Other performance issues could also be addressed if need be; it is open source after all.

    --
    "It's overkill, of course. But you can never have too much overkill." - Anonymous Slashdot Coward
    1. Re:Just add the features you need to dhcpd by sql*kitten · · Score: 3, Insightful

      Well, I have to infer a lot of what you want, but why not just hack on the dhcpd source to make it more scalable? Allow it to automatically process updates of the config file, using some locking method to keep things sane (or check a database that you control, for updates)

      Umm, because he's in the ISP business, not the software development business?

      Let me give you an example: Boeing probably have some fairly strong ideas about what sort of fuel you should put in their aircraft, but you won't see them operating oilrigs anytime soon.

      No, they'll get Shell to do that for them, just as the original poster should get RADIUS/LDAP to do it for him.

  3. Don't forget... by Phexro · · Score: 4, Insightful

    That in addition to not being scalable or sustainable, this scheme is not secure, either.

    MAC addresses can be changed via software ('ifconfig ethX hw ether aa:bb:cc:dd:ee:ff:gg'), and this stuff is sent in the clear, opening you up to (at least) denial-of-service and man-in-the-middle attacks.

    Sorry I don't have a suggestion for what you should use.

    1. Re:Don't forget... by Anonymous Coward · · Score: 1, Insightful
      MAC addresses can be changed via software ('ifconfig ethX hw ether aa:bb:cc:dd:ee:ff:gg'), and this stuff is sent in the clear, opening you up to (at least) denial-of-service and man-in-the-middle attacks.

      I'm not too sure about that. Does their DHCP do auth based on the MAC address of the ethernet card or that of the DSL bridge?

    2. Re:Don't forget... by Pointer80 · · Score: 3, Insightful

      DHCP is not designed as an authentication protocol, and probably should not be used as such. From what I read, it seemed like the poster was having scalability problems using DHCP as an authentication protocol, which is to say that he was having problems getting it to do something it wasn't designed to.

      I would have to agree. DHCP was not designed as an authentication protocol, however, for the purpose in question (giving authorized users access to the network), it works acceptably.

      It seems like changing your MAC before you send out the DHCP request would result in a denial-of-service, stealing away the IP of the person who owns the MAC you just set, since the static ARP entry gets added after the DHCP server ACKs the REQ. ...

      You make a vaild point. Keep in mind that you would have to guess the other customer's MAC because sniffing would do no good.

      This is one of the reasons that moving to circuit-id based auth. The customer would never have to worry about their MAC at all.

      Were a malicious user to be able to guess MACs, our tech support guys would be pretty quick to notice a pattern in the complaints (I've setup dhcpd to log circuit-id with each request) and we would deactivate the customers circuit. The other option would be to setup a daemon to watch the log for x number of requests from unknown clients from a specific circuit id.


      Also, note that the poster didn't detail any specific setup like you did, leaving it pretty open for interpretation.


      Again, you're correct. Your comments about scalaability were made with and educated guess about this persons network config as were mine. My point was that DHCP _can_ be effectively, efficiently and securely be used in this environment.

      --
      [%- PROCESS life -%]
  4. Re:DHCP authentication does not work by 1101z · · Score: 2, Insightful

    Well it will because in the cable and DSL world you know from which cable or xDSL "modem", request is comming from. You do not do it by the MAC address of the ethernet card but from the MAC of the "modem" or the what ever it is called ATM address of the xDSL bridge.

    --
    One day people will learn the folly of Winbloze, Linux Rules!
  5. Re:RADIUS? by irix · · Score: 3, Insightful

    Exactly; everybody uses RADIUS. Why the hell would you use DHCP for auth?

    --

    Do you even know anything about perl? -- AC Replying to Tom Christiansen post.