On Friday, May 26, 2006 05:23:24 PM -0400 Sam Hartman <hartmans-ietf@xxxxxxx> wrote:
"Narayanan," == Narayanan, Vidya <vidyan@xxxxxxxxxxxx> writes:Narayanan,> I fully agree. As far as I can tell, using EAP in this Narayanan,> manner merely reduces it to a posture transport Narayanan,> protocol. The level of security provided by EAPoUDP Narayanan,> does not seem to be any greater than a kerberos-based Narayanan,> authentication done today in most enterprise networks, Narayanan,> considering the presence of switched ethernet. Hence, Narayanan,> the only reason to move to EAPoUDP would be to check Narayanan,> posture and I agree with Sam that making EAP the Narayanan,> posture transport protocol is a bad idea. There are a number of cases where Kerberos is used in a manner similar to radius/diameter, but that's really more for convenience to have your passwords in one place than because you're making good use of Kerberos. You're not making bad use of Kerberos per se, but you certainly could be providing a lot better security.
I prefer not to ever describe those use cases as "using Kerberos for authentication". It's really using passwords for authentication, where password verification happens to be done by obtaining and validating a Kerberos ticket, instead of by computing a hash a la unix passwd, or looking them up in an LDAP database.
That form of authentication provides a limited level of security, and it doesn't provide keying material for IPsec or link-layer security. Using EAP over UDP with passwords (I admit, I can't remember if a password-based EAP mechanism even exists) doesn't provide much more.
However, there are two distinct advantages to be gained by running some form of EAP over UDP instead of the current usurp-HTTP techniques that are so widely deployed. The first is the existance of a standard means of authentication, which means my workstation can prompt me for the username and password needed to access the network. Compare that to the current model, where I get an environment in which a bunch of things are broken because the system thinks I have network connectivity when I really don't, and then have to start up a web browser and navigate some broken authentication UI that's different for every network I connect to.
The second advantage is that it provides a clear path to replacing password-based authentication with _real_ Kerberos, or whatever else people have deployed. From where I sit, that's pretty compelling.
BTW, Carnegie Mellon has a single campus-wide 802.11 wireless network. The access points are completely open, and access to the network is controlled by a combination of pre-registration and authentication via a web page. The mechanism used to actually restrict access to the network is filter between the wireless subnet and the rest of the campus network, which passes only traffic form authorized MAC addresses or to specific services used in the process of authentication and network registration. In that model (which, I admit, has its flaws), the ability to handle authentication for network access using protocols that run on IP is extremely valuable.
-- Jeff _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf