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

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 2 Apr 2007 12:35:42 -0700

I'm not sure that adding yet another version to TTLS specifically for
supporting passwords will make things better for customers.  Multiple
versions certainly has caused quite a confusion in PEAP.    

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

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

---

From: Ryan Hurst <[email-masked]>
Date: Mon, 2 Apr 2007 12:48:16 -0700

I believe there were many issues with how PEAP progressed, if we are
careful we could prevent the same things from happening with TTLS.

Ryan

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Mon, 2 Apr 2007 17:33:22 -0400

What is the difference between defining a new method vs. a new version
of the existing EAP method that is  not backward compatible? I don't see
how the implementation issue will go away. Some one still needs to
implement it and customers need to deploy it. Might be more confusing to
define another version of TTLS, as there are two version defined
already, version 0 and 1. It seems to me much cleaner to start from a
standard based EAP method handling password-only, and gradually
extending it over time.

> From: Ryan Hurst [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 3:48 PM
> To: Joseph Salowey (jsalowey); Bernard Aboba; [email-masked]
> I believe there were many issues with how PEAP progressed, if 
> we are careful we could prevent the same things from 
> happening with TTLS.
> 
> Ryan
> 
> I'm not sure that adding yet another version to TTLS 
> specifically for supporting passwords will make things better 
> for customers.  Multiple
> > After listening to the IETF 68 presentation on a password-based EAP 
> > method, I would like to voice some concerns.
> > 
> 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.
> > 
> > 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.
> > 
> EAP-TTLSv0, 
> > since it is very widely implemented, and has an existing 
> certification 
> > program in
> > In terms of steps to be taken, this would require the following 
> > actions:
> > 
> specification as 
> > an RFC.  The goal here would be to document EAP-TTLSv0 as it exists 
> > today.
> > 
> specifying 
> > additional capabilities (such as Channel Bindings).
> > 
> > 
> >

---

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

>versions certainly has caused quite a confusion in PEAP.

I would agree that "versioning" is not a good idea.  However, as I 
understand it, EAP-TTLSv0 is the only deployed version of TTLS; v1 has never 
been implemented.   So currently there is no versioning issue with TTLS, and 
if possible, it would be best if the IETF would not create such a problem.

It is not clear to me that EAP-TTLS needs "versioning" in order to enable 
addition of new features in a backwards compatible way, since it already 
supports a TLV-based extension mechanism.

---

From: Ryan Hurst <[email-masked]>
Date: Mon, 2 Apr 2007 17:08:24 -0700

I totally agree, I would hate to see us define yet another tunneling eap method if we could add a couple extensions to a existing one that has received reasonable adoption already.
 
If it turns out we had to define a totally new non-backwards compatible protocol I would agree we would probably be better off starting all over but from my read of the current (expired) TTLSv0 document I dont think thats where we would be going.
 
Ryan

________________________________

From: Bernard Aboba [mailto:[email-masked]]
Sent: Mon 4/2/2007 3:45 PM
To: [email-masked]
Subject: RE: [Emu] Thoughts on Password-based EAP Methods

---

From: Jouni Malinen <[email-masked]>
Date: Mon, 2 Apr 2007 19:07:15 -0700

On Mon, Apr 02, 2007 at 03:45:44PM -0700, Bernard Aboba wrote:

> understand it, EAP-TTLSv0 is the only deployed version of TTLS; v1 has 
> never been implemented.   So currently there is no versioning issue with 
> TTLS, and if possible, it would be best if the IETF would not create such a 
> problem.

I'm aware of at least one, though maybe partial, implementation of
TTLSv1. Anyway, I don't think it has been deployed anywhere.

> supports a TLV-based extension mechanism.

If this can be done in backwards compatible way, staying with the v0
sounds reasonable assuming features from TTLSv1 are not desired and I
don't think would necessarily like to mandate TLS/IA support for the
method to be standardized.

In general, the PEAP version negotiation itself works fine, but one of
the problems is that number of different implementations _within_ the
same version number work differently.. The main issue for me from the
implementation view point has been lack of clear description of the
protocol and existance of differently behaving and already deployed
implementations..

EAP-TTLSv0 is in better situation from the viewpoint of most
implementation behaving more or less in the same way. However, this can
get interesting if new extensions are added and if some of the
implementations are not exactly prepared for this.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Mon, 2 Apr 2007 22:41:09 -0400

Please see inline. 

> From: Jouni Malinen [mailto:[email-masked]] 
> Sent: Monday, April 02, 2007 10:07 PM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [Emu] Thoughts on Password-based EAP Methods
> 
> > TTLS, and if possible, it would be best if the IETF would 
> not create 
> > such a problem.
> 
> I'm aware of at least one, though maybe partial, 
> implementation of TTLSv1. Anyway, I don't think it has been 
> deployed anywhere.
> 
> > It is not clear to me that EAP-TTLS needs "versioning" in order to 
> > enable addition of new features in a backwards compatible 
> way, since 
> > it already supports a TLV-based extension mechanism.
> 
> If this can be done in backwards compatible way, staying with 
> the v0 sounds reasonable assuming features from TTLSv1 are 
> not desired and I don't think would necessarily like to 
> mandate TLS/IA support for the method to be standardized.
>
[HZ] My point is that we cannot do it in a backward compatible way.
First of all, not sure we need the Diameter AVP complexity inside the
tunnel. Second of all, TTLSv0 doesn't have crypto-binding and agility,
which mostly require changes that are not backward compatible. 
 
> In general, the PEAP version negotiation itself works fine, 
> but one of the problems is that number of different 
> implementations _within_ the same version number work 
> differently.. The main issue for me from the implementation 
> view point has been lack of clear description of the protocol 
> and existance of differently behaving and already deployed 
> implementations..
[HZ] That's not true. There are only two PEAP versions in deployment,
PEAPv0 and PEAPv1. They are different between them. But among PEAPv0 or
PEAPv1 implementations, they interoperate.
> implementation behaving more or less in the same way. 
> However, this can get interesting if new extensions are added 
> and if some of the implementations are not exactly prepared for this.
> 
[HZ] That's the problem. We cannot add or take away functionalities and
maintain interoperability without incrementing the version. If we do
that, then how is that different than creating a new EAP method. The
design team is looking at approach similar to TTLS/PEAP/EAP-FAST, with a
much simpler inner data representation. Whatever the argument made for
TTLS, we can make it for PEAP and EAP-FAST.

---

From: Jouni Malinen <[email-masked]>
Date: Mon, 2 Apr 2007 20:22:24 -0700

> PEAPv1 implementations, they interoperate.

Have you run interop tests with PEAPv0 and PEAPv1 using a large set of
different server implementations? I've tested with ten or so servers
that supported various combinations of PEAPv0 and PEAPv1. There were at
least six different combinations on behaviors that required peer
workarounds to handle..

PEAPv1 is more problematic on this front since there is more than one
IETF draft describing a protocol that uses version 1 and these
drafts differ on number of areas and none of these drafts actually
describe the exact behavior that most servers uses.. 

For example, at least one server uses "client PEAP encryption" as the
label for PRF whereas most use "client EAP encryption". That is clearly
an interoperability issue (I've only seen this with PEAPv1 and one
RADIUS server, but anyway that is the label described in some of the
drafts).

Another difference is in how the negotiation is terminated. Some
implementations require protected success indication by use of a
tunneled EAP-Success. Some use just plain EAP-Success outside the tunnel
without any protected success indication. Yet another interoperability
issue.

One strange case was an implementation that uses incorrect version
negotiation and in practice ends up always using v0 (which itself
interoperates relatively well, so this is not a major problem).

In other words, PEAPv1 is not exactly something I would consider a good
example of an interoperable or well-defined EAP method. I think that
EAP-PEAP has caused more interop issues in my tests than all other
methods combined.. Sure, this is partly due to most implementations
supporting PEAP in one form or another so there are more test cases, but
still, EAP-TLS and EAP-TTLS have been more or less problem free from the
view point of seeing different behavior from implementations.

> TTLS, we can make it for PEAP and EAP-FAST.

I haven't went through the details of what would be needed for the
changes while trying to maintain backwards compatibility within the same
version number, so I cannot comment on the first part, but I can agree
with the second. Anyway, I certainly support the idea of using something
existing as a starting point whether the end result ends up using the
same method number and version or not.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 03 Apr 2007 00:24:51 -0700

>RADIUS server, but anyway that is the label described in some of the

Using the same label string as EAP-TLS (e.g. "client EAP encryption") 
enables an attacker to modify the PEAP Type Code without detection, since 
the Type field is not included in the MIC.

>interoperates relatively well, so this is not a major problem).

