Subject: [Emu] Results of consensus call on tunnel method document

From: Alan DeKok <[email-masked]>
Date: Fri, 13 May 2011 17:29:03 +0200

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.

---

From: Glen Zorn <[email-masked]>
Date: Sat, 14 May 2011 08:31:46 +0700

>   Anyone with opinions either way is requested to discuss the pros and

There seem to be two issues here: renaming the draft & allocating a new
EAP type.  For which one are opinions being solicited?

...

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 May 2011 08:40:38 +0200

> 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.

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 14 May 2011 10:33:01 -0700 (PDT)

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:
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: Sam Hartman <[email-masked]>
Date: Sat, 14 May 2011 15:36:36 -0400

>>>>> "Alan" == Alan DeKok <[email-masked]> 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.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 14 May 2011 22:58:55 +0200

> "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.

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 14 May 2011 15:41:31 -0700 (PDT)

>   What is the value in changing to a new code?

  Having a new EAP method value would be more ecumenical.

  Dan.

---

From: Glen Zorn <[email-masked]>
Date: Sun, 15 May 2011 08:18:26 +0700

> 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...

...

---

From: Dorothy Stanley <[email-masked]>
Date: Mon, 16 May 2011 11:29:45 -0700

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

---

From: Joe Salowey <[email-masked]>
Date: Mon, 16 May 2011 11:37:21 -0700

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.

---

From: Dorothy Stanley <[email-masked]>
Date: Mon, 16 May 2011 12:04:14 -0700

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 <[email-masked]> wrote:

> [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
> >

---

From: Sam Hartman <[email-masked]>
Date: Mon, 16 May 2011 18:35:43 -0400

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.

---

From: Jouni Malinen <[email-masked]>
Date: Tue, 17 May 2011 11:34:59 +0300

>  Anyone with opinions either way is requested to discuss the pros and

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

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 17 May 2011 17:20:38 +0200

> implementations what to use..

+1 for a new EAP type for FASTv2.

/Simon

---

From: Joe Salowey <[email-masked]>
Date: Mon, 23 May 2011 10:53:24 -0700

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

---

From: Glen Zorn <[email-masked]>
Date: Tue, 24 May 2011 07:50:05 +0700

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.

...

---

From: Joe Salowey <[email-masked]>
Date: Mon, 30 May 2011 21:08:51 -0700

On May 23, 2011, at 5:50 PM, Glen Zorn wrote:

> 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
> 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
> <gwz.vcf>

---

From: Glen Zorn <[email-masked]>
Date: Tue, 31 May 2011 13:25:10 +0700

> [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.

> [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...