Iljitsch van Beijnum wrote: > Let's start with the last question first: there is no discussion of IEEE > 802.1x and why that would be insufficient here.
DHCP requests are broadcast, whereas EAPoL packets are not. Perhaps that makes a difference in certain networks. > ... The other issue is > how the authentication is started. If client is expected to initiate > authentication in the first message, this means it's not possible to > have a client that can seamlessly connect to multiple networks that > require authentication There could be a DHCP response saying "authentication required", which would key the new behavior. > Also, one of the drafts mentions MD5, which is pretty much dead in the > water with a huge hole in the hull right now, it's only a matter of time > until it officially sinks. Using a non-MD5 authentication method would avoid security issues such as broken MD5, and harvesting hashes of credentials. > Further, I'd like to see a more general mechanism. Another situation > where users need to provide credentials that can benefit from better > standards are wifi hotspots. This situation is largely similar to the > DSL situation with the exception that there is often no direct > relationship with the operator of the hotspot and the user, so the user > must either select a roaming partner and provide credentials appropriate > for that roaming partner, or use some other interactive method to gain > temporary access (scratch cards, credit card transactions). Most users at hotspots have figured this out already. They select a roaming partner, and get redirected to a branded login page. This appears to be sufficient for most purposes. > This suggests that a mechanism where unauthenticated users are given > temporary access to a walled garden and then full access at some later > point would be more appropriate than a simple success/fail > authentication method. Hotspots do this already. Many switches have "default VLAN" fallbacks for unauthenticated (802.1x) users. I don't think any new technology is needed here. Alan DeKok. _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
