Alan DeKok wrote:
Artur Hecker wrote:
But the reason for this is the following. In the current best practice, the EAP-Server must never be reachable for clients, while the DHCP server *must* be reachable from client by definition. I.e. only access controllers (part of your infrastructure) speak to the EAP-Server, while your clients speak to the DHCP server.
Yes. That simplifies security a little.
That said, I agree with the underlying strategy. I would have loved to see DHCP integrated with 802.1X from the very beginning. Actually, I would have gone farther and rather proposed a virtual and generic signaling protocol for the session opening, where a client can negotiate all kinds of options with the network on all layers at the same time. This can be easily done with TLV, etc. Then, a provisioning server could not only open the access but also preprovision the client with IP config, proxies to use, existing printers, available servers (SMTP, shares, etc.) etc etc etc, even before it gets IP layer access. That would have been very nice for an enterprise integration. But well.
That's called EAP-TTLS, with extra stuff inside of the tunnel. :)
What's the deal with chaining EAP Methods inside an EAP TTLS tunnel.... could you run EAP-MSCHAPv2 - EAP-TNC - EAP-DHCP (Fictitious EAP type) inside the same tunnel ? Authentication - NAC - Configuration :)
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900