dot1x specification EAPOL-Logoff clarification

[Arran Cudbard-Bell]

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 at sussex.ac.uk)
Authentication, Authorisation and Accounting Officer
Infrastructure Services | ENG1 E1-1-08 
University Of Sussex, Brighton
EXT:01273 873900 | INT: 3900