Subject: [Emu] Re: Thoughts on Password-based EAP Methods

From: "Stephen Hanna" <[email-masked]>
Date: Mon, 2 Apr 2007 17:59:31 -0400

Sorry it took me a few days to respond to this thread.

I agree with Bernard that there's no benefit in creating
Yet Another Password-Based EAP Method (YAPBEM). There's
no point in reinventing the wheel for a fourth time and
it's not the IETF way. We're not researchers. We're practical
engineers who respect running code and rough consensus.
So, yes, we should have a bias toward existing, well-tested
and well-understood protocols.

In a security group, it's especially important to avoid
the temptation to reinvent the wheel. We should focus
our efforts on one secure tunneled EAP method and make
that one secure. We should consider existing methods
and only invent something new if we need to.

I have spoken to Paul Funk, the primary author of the
EAP-TTLSv0 spec. He is glad to proceed as Bernard suggested:

1. Publish an updated EAP-TTLSv0 spec that documents
   current practice (as Informational or Experimental)

2. Give up change control to the IETF so that the EMU WG
   can make any necessary changes or additions to EAP-TTLS

I'm also glad to assist with this effort, since Paul is
pretty busy these days.

Thanks,

Steve

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Tuesday, March 27, 2007 8:07 AM
To: [email-masked]
Subject: [Emu] Thoughts on Password-based EAP Methods

After listening to the IETF 68 presentation on a password-based EAP
method, I would like to voice some concerns.

Today we already have an "over abundance" of such methods. These include
PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and EAP-FAST. In my discussions
with customers, I invariably hear complaints about this explosion, and
about various interoperability and compatibility problems that it
causes. Simply put, customers do not want "yet another password-based
EAP method"; they want a single method that is widely implemented and
interoperable.

I am concerned that by defining yet another password-based
authentication mechanism, EMU WG will be making this problem worse, not
better. Creating yet another mechanism which differs little from the
existing ones also seems to have very little chance of being
implemented.

There is a better alternative that EMU WG should consider. This is to
choose an existing method for inclusion on the IETF Standards Track,
rather than creating a new one. In order to maintain backward
compatibility, this would require that the owners give up change control
to the IETF.

I would suggest that the best candidate for this would be EAP-TTLSv0,
since it is very widely implemented, and has an existing certification
program in WFA. Also, EAP-TTLSv0 had previously been on the Standards
Track in the PPPEXT WG, before work on EAP methods was removed from the
PPPEXT WG charter and the EAP WG was formed.

In terms of steps to be taken, this would require the following actions:

a. Review and publication of the existing EAP-TTLSv0 specification as an
RFC. The goal here would be to document EAP-TTLSv0 as it exists today.

b. Agreement by the authors to give up change control to the IETF.

c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document, specifying
additional capabilities (such as Channel Bindings).

_______________________________________________
Emu mailing list
Emu at ietf.org
https://www1.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 03 Apr 2007 00:11:00 +0200

I am not surprised to hear that EAP method authors agree that no further 
EAP methods should be developed.
Part of the problem with EAP methods is that people should have started 
to standardize them within the IETF several years ago. Unfortunately, 
there was no interest by some of the EAP method authors nor from the EAP 
WG chairs to allow that.

But if some (unknown) customers say that they do not want more EAP 
methods then Sam will have to change his mind. At the last IETF meeting 
he ruled out the usage of TTLS, for example.

I hope that the some people can change their mind with regard to the 
applicability statement of EAP usage in TLS so quickly as well....

~snip~

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 02 Apr 2007 15:42:21 -0700

>Part of the problem with EAP methods is that people should have started to 
>standardize them within the IETF several years ago. Unfortunately, there 
>was no interest by some of the EAP method authors nor from the EAP WG 
>chairs to allow that.

In fact, the IETF was on track to standardize EAP methods back as recently 
as 2001, within the PPPEXT WG.  It was as part of that program that EAP-TLS 
was first published as an Experimental RFC, and EAP-TTLSv0 was put on the 
standards track.

The decision to remove standards track EAP methods from the PPPEXT WG 
charter was made by the IESG, not by the authors of EAP methods, or the EAP 
WG chairs.  As I recall, there was considerable opposition to that decision 
at the time.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 03 Apr 2007 10:27:12 +0200

I see it a bit differently since I was at many EAP meetings where EAP 
method authors wanted to work on standards track EAP methods.

Ciao
Hannes

Bernard Aboba wrote:
>> Part of the problem with EAP methods is that people should have 
>> started to standardize them within the IETF several years ago. 
>> Unfortunately, there was no interest by some of the EAP method 
>> authors nor from the EAP WG chairs to allow that.
>
> In fact, the IETF was on track to standardize EAP methods back as 
> recently as 2001, within the PPPEXT WG.  It was as part of that 
> program that EAP-TLS was first published as an Experimental RFC, and 
> EAP-TTLSv0 was put on the standards track.
>
> charter was made by the IESG, not by the authors of EAP methods, or 
> the EAP WG chairs.  As I recall, there was considerable opposition to 
> that decision at the time.
>
>
>

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Tue, 3 Apr 2007 10:25:37 -0700

