On 5/16/2011 9:32 PM, Hao Zhou 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? Let me get this straight: are you claiming that changing the EAP type will break the "running code" but making the same "small changes" and keeping the same EAP type won't? > >> 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. New devices are created every day. I don't think that it's too much of a stretch to think that device vendors would prefer to support only one tunneled method; after all, isn't that one of the purposes of this exercise? >>> 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. Is the claim here that customers are so stupid that they would deploy a new version of EAP-FAST without validating its security? > Implementers could reuse the same code. This is a non-issue. The same code can be reused regardless of the EAP type. > 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. Again, I'm confused: you wrote above that there are no implementations in existence. If we adopted EAP-FASTv2 "because of its existing code and deployment" then we must certainly be deluded since there is no code and there are no deployments. > Changing the method > name and type would totally negativate that. I suspect that all it would really negate is the marketing opportunity. OTOH, the Cisco marketing machine is truly awesome while the IETF's, not so much ;-). Would vendors (other than the employers of the authors) be more likely to implement EAP-FASTv2 that the IETF Tunneled EAP Method? Would customers be more likely to deploy it? I don't know, but I think that it's worth considering. AFAICT the difference between the two options in terms of development and operational costs is very close to zero, though. ...
<<attachment: gwz.vcf>>
_______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
