Subject: [Emu] Some questions about eap type code and the tunnel method

From: Sam Hartman <[email-masked]>
Date: Mon, 16 May 2011 08:39:14 -0400

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.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 May 2011 15:02:43 +0200

> I'd like to confirm that code is in use both by implementations of

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

---

From: Hao Zhou <[email-masked]>
Date: Mon, 16 May 2011 10:32:09 -0400

Alan:

Please see responses inline below.

>> I'd like to confirm that code is in use both by implementations of
[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.
 
>> 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?
 
> 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.

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 16 May 2011 16:45:38 +0200

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

> most of them could support both easily. Doesn't running code mean something

  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.

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

> tunnel methods, including EAP-FASTv1.

  See above.

> By retaining the EAP-FAST type,
> 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

  I'm not sure how changing the type code adds deployment costs.  The
new version has to be deployed no matter what.

  Alan DeKok.

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 16 May 2011 10:44:19 -0700 (PDT)

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.

---

From: Nancy Cam-Winget <[email-masked]>
Date: Mon, 16 May 2011 16:48:00 -0700

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

---

From: Glen Zorn <[email-masked]>
Date: Tue, 17 May 2011 07:03:25 +0700

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

> possible to deploy only the EMU tunneled method.

This seems to me to be a strong argument for a new type code.

...

---

From: Glen Zorn <[email-masked]>
Date: Tue, 17 May 2011 07:12:46 +0700

> I'd like to confirm that code is in use both by implementations of

I'm pretty sure that there are no implementations (except maybe in a lab
somewhere) of EAP-FAST 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...

---

From: Glen Zorn <[email-masked]>
Date: Tue, 17 May 2011 08:04:07 +0700

On 5/16/2011 9:32 PM, Hao Zhou wrote:

...

> most of them could support both easily. Doesn't running code mean something

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?

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

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

> 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

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.

...

---

From: Stefan Winter <[email-masked]>
Date: Tue, 17 May 2011 08:41:45 +0200

Hi,

> 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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 17 May 2011 09:33:08 +0200

> It seems too early to decide whether there is a need to change the EAP type

  We're asking for input, not a decision right now.

>  interfaces especially on the client side.

  Yes, that is certainly true.

  Alan DeKok.

---

From: Glen Zorn <[email-masked]>
Date: Wed, 18 May 2011 09:43:37 +0700

>   We're asking for input, not a decision right now.

Why not?

>>  interfaces especially on the client side.

Sorry, but I have no idea what that means.  What you seem to be saying
is that the mere addition of a new EAP method requires changes in the
actual defined interfaces between the management and configuration
components of the system (not merely in the data that traverses those
interfaces).  That is absurd, of course, so you must _mean_ is that
there will be more and/or different stuff to configure and manage but
that is so close to being a tautology that it hardly seems mentioning
(and certainly not in such an ominous tone).  Or maybe not.  What are
you talking about?

...

---

From: Alan DeKok <[email-masked]>
Date: Wed, 18 May 2011 07:39:20 +0200

>>   We're asking for input, not a decision right now.

  I'd like to see what the WG consensus is prior to making a decision.

  In addition, I'd like to be sure we understand the consequences of a
change, before we make a decision.

  If the type code does change, then the method name will likely need to
change, too.  What's the new name?  etc...

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 18 May 2011 08:06:28 +0200

Glen Zorn wrote:
> I guess the IETF process has really changed lately!  I had always
> thought that WG consensus _was_ the decision & the task of the chairs
> was merely to determine what WG consensus was.  Silly me!

  Make that "establish WG consensus prior to announcing a decision"

  Alan DeKok.

---

From: Glen Zorn <[email-masked]>
Date: Wed, 18 May 2011 13:02:37 +0700

> change, too.  What's the new name?  etc...

Highly technical stuff -- I'd put a couple of more years in the charter
timeline to deal with these tough questions.  In the  meantime, I have
two suggestions for the new name (assuming that the Deciders establish
that a new type is a good idea), just to get the ball rolling: Tunneled
Extensible Authentication Method (TEAM, an oldie but goody) and Internet
(or IETF) Tunneled EAP Method (ITEM).

...

---

From: Stefan Winter <[email-masked]>
Date: Mon, 23 May 2011 14:45:24 +0200

Hi,

> (or IETF) Tunneled EAP Method (ITEM).

Crazy thought: how about EAP-TUNNEL?

Yes, I know, not an acronym, just a plain old English word which makes
sense on its own - which probably breaks several "but it needs to be a
four-letter acronym, preferably a nicely sounding one, with a strange
expansion which is obviously reverse-engineered from the acronym to
sound cool" policies.

Stefan

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

---

From: Glen Zorn <[email-masked]>
Date: Wed, 25 May 2011 10:46:03 +0700

> expansion which is obviously reverse-engineered from the acronym to

Actually, I was pleasantly surprised that "Internet Tunneled EAP Method"
turned out to be ITEM but in any case...I'm sure that there is no policy
except maybe having a little fun ;-).  Maybe that should be against
policy?  I do think that EAP-TUNNEL is both grammatically incorrect
(since "tunnel" is a common noun it shouldn't be capitalized, let alone
ALL CAPS :-).  Also, I wonder if it isn't a bit too generic: there are a
whole bunch of PEAP clones (sorry, tunneled methods) already: TTLS,
FAST, etc., all of which could be reasonably referred to as "EAP TUNNEL".

...

---

From: Stefan Winter <[email-masked]>
Date: Wed, 25 May 2011 09:23:35 +0200

Hi,

> ALL CAPS :-).

I didn't want to violate more common thinking about naming by using
non-capitals! EAP-Tunnel would be just as fine for me.

>   Also, I wonder if it isn't a bit too generic: there are a

That's right. We should prefix it as "*/the/*" EAP Tunnel to make people
aware that it's the one-and-only type to be used. Yes, I'm actually
dreaming that the deployed world out there would settle to use just one
in a distant future...

Stefan

Tel: +352 424409 1
Fax: +352 422473

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 25 May 2011 08:16:44 -0700 (PDT)

> dreaming that the deployed world out there would settle to use just one

  Let me offer my suggestion again: Extensible Tunneled Authentication
or EAP-ETA. "What's the ETA?" Well the way this group progresses it's
probably about...wait, sorry, ETA is the shiny new fantabulous EAP
method from EMU!

  regards,

  Dan.