Hi, > As for security, I think the majority of the Internet community > expects all of the standards setting bodies to put good security high > on their list of things to care about. While the comment that > EAP-TTLS can be just as dangerous in letting credentials out, there is > one major difference from my point of view. No where that I have seen > in the EAP-TTLS specifications did I ever see any hint that the > supplicant could (or should) operate in a mode where the certificate > isn't verified. For EAP-FAST provisioning anonymous provisioning is > clearly spelled out as a possible mode of operation. By allowing > things to be published like that without anyone calling attention to > the related security issues seems like a bad idea. Further it bothers > me more when I see a NIST document that indicates that EAP-FAST is the > best choice for a secure, but easy to deploy, EAP method.
I agree with Chris here. There is a substantial difference between TTLS and FAST. In TTLS, the server will present a certificate and the user *can* verify his EAP peer unambiguously (whether or not he actually does that is another question). With FAST, and Chris' description of the possibility of sniffing and faking A-IDs etc., the user *can not* verify that his EAP peer is genuine. This is a qualitative difference, and I am very much against ignoring it. With Chris' claims I can not, for example, suggest eduroam participants to use EAP-FAST for their mutual authentication needs. > I agree. It was not my intention to claim that all issues were of > equal importance. There are obviously cases where decisions were made > and released to the wild. My goal by listing all of the issues I did > was to attempt to start a conversation and allow the important issues > to rise to the top. Ultimately I want to see the use of EAP continue > to be successful, but also to be secure. I figured I either had to > put the issues (as I see them) out there and try to be part of the > solution, or ignore them and just hope it works out. I would prefer > to be part of the solution where possible. My top list definitely has "problems in genuinely identifying the EAP peer" as a major bullet point. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
