I strongly recommend against publication of these two documents. They represent essentially proprietary hacks on established protocols. The benefit in documenting use of EAP in the Internet today is far outweighed by the damage done to existing protocol specification and implementations. They will serve only to create spagetti code and unnecessary complexity.
In addition to the issues noted by others I will also point out that information is being extracted from TLS for use in (the exchange erroneously described as) "EAP-MSCHAPv2" in a way that is different than the way being proposed by the TLS WG and does not include a binding to the application. I don't believe a stable reference of these proprietary hacks is necessary because the lack of an RFC to reference them has not stopped them from being implemented. Whatever process has been used in the past to convey their specification can be used going forward. draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226 but nowhere in that RFC can I find description of the following label for an initial assignment of repository values: "allocated for management by Cisco" yet the draft instructs IANA to set aside values 11-63 for just that purpose. I think that's very inappropriate. Not only is it telling IANA to cede some of its authority to a large multinational corporation but it is decidedly *NOT* documenting existing use! If this whole exercise is to document existing use then where are the specifications for these PAC attribute types? The recommended note does nothing to stop this kind of abuse in the future because the pain you mention is not felt by the one doing the abuse. To condone one transgression is to invite one thousand more. regards, Dan. On Sun, February 1, 2009 12:46 pm, The IESG wrote: > 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. > > 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
