I think assigning a new EAP Type for an existing EAP method with different usages intended for a particular tunneling method is a bad idea. Can we avoid it?
Since the Intended status of this draft is Informational, I think adding an IESG Note describing the issue recognized by the IESG may be ok. Thanks, Yoshihiro Ohba On Thu, Feb 05, 2009 at 02:27:39PM -0800, Nancy Cam-Winget (ncamwing) wrote: > Hi, > > Per the potential notes and given feedback thus far, we (the authors) > can address the relevant concerns with updates to the draft(s) as > follows: > > 1. Update the EAP-FAST provisioning draft to change EAP-MSCHAPv2 to > EAP-FAST-MSCHAPv2 throughout the document where the reference is to its > working inside the EAP-FAST tunnel during anonymous provisioning mode. > Also clarify the use of EAP-FAST-MSCHAPv2 during anonymous provisioning > in section 3.2.3 > > 2. The following text could be added either in the introduction or IANA > considerations (or anywhere the IESG prefers): > "EAP-FAST has been implemented by many vendors and it is used in the > Internet. Publication of this is intended to promote interoperability. > The reuse of EAP-MSCHAPv2/EAP-GTC EAP method IDs with different meaning > and behavior inside the tunnel method might cause problems in some > environments. If EAP-FAST were to be designed today, these difficulties > could be avoided by the assignment of new EAP Type codes, which was more > difficult before RFC 3748 defined expanded EAP Types. The reuse may > cause problems in implementations where the use of unaltered methods is > required. It also can make implementations that use methods both within > and outside of the tunnel method more difficult, since this support > requires special case execution of these methods within a tunnel. Given > these issues, assigned method types must not be re-used with different > meaning inside tunneled methods in the future." > > Thanks, > Nancy. > > > -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Jari Arkko > Sent: Thursday, February 05, 2009 1:01 AM > To: Bernard Aboba > Cc: emu@ietf.org > Subject: Re: [Emu] Potential Notes in EAP-FAST Documents > > Bernard, > > > c. EAP negotiation issues. Neither the IESG note nor the text > > explicitly states what is wrong with using an EAP Type Code for > > incompatible versions of an EAP method that does not support version > > negotiation. > > They should state this. > > > Indeed, it would appear that some > > members of the IESG think that method overloading is required by EAP > > tunneling methods desiring to incorporate support for cryptographic > > binding. > Not sure who you are referring to, but for the record I at least do not > believe that. Cryptographic binding can clearly be achieved without > overloading or re-definition of behaviour of existing components. > > > Saying that this "might be difficult > > in some software environments" isn't a good characterization. > > Would the IESG use the same words to describe the reuse of IP protocol > > > numbers within an IP tunnel? I doubt it. > > I guess this referred to the difficulty of implementing the remedy where > EAP within a tunnel is different from EAP outside the tunnel. In some > cases this would be possible, in some other cases not... depending on > what the software architecture, APIs, etc are. But in all cases it is > painful, which is why this is a bad approach and should not be done by > future methods. > > Jari > > _______________________________________________ > 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 > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
