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

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Sun, 22 Oct 2006 21:40:44 -0700

We have had discussions on limiting the ciphersuites that are supported
by EAP-TLS in the past.  In particular it seemed that there was some
leaning towards limiting it to certificate based ciphersuites.  For the
most part this seems unnecessary since TLS supports ciphersuite
negotiation.  However some have raised the concern that negotiating the
use of different credentials may not be appropriate at the TLS level.
If this is the case then one approach would be to assign different EAP
method types to different types of ciphersuites. 

Do people see the need to limit the types of ciphersuites that can be
negotiated within EAP-TLS?  

If so what would be the appropriate way to divide up the ciphersuites
with method types? 

Thanks,

Joe

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 23 Oct 2006 09:17:00 -0700

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.

---

From: "Charles Clancy" <[email-masked]>
Date: Mon, 23 Oct 2006 12:17:52 -0400 (EDT)

> negotiated within EAP-TLS?

In general, no.

> If so what would be the appropriate way to divide up the ciphersuites

When going down this road, it's difficult to tell where you should stop. 
The first step would be splitting PSK and PKI into two different EAP
types.  The problem is that the argument for doing the first split can be
recursively applied until we have a different EAP type code for every
EAP-TLS ciphersuite.

I think the point of EAP-level vs TLS-level credential negotiation is
valid from a protocol standpoint, but of insignificant importance in
real-world deployments.  For example, I've yet to encounter an 11i network
that supports more than a single EAP type for authentication.

Are we trying to solve a non-existant problem?  Are there *real-world*
scenarios (i.e. something someone has actually encountered, and not a
hypothetical corner case) where this would be a *real* issue?

-- 
t. charles clancy, ph.d.  <>  [email-masked]  <>  www.cs.umd.edu/~clancy

---

From: "Charles Clancy" <[email-masked]>
Date: Mon, 23 Oct 2006 12:28:37 -0400 (EDT)

So that answers the questions from my last email.  It sounds like PKI vs
PSK is a reasonable split, but for reasons somewhat unrelated to EAP vs
TLS credential negotiation, which I don't see as a big problem,
personally.

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

  EAP-TLS-v1
  EAP-TLS-v2-PSK
  EAP-TLS-v2-PKI

... might be appropriate.

---

From: Badra <[email-masked]>
Date: Mon, 23 Oct 2006 20:43:28 +0200

So what Joe did propose is the appropriate way: assign different EAP
method types to different types of ciphersuites.

> negotiated within EAP-TLS?

I think it is better to keep TLS ciphersuite negotiation as it is.
Best regards,
Badra

On 10/23/06, Charles Clancy <[email-masked]> wrote:
> > both certificate and non-certificate modes in a single EAP method.
> Such
> > an

---

From: "Ray Bell" <[email-masked]>
Date: Mon, 23 Oct 2006 11:58:00 -0700

There appears to be a requirement for either approach, or a combination of
both.  I thought Charles' suggestion made sense.

Ray

  _____  

From: Badra [mailto:[email-masked]] 
Sent: Monday, October 23, 2006 11:43 AM
To: Charles Clancy
Cc: Bernard Aboba; [email-masked]
Subject: Re: [Emu] Tying EAP-TLS method type to specific ciphersuites

Best regards,

Badra

EAP-TLS-v1
EAP-TLS-v2-PSK
EAP-TLS-v2-PKI

> [email-masked]  <mailto:[email-masked]>

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 23 Oct 2006 18:07:43 -0700

>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: <[email-masked]>
Date: Wed, 25 Oct 2006 10:04:23 +0300

Bernard Aboba wrote:
> 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.
>
> 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.

By certificate-based ciphersuites, do you mean TLS_RSA_WITH_*
ciphersuites from RFC 2246 specifically, or any ciphersuite that 
uses any kind of certificates?

(To me it looks like many of these arguments would also suggest
defining a separate EAP type code for e.g. ECC certificates
based on the RFC 4492 ciphersuites. I don't think that would
be a good idea...)

Best regards,
Pasi

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 25 Oct 2006 08:02:57 -0700

>uses any kind of certificates?

Any ciphersuite supporting client certificate authentication would be ok.

>based on the RFC 4492 ciphersuites. I don't think that would

I'd agree.  It isn't necessary to have a new EAP method for each 
ciphersuite.

---

From: "Charles Clancy" <[email-masked]>
Date: Thu, 26 Oct 2006 12:44:49 -0400 (EDT)

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?

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Thu, 26 Oct 2006 18:51:45 +0200

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
> 

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

> >>Should the split be EAP-TLS-v1 (PKI only) vs EAP-TLS-v2 
> (PKI and PSK)?
> >> Or
> > So far, we've talked about handling PSK support by creating 
> a new EAP
> > method
> > Creating "versions" of EAP-TLS would potentially confuse 
> customers and
> > cause
> > problems with existing test suites and certification 
> programs.  Witness
> > the