Sam, I think it would be useful to do a partial survey and just say that it is a partial survey. In part I think this would be useful just so that the points that you feel are important for the CB are highlighted. I would be perfectly willing for such a survey to cover only a couple of the most recent EAP methods with a statement that it is a partial survey and stating why.
However I can also understand why you would not want to do this because I would be afraid that the IESG would want to know why it is not a more complete survey. Jim > -----Original Message----- > From: Sam Hartman [mailto:hartmans-i...@mit.edu] > Sent: Sunday, February 24, 2013 10:56 AM > To: Jim Schaad > Cc: 'Sam Hartman'; emu@ietf.org; draft-ietf-emu-crypto- > bind...@tools.ietf.org > Subject: Re: [Emu] crypto binding: why did I want a survey of methods > > 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