Bernard Aboba <mailto:[email-masked]> allegedly scribbled on

> that decision at the time.   

I was in favor of it at the time, as I recall; however, I imagined that
the project would move to the EAP WG, not drop into a black hole.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sat, 7 Apr 2007 14:49:55 -0700

I share the concerns expressed about defining yet another password based
EAP method. As people have pointed out here, EAP-TTLSv0 also allows the
use of the TLS record layer to carry a password-based authentication
method without an inner tunneling of EAP. 

Several months ago, I tried contacting Paul Funk, Bernard and Jari to
see if there would be an interest in publishing EAP-TTLSv0. Since we
never heard from Paul, that communication fizzled out. We (in Qualcomm)
have an implementation of PEAPv0, PEAPv1 and TTLSv0 and would like to
see the IETF publish a standard for at least one of these methods,
preferably TTLSv0. The choice of an EAP method to use with some legacy
authentication mechanisms in 3gpp2 has been pending for a while, due to
the lack of IETF activity with respect to these protocols. Publishing a
new password-based method is not going to solve this problem, since
there is considerable resistance to implementing another method. 

I'm glad to hear from Steve here that there is support for publishing
TTLSv0. I would like to see that happen regardless of whether it is done
as an EMU work item or not. 

Vidya

> From: Stephen Hanna [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 3:00 PM
> To: [email-masked]
> Subject: [Emu] Re: Thoughts on Password-based EAP Methods
> 
> I agree with Bernard that there's no benefit in creating Yet 
> Another Password-Based EAP Method (YAPBEM). There's no point 
> in reinventing the wheel for a fourth time and it's not the 
> IETF way. We're not researchers. We're practical engineers 
> who respect running code and rough consensus.
> In a security group, it's especially important to avoid the 
> temptation to reinvent the wheel. We should focus our efforts 
> on one secure tunneled EAP method and make that one secure. 
> We should consider existing methods and only invent something 
> new if we need to.
> 
> After listening to the IETF 68 presentation on a 
> password-based EAP method, I would like to voice some concerns.
> 
> Today we already have an "over abundance" of such methods. 
> These include PEAPv0, PEAPv1, EAP-TTLSv0, EAP-TTLSv1, and 
> EAP-FAST. In my discussions with customers, I invariably hear 
> complaints about this explosion, and about various 
> interoperability and compatibility problems that it causes. 
> Simply put, customers do not want "yet another password-based 
> EAP method"; they want a single method that is widely 
> implemented and interoperable.
> 
> authentication mechanism, EMU WG will be making this problem 
> worse, not better. Creating yet another mechanism which 
> differs little from the existing ones also seems to have very 
> little chance of being implemented.
> 
> There is a better alternative that EMU WG should consider. 
> This is to choose an existing method for inclusion on the 
> IETF Standards Track, rather than creating a new one. In 
> order to maintain backward compatibility, this would require 
> that the owners give up change control to the IETF.
> 
> I would suggest that the best candidate for this would be 
> EAP-TTLSv0, since it is very widely implemented, and has an 
> existing certification program in WFA. Also, EAP-TTLSv0 had 
> previously been on the Standards Track in the PPPEXT WG, 
> before work on EAP methods was removed from the PPPEXT WG 
> charter and the EAP WG was formed.
> 
> a. Review and publication of the existing EAP-TTLSv0 
> specification as an RFC. The goal here would be to document 
> EAP-TTLSv0 as it exists today.
> 
> c. EMU WG efforts to publish an EAP-TTLSv0 "bis" document, 
> specifying additional capabilities (such as Channel Bindings).
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 07 Apr 2007 15:17:57 -0700

>as an EMU work item or not.

My understanding is that a new version of the TTLSv0 document will be 
forthcoming which will fill in some of the details that were previously 
missing, such as the EMSK generation formula, and the definitions of the 
Session-Id, Peer-Id and Server-Id.

A new version of the PEAPv0 specification will also be forthcoming.

---

From: Madjid Nakhjiri <[email-masked]>
Date: Thu, 12 Apr 2007 15:34:56 -0700

Hi Steve,

Sorry for jumping late. Internally within the design team and not having
followed this thread, I suggested that we could follow the TTLS path in a
way that it meets our requirements. The fact that Paul has agreed to give up
control of the draft to IETF is really good news, however, I am a bit
confused as how the process you suggested will happen, so let me understand
this:

We publish the current TTLSv0 as an RFC, 
and we also publish TTLSvX based on the changes EMU does as a separate RFC
in a way that it does not deprecate the first one? (sort of like IKEv1 and
IKEv2 scenario?)

As good as that sounds to me, the not so rhetorical question would be:
wouldn't the two versions still get two different method types?

BTW, I am hearing that Paul has promised to add EMSK generation to TTLSv0,
so may be TTLSv0 is not quite there yet:)?

R,

Madjid

-----Original Message-----
From: Stephen Hanna [mailto:[email-masked]] 
Sent: Monday, April 02, 2007 3:00 PM
To: [email-masked]
Subject: [Emu] Re: Thoughts on Password-based EAP Methods

Thanks,

Steve