The PEAP version negotiation assumes that implementations support all the 
downward compatible versions, so that a server advertising PEAPv1 also can 
negotiate (and support) PEAPv0.  However, this assumes that endpoints will 
negotiate the highest available version.  Unfortunately, there are now 
multiple versions of PEAPv0, some of which include functionality not 
supported by PEAPv1, so that this assumption is not really valid.

>I think that PEAP has caused more interop issues in my tests than all other
>methods combined..

Right.  Not surprisingly, PEAP also been the source of a huge number of 
customer complaints.

>Still, EAP-TLS and EAP-TTLS have been more or less problem free from the

At least this was true prior to the deployment of TLSv1.1 implementations.  
I'm afraid that since then we are seeing a substantial rise in 
interoperability problems with all TLS-based EAP methods.  Hopefully this 
will subside once broken TLS v1.0 implementations are fixed in the field.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 3 Apr 2007 08:15:35 -0700

Some of the things that need to be fixed are fairly fundamental. For
example crypto-binding and avoiding multiple layers of negotiation are
fairly fundamental.  At this point I'm not sure that modifying TLVs is
the best way to achieve this.  It needs to be investigated.  

Joe

> Sent: Monday, April 02, 2007 3:46 PM
> To: [email-masked]
> specifically for 
> I would agree that "versioning" is not a good idea.  However, 
> as I understand it, EAP-TTLSv0 is the only deployed version 
> of TTLS; v1 has never 
> It is not clear to me that EAP-TTLS needs "versioning" in 
> order to enable addition of new features in a backwards 
> compatible way, since it already supports a TLV-based 
> extension mechanism.
> 
> 
>

