Re: [Emu] Results of consensus call on tunnel method document
It looks like we have rough consensus for a new EAP type. I Agree, that with a new EAP type it makes sense to start the version at 1. I was originally thinking of the SSL 3.0 to TLS 1.0 transition where the protocol version went from 3.0 to 3.1, but in that case TLS did not have an equivalent code point assigned.I'll add these to the list of changes for the next revision. Cheers, Joe On May 30, 2011, at 11:25 PM, Glen Zorn wrote: On 5/31/2011 11:08 AM, Joe Salowey wrote: On May 23, 2011, at 5:50 PM, Glen Zorn wrote: On 5/24/2011 12:53 AM, Joe Salowey wrote: One benefit I see in keeping the same EAP method type code is it allows secure version negotiation from v1 to v2 with version rollback protection. However, moving to a new EAP type code would seem to make EAP method negotiation somewhat better since all implementation may not implement v1. I'm OK with assigning a new EAP method type code, but I'd like to try to maintain some backward compatibility with the v1 versioning in the case that v1 implementations find it advantageous to negotiate the v2 feature set under the v1 type code. None of this seems to me to be relevant to the IETF, the emu WG or the discussion at hand. [Joe] I would hope that negotiation of methods is relevant to the EMU WG. Hmm. I thought we were talking about EAP-FAST version negotiation. Just to be clear, EAP-FAST is not a product of any IETF WG and does not specify a standard of any kind. Furthermore, regardless of the IANA type registration status, EAP-FAST is, in fact, a proprietary protocol; it's publication in RFC 4851 reflects the RFC Series as a vanity press, not the IETF as a SDO. The method that this WG is developing will be a standard, however, and must not be tethered in any way to a proprietary protocol; i.e., backward compatibility with EAP-FAST. Whatever the name of the tunneled method ends up to be, the version number must be one (1). [Joe] A new method name would be good. A new EAP type would be better. If a new EAP type is assigned, how does it make sense to start the version numbering for that type @ 2? How the protocol evolves is up to the working group. Absolutely, but unless the rules have changed rather drastically recently, I'm pretty sure that I'm a WG member... If a vendor wants to track the IETF protocol development for whatever reason so that, for example, v2 of its protocol is equivalent to v1 of the standard then that is their choice, but enabling (let alone encouraging) that behavior is not any of our concern. ... gwz.vcf gwz.vcf ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
On 5/31/2011 11:08 AM, Joe Salowey wrote: On May 23, 2011, at 5:50 PM, Glen Zorn wrote: On 5/24/2011 12:53 AM, Joe Salowey wrote: One benefit I see in keeping the same EAP method type code is it allows secure version negotiation from v1 to v2 with version rollback protection. However, moving to a new EAP type code would seem to make EAP method negotiation somewhat better since all implementation may not implement v1. I'm OK with assigning a new EAP method type code, but I'd like to try to maintain some backward compatibility with the v1 versioning in the case that v1 implementations find it advantageous to negotiate the v2 feature set under the v1 type code. None of this seems to me to be relevant to the IETF, the emu WG or the discussion at hand. [Joe] I would hope that negotiation of methods is relevant to the EMU WG. Hmm. I thought we were talking about EAP-FAST version negotiation. Just to be clear, EAP-FAST is not a product of any IETF WG and does not specify a standard of any kind. Furthermore, regardless of the IANA type registration status, EAP-FAST is, in fact, a proprietary protocol; it's publication in RFC 4851 reflects the RFC Series as a vanity press, not the IETF as a SDO. The method that this WG is developing will be a standard, however, and must not be tethered in any way to a proprietary protocol; i.e., backward compatibility with EAP-FAST. Whatever the name of the tunneled method ends up to be, the version number must be one (1). [Joe] A new method name would be good. A new EAP type would be better. If a new EAP type is assigned, how does it make sense to start the version numbering for that type @ 2? How the protocol evolves is up to the working group. Absolutely, but unless the rules have changed rather drastically recently, I'm pretty sure that I'm a WG member... If a vendor wants to track the IETF protocol development for whatever reason so that, for example, v2 of its protocol is equivalent to v1 of the standard then that is their choice, but enabling (let alone encouraging) that behavior is not any of our concern. ... gwz.vcf attachment: gwz.vcf___ 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 23, 2011, at 5:50 PM, Glen Zorn wrote: On 5/24/2011 12:53 AM, Joe Salowey wrote: One benefit I see in keeping the same EAP method type code is it allows secure version negotiation from v1 to v2 with version rollback protection. However, moving to a new EAP type code would seem to make EAP method negotiation somewhat better since all implementation may not implement v1. I'm OK with assigning a new EAP method type code, but I'd like to try to maintain some backward compatibility with the v1 versioning in the case that v1 implementations find it advantageous to negotiate the v2 feature set under the v1 type code. None of this seems to me to be relevant to the IETF, the emu WG or the discussion at hand. [Joe] I would hope that negotiation of methods is relevant to the EMU WG. Just to be clear, EAP-FAST is not a product of any IETF WG and does not specify a standard of any kind. Furthermore, regardless of the IANA type registration status, EAP-FAST is, in fact, a proprietary protocol; it's publication in RFC 4851 reflects the RFC Series as a vanity press, not the IETF as a SDO. The method that this WG is developing will be a standard, however, and must not be tethered in any way to a proprietary protocol; i.e., backward compatibility with EAP-FAST. Whatever the name of the tunneled method ends up to be, the version number must be one (1). [Joe] A new method name would be good. How the protocol evolves is up to the working group. If a vendor wants to track the IETF protocol development for whatever reason so that, for example, v2 of its protocol is equivalent to v1 of the standard then that is their choice, but enabling (let alone encouraging) that behavior is not any of our concern. ... gwz.vcf ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
One benefit I see in keeping the same EAP method type code is it allows secure version negotiation from v1 to v2 with version rollback protection. However, moving to a new EAP type code would seem to make EAP method negotiation somewhat better since all implementation may not implement v1. I'm OK with assigning a new EAP method type code, but I'd like to try to maintain some backward compatibility with the v1 versioning in the case that v1 implementations find it advantageous to negotiate the v2 feature set under the v1 type code. Cheers, Joe On May 13, 2011, at 8:29 AM, Alan DeKok wrote: Since we have reached WG consensus on the method, can the authors of draft-zhou-emu-eap-fastv2-00.txt please re-submit the document as: draft-ietf-emu-eap-tunnel-method-00.txt The reason for the name change is that there have been questions raised about whether this document should be left as EAP-FASTv2, or whether it should request allocation of a new EAP type. Since the document name (individual draft) currently reflects the EAP type name, abstracting that would be useful. That way the document name will not change no matter what the WG decides to do. Anyone with opinions either way is requested to discuss the pros and cons of the issue. 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] Results of consensus call on tunnel method document
On 5/24/2011 12:53 AM, Joe Salowey wrote: One benefit I see in keeping the same EAP method type code is it allows secure version negotiation from v1 to v2 with version rollback protection. However, moving to a new EAP type code would seem to make EAP method negotiation somewhat better since all implementation may not implement v1. I'm OK with assigning a new EAP method type code, but I'd like to try to maintain some backward compatibility with the v1 versioning in the case that v1 implementations find it advantageous to negotiate the v2 feature set under the v1 type code. None of this seems to me to be relevant to the IETF, the emu WG or the discussion at hand. Just to be clear, EAP-FAST is not a product of any IETF WG and does not specify a standard of any kind. Furthermore, regardless of the IANA type registration status, EAP-FAST is, in fact, a proprietary protocol; it's publication in RFC 4851 reflects the RFC Series as a vanity press, not the IETF as a SDO. The method that this WG is developing will be a standard, however, and must not be tethered in any way to a proprietary protocol; i.e., backward compatibility with EAP-FAST. Whatever the name of the tunneled method ends up to be, the version number must be one (1). If a vendor wants to track the IETF protocol development for whatever reason so that, for example, v2 of its protocol is equivalent to v1 of the standard then that is their choice, but enabling (let alone encouraging) that behavior is not any of our concern. ... attachment: gwz.vcf___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
On Fri, May 13, 2011 at 6:29 PM, Alan DeKok al...@deployingradius.com wrote: The reason for the name change is that there have been questions raised about whether this document should be left as EAP-FASTv2, or whether it should request allocation of a new EAP type. Since the document name (individual draft) currently reflects the EAP type name, abstracting that would be useful. That way the document name will not change no matter what the WG decides to do. Anyone with opinions either way is requested to discuss the pros and cons of the issue. I would prefer to allocate a new EAP type for this method and do that as soon as possible to make it easier to run early interoperability testing without having to use vendors specific type or experimental type (of which there are only one) and to agree between various implementations what to use.. Allocating a new EAP type enables cleaner design options for implementations that only support the standard method and do not have support for the proprietary EAP-FAST method. In addition, it allows proprietary EAP-FAST extensions to be kept separate in case both methods are implemented. EAP-FAST requires various hacks in the EAP implementation, including modifying a phase 2 method (EAP-GTC) based on the phase 1 method. I do not really want to extend those hacks any further and just want to keep them conditional on the already allocated EAP-FAST type instead of having to figure out which EAP-FAST method version is being run in a method that is not really supposed to be in any way dependent on the tunnel method. As far as EAP method/version negotiation is concerned, I find it more likely that the EAP-NAK mechanism for selecting the EAP method has received much more testing than EAP-FAST version negotiation and as such, is more likely to interoperate with legacy implementations. - Jouni ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
Jouni Malinen jkmali...@gmail.com writes: On Fri, May 13, 2011 at 6:29 PM, Alan DeKok al...@deployingradius.com wrote: The reason for the name change is that there have been questions raised about whether this document should be left as EAP-FASTv2, or whether it should request allocation of a new EAP type. Since the document name (individual draft) currently reflects the EAP type name, abstracting that would be useful. That way the document name will not change no matter what the WG decides to do. Anyone with opinions either way is requested to discuss the pros and cons of the issue. I would prefer to allocate a new EAP type for this method and do that as soon as possible to make it easier to run early interoperability testing without having to use vendors specific type or experimental type (of which there are only one) and to agree between various implementations what to use.. +1 for a new EAP type for FASTv2. /Simon ___ 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 g...@net-zen.net wrote: On 5/15/2011 2:36 AM, Sam Hartman wrote: Alan == Alan DeKok al...@deployingradius.com 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
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 jsalo...@cisco.com 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 g...@net-zen.net wrote: On 5/15/2011 2:36 AM, Sam Hartman wrote: Alan == Alan DeKok al...@deployingradius.com 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] Results of consensus call on tunnel method document
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? Allocating a new EAP type. The draft name eap-tunnel-method describes the protocol accurately. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
My opinion is we request allocation of a new EAP method value. And I suggest that the new EAP method have a name/description of Extensible Tunneled Authentication (ETA). Dan. On Fri, May 13, 2011 8:29 am, Alan DeKok wrote: Since we have reached WG consensus on the method, can the authors of draft-zhou-emu-eap-fastv2-00.txt please re-submit the document as: draft-ietf-emu-eap-tunnel-method-00.txt The reason for the name change is that there have been questions raised about whether this document should be left as EAP-FASTv2, or whether it should request allocation of a new EAP type. Since the document name (individual draft) currently reflects the EAP type name, abstracting that would be useful. That way the document name will not change no matter what the WG decides to do. Anyone with opinions either way is requested to discuss the pros and cons of the issue. 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] Results of consensus call on tunnel method document
Alan == Alan DeKok al...@deployingradius.com 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. However we can always short-circuit the issue early. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
On Sat, May 14, 2011 1:58 pm, Alan DeKok wrote: Dan Harkins wrote: My opinion is we request allocation of a new EAP method value. And I suggest that the new EAP method have a name/description of Extensible Tunneled Authentication (ETA). I'd like to know more about the pros and cons. What is the value in keeping the existing EAP-FAST code? What is the value in changing to a new code? Alan DeKok. Having a new EAP method value would be more ecumenical. Dan. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
On 5/15/2011 2:36 AM, Sam Hartman wrote: Alan == Alan DeKok al...@deployingradius.com 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... ... attachment: gwz.vcf___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Results of consensus call on tunnel method document
Since we have reached WG consensus on the method, can the authors of draft-zhou-emu-eap-fastv2-00.txt please re-submit the document as: draft-ietf-emu-eap-tunnel-method-00.txt The reason for the name change is that there have been questions raised about whether this document should be left as EAP-FASTv2, or whether it should request allocation of a new EAP type. Since the document name (individual draft) currently reflects the EAP type name, abstracting that would be useful. That way the document name will not change no matter what the WG decides to do. Anyone with opinions either way is requested to discuss the pros and cons of the issue. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
Re: [Emu] Results of consensus call on tunnel method document
On 5/13/2011 10:29 PM, Alan DeKok wrote: Since we have reached WG consensus on the method, can the authors of draft-zhou-emu-eap-fastv2-00.txt please re-submit the document as: draft-ietf-emu-eap-tunnel-method-00.txt The reason for the name change is that there have been questions raised about whether this document should be left as EAP-FASTv2, or whether it should request allocation of a new EAP type. Since the document name (individual draft) currently reflects the EAP type name, abstracting that would be useful. That way the document name will not change no matter what the WG decides to do. Anyone with opinions either way is requested to discuss the pros and cons of the issue. There seem to be two issues here: renaming the draft allocating a new EAP type. For which one are opinions being solicited? ... attachment: gwz.vcf___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
