Hi
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 :)
That's what I meant. You could actually map this to a virtual interface (a signaling channel) and put the whole mobility things, network and service discovery, etc. on it: handoffs, mDNS, UPnP, whatever, to discover where you are and what it is. All that signed / encrypted with the authentication keys, previously established. Fine for an enterprise and technically this is not a problem. But it is not wanted, for two reasons: 1. The IETF's EAP-WG does not want it. EAP is authentication, not a generic transport. You could come up with something simular and standardize it through IEEE and IETF, ok. but there is problem nr 2: 2. Even if it is ok for an Enterprise network, it is not ok for the Internet, which IETF is responsible for. It means indeed a different access model. The local provider becomes a bit too mighty in this configuration, so it cannot become a generic standard. This has been recently discussed at HOKEY, I believe. artur