Alan: Please see responses inline below.
On 5/16/11 9:02 AM, "Alan DeKok" <al...@deployingradius.com> wrote: > Sam Hartman wrote: >> I'd like to confirm that code is in use both by implementations of >> eap-fast v1 and v2. > [HZ] Yes. Type Code 43 is being used by EAP-FAST v1 and widely deployed. > As a backup question: Are there *any* implementations of v2? > [HZ] Not right now. Once this draft is finalized, it will be. > The draft does not make it clear if this is the case. Can the authors > step in and give their opinion? > >> Does the current text mandate support for eap-fast v1 as well as v2? > [HZ] The draft doesn't mandate support for v1 and v2, it's up to each implementation. How, ever, due to the small changes from V2 to v1, I suspect most of them could support both easily. Doesn't running code mean something in IETF? > Yes and no. Section 3.1 says: > > The version negotiation procedure guarantees that the EAP-FAST peer > and server will agree to the latest version supported by both > parties. If version negotiation fails, then use of EAP-FAST will not > be possible, and another mutually acceptable EAP method will need to > be negotiated if authentication is to proceed. > > This makes it *possible* for an implementation to support v2 only. > This will require starting version negotiation for EAP-FASTv2, and then > switching to a different EAP method. > > Implementations traditionally have found it difficult to start one EAP > method, and then to switch to another one. This means that v2-only > implementations may be difficult to deploy in practice. > [HZ] Agree. Considering all devices out there supporting EAP-FASTv1 and it may take a while for them to support the new method, most server implementations would probably support both. >> Is it expected that most implementations will support v1 and v2? >> [HZ] See above. >> Is it desired that people be able to create a v2 only implementation? > > I will partially avoid those two questions, and say that it should be > possible to deploy only the EMU tunneled method. [HZ] Realistically, until the new tunnel method is published and adopted by all servers and supplicants, implementation would have to support older tunnel methods, including EAP-FASTv1. By retaining the EAP-FAST type, customers wouldn't have to be educated with another new EAP type and validate its security, and they would have a smoother migration path, from v1 to v2. Implementers could reuse the same code. I thought one of the reasons EAP-FASTv2 is adopted is because of its existing code and deployment, with small changes to meet EMU requirements. Changing the method name and type would totally negativate that. > > Alan DeKok. > _______________________________________________ > 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
