This looks like a good resolution. Thanks Tim. Gabriel
----- Original Message ---- > From: Tim Polk <tim.p...@nist.gov> > To: emu@ietf.org > Cc: "i...@ietf.org IESG" <i...@ietf.org> > Sent: Wednesday, February 11, 2009 6:26:14 AM > Subject: Re: [Emu] Potential Notes in EAP-FAST Documents > > Folks, > > As the AD that sponsored publication of the EAP-FAST documents under > discussion, > I have been trying to find the best way forward. I believe that the best > course > of action > involves some clarifications to draft-cam-winget-eap-fast-provisioning to > distinguish > the modified and unmodified use of EAP-MSCHAPv2, and IESG notes to ensure > these > publications do not establish precedent for future reuse of EAP type codes > with > different semantics. > > First, I support revising draft-cam-winget-eap-fast-provisioning so that the > modified > form of EAP-MSCHAPv2 is consistently referred to as EAP-FAST-MSCHAPv2. The > authors offered to make this change earlier in the thread, and I have seen > some > support and no opposition to this suggestion. > > Second, I will be offering the following text for IESG notes on both > documents. > The > notes clearly state the drawbacks for EAP type code reuse and define an > acceptable > path for future protocol developers. > > ------ draft-cam-winget-eap-fast-provisioning ----- > > EAP-FAST has been implemented by many vendors and it is used in the > Internet. Publication of this specification is intended to promote > interoperability by documenting current use of existing EAP methods > within EAP-FAST. > > The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code assigned to > EAP-MSCHAPv2 (26) for authentication within an anonymous TLS tunnel. In > order to minimize the risk associated with an anonymous tunnel, changes > to the method were made that are not interoperable with EAP-MSCHAPv2. > Since EAP-MSCHAPv2 does not support method-specific version negotiation, > the use of EAP-FAST-MSCHAPv2 is implied by the use of an anonymous > EAP-FAST tunnel. This behavior may cause problems in implementations > where the use of unaltered EAP-MSCHAPv2 is needed inside an anonymous > EAP-FAST tunnel. Since such support requires special case execution of > a method within a tunnel, it also complicates implementations that use > the same method code both within and outside of the tunnel method. If > EAP-FAST were to be designed today, these difficulties could be avoided > by utilization of unique EAP Type codes. Given these issues, assigned > method types must not be re-used with different meaning inside tunneled > methods in the future. > > ---- draft-zhou-emu-fast-gtc ------ > > EAP-FAST has been implemented by many vendors and it is used in the > Internet. Publication of this specification is intended to promote > interoperability by documenting current use of existing EAP methods > within EAP-FAST. > > The EAP method EAP-FAST-GTC reuses the EAP type code assigned to > EAP-GTC (6). The reuse of previously assigned EAP Type Codes is > incompatible with EAP method negotiation as defined in RFC 3748. Since > EAP-GTC does not support method-specific version negotiation, the use of > EAP-FAST-GTC is implied when used inside the EAP-FAST tunnel during > authentication. This behavior may cause problems in implementations where > the use of another vendor's EAP-GTC is required. Since such support > requires > special case execution of a method within a tunnel, it also complicates > implementations that use the same method code both within and outside of > the tunnel method. If EAP-FAST were to be designed today, these > difficulties could be avoided by utilization of unique EAP Type codes. > Given these issues, assigned method types must not be re-used with > different meaning inside tunneled methods in the future. > > I am not under the illusion that this text will be entirely satisfactory to > anyone, > but I believe that it is an *appropriate* resolution to the problem. > > Thanks, > > Tim Polk > _______________________________________________ > 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