---

From: Ryan Hurst <[email-masked]>
Date: Tue, 3 Apr 2007 09:43:22 -0700

I can easily see how crypto-binding could be added to the protocol
without breaking backwards compatibility, eg how negotiation via
TTLSv0's extensibility model could add this in as a optional operation
that the client and server agree upon.

In general I think having a standards based, interoperable tunneling
method would be good for customers and the industry and TTLSv0 appears
clean enough, and pretty broadly adopted so using it as the basis of
work in this area looks like a good idea to me.

Ryan

-----Original Message-----
From: Joseph Salowey (jsalowey) [mailto:[email-masked]] 
Sent: Tuesday, April 03, 2007 8:16 AM
To: Bernard Aboba; [email-masked]
Subject: RE: [Emu] Thoughts on Password-based EAP Methods

Joe

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 3 Apr 2007 15:34:24 -0400

> TTLSv1. Anyway, I don't think it has been deployed anywhere.

I talked to Paul Funk about this. He hasn't implemented EAP-TTLSv1,
is not planning to do so, and is not aware of any implementations
or deployments of that protocol.

Also, Pascal asked about a patent application. I asked Paul about
that and he said it isn't about EAP-TTLS.

Thanks,

Steve

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 03 Apr 2007 17:17:21 -0700

>that and he said it isn't about EAP-TTLS.

Searching the IETF IPR page, I found the following disclosure, which relates 
to TLS-IA, and therefore is only relevant to EAP-TTLSv1:
https://datatracker.ietf.org/public/ipr_detail_show.cgi?&ipr_id=594