Hi. I've included a survey of tunnel methods that have made it to RFC and TEAP. It's quite possible that people want to cover more tunnel methods in the summary (LEAP, PEAP, EAP-TTLS v1). People who want to supply text are welcome to do so.
After looking at it, I don't feel comfortable volunteering to do the inner method summary. For the more modern methods the answer tends to always be "yeah, nothing wrong there." Now, the method itself may be weaker than you'd like, but the mutual authentication and key handling tends not to be of particular note. At least that seems to be true for the PAKE methods, for GPSK and for revised AKA. Note that is an initial guess, I don't have enough confidence in that statement to go write it down in the draft, and I'm not convinced it's all that useful. As you get into older methods, say EAP-SIM and EAP-MSCHAPV2, it gets more complex. EAP-SIM has some significant challenges with mutual authentication and I think with key generation. Being able to summary more than what is in the eap-sim security considerations section would involve a lot more operational knowledge than I have. I don't even know where to find documentation for EAP-MSCHAPv2. I'm strongly suspecting it's got problems, given its age and attachment to md4 and rc4. However, the mschapv2 PPP extensions got away with a one sentence security considerations section, so it's definitely not just summarizing already current security analysis. So, I don't think what I could do with inner method surveys is going to be helpful enough to write up. I'm dropping that section but if text emerges within the WG I'd be happy to include it. I think though that we're doing a good enough job with security considerations sections for post-RFC 3748 EAp inner methods that we don't need such a summary. _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
