[Emu] Some questions about eap type code and the tunnel method
I'd like to confirm my understanding. The current text proposes the use of eap type code 43. I'd like to confirm that code is in use both by implementations of eap-fast v1 and v2. Does the current text mandate support for eap-fast v1 as well as v2? Is it expected that most implementations will support v1 and v2? Is it desired that people be able to create a v2 only implementation? I think based on answers to these questions I at least will be able to better determine my opinion on the type code issue. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some questions about eap type code and the tunnel method
Sam Hartman wrote: > I'd like to confirm that code is in use both by implementations of > eap-fast v1 and v2. As a backup question: Are there *any* implementations of v2? 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? 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. > Is it expected that most implementations will support v1 and v2? > > 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. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some questions about eap type code and the tunnel method
Alan: Please see responses inline below. On 5/16/11 9:02 AM, "Alan DeKok" 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
Re: [Emu] Some questions about eap type code and the tunnel method
Hao Zhou wrote: >> As a backup question: Are there *any* implementations of v2? >> > [HZ] Not right now. Once this draft is finalized, it will be. OK. That means there are no costs to choosing a new EAP type code. > [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? Speaking as an individual contributor and implementor, I think the v2 draft is a lot clearer than the v1 specification. It looks to be simpler, too. > [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. Again, speaking as an individual, some server software doesn't support EAP-FAST. There have been few complaints so far about that. > [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. See above. > 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 agree that cost of deployment is a factor to consider. > 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. I'm not sure how changing the type code adds deployment costs. The new version has to be deployed no matter what. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some questions about eap type code and the tunnel method
Hi Hao, On Mon, May 16, 2011 7:32 am, Hao Zhou wrote: > 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. After the "vote" I asked several people who did not have a dog in the fight why they did not "vote" for TEAM and the overwhelming response I got was the way TEAM did passwords. It had nothing to do with deployment. regards, Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
I support allocating a new method type for the new standard method, sooner, rather than later. The new method is defined by an IETF group, based on submissions/modifications from multiple parties, and should carry/use an IETF rather than specific vendor identifier. Dorothy On Sat, May 14, 2011 at 6:18 PM, Glen Zorn wrote: > On 5/15/2011 2:36 AM, Sam Hartman wrote: > >> "Alan" == Alan DeKok writes: > > > > Alan> Glen Zorn wrote: > > >> There seem to be two issues here: renaming the draft & allocating > > >> a new EAP type. For which one are opinions being solicited? > > > > Alan> Allocating a new EAP type. > > > > My opinion is that we have two options: > > > > 1) Allocate a new method type now. > > > > 2) Revisit this issue at the end. > > > > I don't think we'll be in a position to decide for sure we can keep the > > method type until we reach WGLC. > > I don't follow your logic here. Allocating a new EAP type is, > practically speaking, nothing. > > > > > However we can always short-circuit the issue early. > > The only question I can see is whether or not emu really is an extension > of the Cisco marketing department. One would like to think that the > answer is obvious but maybe not... > > ... > > ___ > 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
Re: [Emu] Results of consensus call on tunnel method document
On May 16, 2011, at 11:29 AM, Dorothy Stanley wrote: > I support allocating a new method type for the new standard method, sooner, > rather than later. > > The new method is defined by an IETF group, based on submissions/modifications > from multiple parties, and should carry/use an IETF rather than specific > vendor identifier. > [Joe] Just to be clear, EAP-FAST type ID has been allocated from the IETF type space and is not an expanded vendor specific EAP type as defined in RFC 3748. > Dorothy > > On Sat, May 14, 2011 at 6:18 PM, Glen Zorn wrote: > On 5/15/2011 2:36 AM, Sam Hartman wrote: > >> "Alan" == Alan DeKok writes: > > > > Alan> Glen Zorn wrote: > > >> There seem to be two issues here: renaming the draft & allocating > > >> a new EAP type. For which one are opinions being solicited? > > > > Alan> Allocating a new EAP type. > > > > My opinion is that we have two options: > > > > 1) Allocate a new method type now. > > > > 2) Revisit this issue at the end. > > > > I don't think we'll be in a position to decide for sure we can keep the > > method type until we reach WGLC. > > I don't follow your logic here. Allocating a new EAP type is, > practically speaking, nothing. > > > > > However we can always short-circuit the issue early. > > The only question I can see is whether or not emu really is an extension > of the Cisco marketing department. One would like to think that the > answer is obvious but maybe not... > > ... > > ___ > 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
Re: [Emu] Results of consensus call on tunnel method document
Joe, Understood. The "EAP-FAST" protocol and name and type value (from the IETF space) are tied in the market to specific vendor. A new name and a corresponding new IETF type help associate the new standard method with the IETF. Dorothy On Mon, May 16, 2011 at 11:37 AM, Joe Salowey wrote: > > On May 16, 2011, at 11:29 AM, Dorothy Stanley wrote: > > > I support allocating a new method type for the new standard method, > sooner, rather than later. > > > > The new method is defined by an IETF group, based on > submissions/modifications > > from multiple parties, and should carry/use an IETF rather than specific > vendor identifier. > > > > [Joe] Just to be clear, EAP-FAST type ID has been allocated from the IETF > type space and is not an expanded vendor specific EAP type as defined in RFC > 3748. > > > Dorothy > > > > On Sat, May 14, 2011 at 6:18 PM, Glen Zorn wrote: > > On 5/15/2011 2:36 AM, Sam Hartman wrote: > > >> "Alan" == Alan DeKok writes: > > > > > > Alan> Glen Zorn wrote: > > > >> There seem to be two issues here: renaming the draft & > allocating > > > >> a new EAP type. For which one are opinions being solicited? > > > > > > Alan> Allocating a new EAP type. > > > > > > My opinion is that we have two options: > > > > > > 1) Allocate a new method type now. > > > > > > 2) Revisit this issue at the end. > > > > > > I don't think we'll be in a position to decide for sure we can keep the > > > method type until we reach WGLC. > > > > I don't follow your logic here. Allocating a new EAP type is, > > practically speaking, nothing. > > > > > > > > However we can always short-circuit the issue early. > > > > The only question I can see is whether or not emu really is an extension > > of the Cisco marketing department. One would like to think that the > > answer is obvious but maybe not... > > > > ... > > > > ___ > > 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
Re: [Emu] Results of consensus call on tunnel method document
Based on the answers to my questions, I strongly support allocation of a new EAP type code . I think using the existing type code will significantly disadvantage implementations that want to implement the IETF spec but not eap-fast v1. I believe that is highly undesirable. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some questions about eap type code and the tunnel method
It seems too early to decide whether there is a need to change the EAP type at this point. I think there is merit to considering reducing customer education as to why yet another new EAP type is being definedas Hao mentioned, there is also merit to facilitating code reuse and reducing deployment complexity. Changing the type code has implications to the configuration and management interfaces especially on the client side. Nancy. On 5/16/11 7:45 AM, "Alan DeKok" wrote: > Hao Zhou wrote: >>> >> As a backup question: Are there *any* implementations of v2? >>> >> >> > [HZ] Not right now. Once this draft is finalized, it will be. > > OK. That means there are no costs to choosing a new EAP type code. > >> > [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? > > Speaking as an individual contributor and implementor, I think the v2 > draft is a lot clearer than the v1 specification. It looks to be > simpler, too. > >> > [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. > > Again, speaking as an individual, some server software doesn't support > EAP-FAST. There have been few complaints so far about that. > >> > [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. > > See above. > >> > 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 agree that cost of deployment is a factor to consider. > >> > 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. > > I'm not sure how changing the type code adds deployment costs. The > new version has to be deployed no matter what. > > 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
Re: [Emu] Some questions about eap type code and the tunnel method
On 5/16/2011 8:02 PM, Alan DeKok wrote: > Sam Hartman wrote: >> I'd like to confirm that code is in use both by implementations of >> eap-fast v1 and v2. > > As a backup question: Are there *any* implementations of v2? > > The draft does not make it clear if this is the case. Can the authors > step in and give their opinion? I believe that it was stated in Prague that there were no implementations (let alone deployments) at that time, but that Cisco would commit to putting development on their road map. > >> Does the current text mandate support for eap-fast v1 as well as v2? > > 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. > >> Is it expected that most implementations will support v1 and v2? >> >> 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. This seems to me to be a strong argument for a new type code. ... <>___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some questions about eap type code and the tunnel method
On 5/16/2011 7:39 PM, Sam Hartman wrote: > > > I'd like to confirm my understanding. > > The current text proposes the use of eap type code 43. > > I'd like to confirm that code is in use both by implementations of > eap-fast v1 and v2. I'm pretty sure that there are no implementations (except maybe in a lab somewhere) of EAP-FAST v2. > > Does the current text mandate support for eap-fast v1 as well as v2? > > Is it expected that most implementations will support v1 and v2? This question seems to assume an answer. There are 2 ways to look at the question: either the standard tunneled method is EAP-FAST v2 or it is v1 of itself (as yet unnamed -- I suggest "TEAM" ;-). > > Is it desired that people be able to create a v2 only implementation? See above, but my guess is that most vendors would prefer to be able to support the standard tunneled method without also supporting a proprietary tunneled method... > > I think based on answers to these questions I at least will be able to > better determine my opinion on the type code issue. > ___ > 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
Re: [Emu] Some questions about eap type code and the tunnel method
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. ... <>___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Some questions about eap type code and the tunnel method
Hi, > 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. That would speak for assigning a new EAP type code for v2, wouldn't it? EAP method (re)negotiation is well-tested, and known to work across many supplicants. That way, a v2-only implementation wouldn't need to rely on in-EAP-method version negotiation and whacky switching. Greetings, Stefan Winter >> Is it expected that most implementations will support v1 and v2? >> >> 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. > > 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
