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

Comments

arp requests

[dpoulson]

Would it be possible to let dhcp serve out ip addresses, but then have a different program such as arpwatch to watch for new mac addresses, check a database, then disconnect that user. They might have access for a few seconds, but thats all. Any rouge mac addresses deteced can then be reported.

Look at DDNS, too

[dpilot]

As others have mentioned, DHCP has no authentication other than MAC, and MAC is not reliable.

But take a look at the ISC web site, and there has been a lot of work to integrate DHCP with DDNS. In perticular, there is some bleeding-edge work to crytographically secure the DDNS authentication with either symmetric or asymmetric keys. Neither is ready to deploy, though the symmetric key work requires less patching. In your situation, it may be possible for DHCP to only serve DDNS-approved addresses, all others would fail.

Though not ready it may help set a direction for the future.

But even this wouldn't stop a rogue from sniffing your network for others' DHCP packets, and using that information to guess a static IP, and run that way. As much as people dislike PPPoE-type solutions, some form of encapsulation like that or DOCSIS is the only safe way. Another option might be to have everyone run VPN software. Then route the other side of the VPN, and none of the untrusted network. Just another method of encapsulation.