Subject: [Emu] Presentations for EMU

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 19 Mar 2007 02:01:04 -0700

Please send me presentations for EMU agenda items this morning. 

Thanks,

Joe

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 27 Mar 2007 08:07:19 -0700

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

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Thu, 29 Mar 2007 17:24:54 -0400

Bernard:

I am not sure reusing one of the existing EAP methods is the right
approach. All three EAP method mentioned, EAP-TTLS/PEAP/EAP-FAST all has
something that are outside the scope of the charter, which means we have
to take some of them out. Not unitl we change the charter, then we can
pick one of them and declare victory. Some (if not all) are also missing
some features required, like crypto-agility, etc.  This means we will
change the existing protocol and make it not backward compatible. There
will be the same issue with implementation whether a new EAP method or a
modified EAP method. I think part of the benefits of defining a new
standard EAP method, people will want to implement it, as opposed to
implement according to some expired draft. The design team are aware of
TTLS and is working towards something that will probably be similar and
much simpler. We try to strive for something simple but extensible, then
over time we can enhance it as it is in IETF control. 

EAP-TTLS itself also has its own issues:  
1. It's internal AVP uses Radius attribute, I am not sure that' a good
idea.
2. There is also TTLSv1 draft, which is quite different than v0. I am
not sure about there are actual implementations or not. But if we create
another modified TTLS from TTLSv0, it might create confusions.
3. The patent issue mentioned by Pascal.

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Tuesday, March 27, 2007 11: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.
> 
> 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 
> 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 
> 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).
> 
> 
>