> Dear EMU WG: > > These two documents are in the RFC Editor queue: > > draft-cam-winget-eap-fast-provisioning-10.txt > draft-zhou-emu-fast-gtc-05.txt > > The IESG has received a very late comment about these documents, and > we seek your input on the proposed resolution. > > The late comment raises a potential interoperability concern with > existing implementations of EAP-MSCHAPv2 and EAP-GTC. > > The draft-cam-winget-eap-fast-provisioning-10.txt document specifies > a very specific way to generate the challenges used in EAP-MSCHAPv2 > that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2 > exchanges. > > The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is > uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST- > GTC > employs a subset of the EAP-GTC formatting. > > The IESG recognizes the difficulties caused by re-use of an EAP Type. > Further, the IESG recognizes the concern about implementations that > might not easily adapt to additional requirements. However, the IESG > also recognizes the significant value in documenting EAP methods that > are implemented and deployed in the Internet today. > > The IESG believes that the right thing to do in this situation is to > proceed with the publication of these documents. However, the IESG > also > sees value in warning future EAP method designers about this experience > so that this pain might be avoided in the future. > > The IESG is considering the additional informative paragraph in the > IANA > considerations section of both documents that says: > > IESG Note: EAP-FAST has been implemented by many vendors and it is > used in the Internet. Publication of this is intended to promote > interoperability, even though the use of the EAP-MSCHAPv2 and > EAP-FAST-GTC EAP methods might be difficult in some software > environments. If EAP-FAST were to be designed today, these > difficulties could be avoided by the assignment of new EAP Type > codes. > > Please provide comments on the proposed way forward.
I am strongly opposed to the publication of these documents as RFCs in their current form. Not only is the "fast provisioning" for EAP-FAST what can only be characterized as a security disaster, but EAP-FAST-GTC has nothing whatsoever to do with the EAP-GTC type. EAP-GTC was "defined for use with various Token Card implementations which require user input" but EAP-FAST-GTC is used solely to transfer a username/password combination, the password in plaintext. It's hard to see what this has to do with actual token cards & appears to be a lazy misuse of an existing type. Furthermore, it's even harder to see how rewarding this kind of nonsense with publication will serve as a warning of any kind; I would expect that the action of publication (with or without IESG note) would be more likely taken as notice that one can do whatever one please without fear. > On behalf of the IESG, > Russ > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
