Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Mon, 23 Oct 2006 18:22:49 -0700

Bernard Aboba <mailto:[email-masked]> supposedly scribbled on
Monday, October 23, 2006 6:08 PM:

...

> Creating "versions" of EAP-TLS would potentially confuse customers
> and cause problems with existing test suites and certification
> programs.  Witness the confusion that was created by PEAP versioning,
> where PEAPv0 and PEAPv1 did not interoperate.   

I believe that the interoperability problems were caused by corporate
power plays & infighting rather than versioning per se.

...

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

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 26 Oct 2006 22:26:56 -0700

I think the typecode and separate document are orthogonal.  There has been discussion of adding enhancements to EAP-TLS, such as channel bindings, which would probably not be backward compatible.  In this case we would need a new typecode for this new protocol.  PSK or other ciphersuites could be negotiated in TLS under this method type.  

Joe

> -----Original Message-----
> From: Tschofenig, Hannes [mailto:[email-masked]] 
> Sent: Thursday, October 26, 2006 9:52 AM
> To: Charles Clancy; Bernard Aboba
> Cc: [email-masked]
> Subject: AW: [Emu] Tying EAP-TLS method type to specific ciphersuites
> 
>  Hi Charles,
> 
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Charles Clancy [mailto:[email-masked]]
> > Gesendet: Donnerstag, 26. Oktober 2006 18:45
> > An: Bernard Aboba
> > Cc: [email-masked]
> > Betreff: RE: [Emu] Tying EAP-TLS method type to specific 
> ciphersuites
> > 
> > So, it sounds like defining an EAP type code for EAP-TLS 
> with non-PKI 
> > ciphersuites sounds like the best way to go.  Would it be 
> appropriate 
> > to have IANA allocate a new EAP type code with 2716bis, or have a 
> > seperate document discussing EAP-TLS with TLS-PSK ciphersuites?
> 
> A separate document is needed since the security properties 
> are different.
> You need to describe them somewhere. 
> 
> Example:
> draft-otto-emu-eap-tls-psk-01.txt
> 
> For some other ciphersuites you even need todo more. 
> Example: A Kerberos based TLS ciphersuite
> 
> Ciao
> Hannes
> 
> 
> > 
> > --
> > t. charles clancy, ph.d.  <>  [email-masked]  <>  
> www.cs.umd.edu/~clancy
> > 
> > 
> > On Mon, October 23, 2006 9:07 pm, Bernard Aboba wrote:
> > >>Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2
> > (PKI and PSK)?
> > >> Or
> > >>EAP-TLS-PKI and EAP-TLS-PSK?  If we have both legacy issues
> > AND footprint
> > >>issues, perhaps something like ...
> > >
> > > So far, we've talked about handling PSK support by creating
> > a new EAP
> > > method
> > > with a distinct name: "EAP-TLS-PSK".    That approach 
> > enables embedded
> > > devices to implement only PSK ciphersuites, reducing
> > footprint.   It also
> > > avoids impacting the interoperability and security of
> > existing EAP-TLS
> > > implementations.
> > >
> > > Given that EAP-TLS already supports PKI, I'm not sure why a
> > distinct EAP
> > > method called "EAP-TLS-PKI" would be needed.
> > >
> > > Creating "versions" of EAP-TLS would potentially confuse
> > customers and
> > > cause
> > > problems with existing test suites and certification
> > programs.  Witness
> > > the
> > > confusion that was created by PEAP versioning, where PEAPv0
> > and PEAPv1 did
> > > not interoperate.   So I'd stay away from versioning if at 
> > all possible.
> > >
> > >
> > >

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 26 Oct 2006 22:29:04 -0700

I don't think we would go down the route of making other types of
ciphersuites mandatory to implement.  

> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, October 23, 2006 9:17 AM
> To: [email-masked]
> Subject: RE: [Emu] Tying EAP-TLS method type to specific ciphersuites
> 
> During the EMU BOF we talked about the high cost that would 
> be imposed on customers by introducing new non-certificate 
> ciphersuites during EAP-TLS.
> 
> EAP-TLS is now ten years old, and has a very large installed base.  
> Virtually all of these installations only support 
> certificate-based authentication, since that is a requirement 
> of RFC 2716, which states:
> 
>    If the EAP server is not resuming a previously established
>    session, then it MUST include a TLS server_certificate handshake
>    message, and a server_hello_done handshake message MUST be the last
>    handshake message encapsulated in this EAP-Request packet....
> 
>    If the EAP server sent a certificate_request message in 
> the preceding EAP-Request packet, then
>    the peer MUST send, in addition, certificate and 
> certificate_verify handshake messages.
> 
> As a result of these and other specification requirements, an 
> implementation that does not support certificate 
> authentication is non-compliant with RFC 2716.
> 
> During the BOF we also talked about the drawbacks of 
> attempting to support 
> both certificate and non-certificate modes in a single EAP 
> method.   Such an 
> approach would require embedded systems to take on the 
> footprint of certificate handling even when all they really 
> needed to do was to support pre-shared keys.  It would also 
> add new potential security vulnerabilities to one of the few 
> EAP methods that has provable security properties.
> 
> In addition adding new non-certificate modes would impose 
> large costs on customers. Today there are interoperability 
> and conformance test suites for EAP-TLS that assume that only 
> certificate-based authentication is supported. 
>   In addition, EAP-TLS has been approved for use within FIPS 
> 140-2 installations, based on support for certificate-base 
> ciphersuites.  
> Introducing new non-certificate modes would introduce 
> confusion, and would force existing test suites to be re-written.
> 
> For customers, deployment of EAP is difficult enough without 
> introducing confusion, interoperability problems and new 
> security vulnerabilities into the one EAP method that today 
> is synonmous with high security.
> 
> 
>