Subject: [Emu] Enhanced EAP-TLS

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 8 Jun 2006 13:01:28 -0700

One of our charter items is to develop an enhanced EAP-TLS that can
support features that are not possible to support in a manner that is
backward compatible with RFC2716. 

Some of the potential features on the list include:

1. Additional cipher suites (PSK, Kerberos, ECC)
2. TLS extensions 
3. Channel Bindings
4. Identity protection

Are there additional features that should be supported by an enhanced
TLS?  

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

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Mon, 12 Jun 2006 14:49:16 -0400

What about exchanges of arbitrary data in the protected tunnel (may
include channel binding), optional server side authentication with inner
method support for weak password. Would it make sense to create a single
TLS based tunneling method instead of two separate ones, one for
enhanced TLS, and another one for tunneling method support for weak
password?

> -----Original Message-----
> From: Joseph Salowey (jsalowey) 
> Sent: Thursday, June 08, 2006 4:01 PM
> To: [email-masked]
> Subject: [Emu] Enhanced EAP-TLS
> 
> One of our charter items is to develop an enhanced EAP-TLS 
> that can support features that are not possible to support in 
> a manner that is backward compatible with RFC2716. 
> 
> 1. Additional cipher suites (PSK, Kerberos, ECC) 2. TLS 
> extensions 3. Channel Bindings 4. Identity protection
> 
> Are there additional features that should be supported by an 
> enhanced TLS?  
>

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Mon, 19 Jun 2006 08:50:24 -0700

Exchanging data within the TLS tunnel is one way to achieve channel
bindings.  I could see advantages to having a single method for legacy
password database support and enhanced TLS.  At least it seems the core
specification could be the same.  

I'm not quite sure how to handle EAP negotiation with multiple
credentials supported by the same method.  For example, I don't see a
problem with backwards compatibility in adding additional ciphersuite
support to RFC2617bis to PSK and other credentials; I believe that most
TLS implementations handle ciphersuite negotiation correctly.  There may
a potential problem because if ciphersuite negotiation fails the only
way within EAP to try a new EAP method is to restart the entire
conversation in the lower layer.  This may be less than ideal, but I'm
not sure it is too much of a problem in reality. 

Joe

> From: Hao Zhou (hzhou) 
> Sent: Monday, June 12, 2006 11:49 AM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Emu] Enhanced EAP-TLS
> 
> What about exchanges of arbitrary data in the protected 
> tunnel (may include channel binding), optional server side 
> authentication with inner method support for weak password. 
> Would it make sense to create a single TLS based tunneling 
> method instead of two separate ones, one for enhanced TLS, 
> and another one for tunneling method support for weak password?
>