Subject: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 5 Mar 2007 19:58:22 -0800

All,
I have a question on support for the TLS PSK ciphersuites in EAP-TLS.
Looking at the message flow in section 2.1.1, I don't see any reason why
the TLS PSK ciphersuites, as specified in RFC4279, cannot be used with
it, but, the optional TLS elements are not immediately clear from it and
hence, the question. 

Thanks,
Vidya

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 05 Mar 2007 23:28:52 -0800

According to RFC 2716, a compliant EAP-TLS implementation must support 
certificates.  Since the resources required to support certificates is much 
larger than the resources required for TLS-PSK, a combined method would not 
be optimal for use within an embedded environment.  There would also be 
substantial costs to adding support for additional authentication methods to 
EAP-TLS.  For example, EAP-TLS certification and testing programs have been 
developed which focus solely on certificate ciphersuites; rewriting those 
test suites would be costly.

By developing EAP-TLS-PSK as a separate EAP method an implementation can 
solely implement TLS-PSK while remaining compliant.  This permits EAP 
TLS-PSK implementations to be optimized for embedded environments.  As a 
side benefit, this approach also eliminates multiple levels of negotiation, 
which had been raised as a potential problem.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 6 Mar 2007 11:51:05 -0800

Hi Bernard,
Thanks much for the response. If we go down this path, are we then
saying that for every new ciphersuite that may be added to TLS, a
separate EAP method would need to be designed to support that in EAP?
Also, how is this different from TLS implementations having to support
the newer ciphersuites? 

I can understand the mandatory cert requirement in RFC2716, since at
that point of time, TLS did not have the PSK ciphersuites. But, now that
we are revising it, does it not make sense to support all the
ciphersuites supported in TLS? 

Also, could you please elaborate on the multiple negotiation problem?
Looking at the message flows in section 2.1 in
draft-otto-emu-eap-tls-psk-02 and section 2.1.1 in
draft-simon-emu-rfc2716bis-08, except for the certs portion, everything
else looks the same. 

Thanks,
Vidya

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Monday, March 05, 2007 11:29 PM
> To: Narayanan, Vidya; [email-masked]
> Subject: RE: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?
> 
> According to RFC 2716, a compliant EAP-TLS implementation 
> must support certificates.  Since the resources required to 
> support certificates is much larger than the resources 
> required for TLS-PSK, a combined method would not be optimal 
> for use within an embedded environment.  There would also be 
> substantial costs to adding support for additional 
> authentication methods to EAP-TLS.  For example, EAP-TLS 
> certification and testing programs have been developed which 
> focus solely on certificate ciphersuites; rewriting those 
> By developing EAP-TLS-PSK as a separate EAP method an 
> implementation can solely implement TLS-PSK while remaining 
> compliant.  This permits EAP TLS-PSK implementations to be 
> optimized for embedded environments.  As a side benefit, this 
> approach also eliminates multiple levels of negotiation,

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Tue, 6 Mar 2007 12:18:44 -0800

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Tuesday, March 06, 2007 11:51 AM
> To: Bernard Aboba; [email-masked]
> Thanks much for the response. If we go down this path, are we 
> then saying that for every new ciphersuite that may be added 
> to TLS, a separate EAP method would need to be designed to 
> support that in EAP?
> Also, how is this different from TLS implementations having 
> to support the newer ciphersuites? 
> 

[Joe] We have a charter item for enhanced TLS which could support other
types of ciphersuites along with other features. 

> I can understand the mandatory cert requirement in RFC2716, 
> since at that point of time, TLS did not have the PSK 
> ciphersuites. But, now that we are revising it, does it not 
> make sense to support all the ciphersuites supported in TLS? 
> 
> draft-simon-emu-rfc2716bis-08, except for the certs portion, 
> everything else looks the same. 
> 

[Joe] EAP negotiation happens early before TLS negotiation.  If a peer
or server negotiate a particular EAP method they may actually not
actually be able to complete this because TLS negotiation arrives upon
an result that is not satisfactory. Restricting EAP-TLS to certificate
based ciphers does not solve this problem, but it helps. In an enhanced
EAP-TLS the initial message from the server could indicate the supported
ciphers giving the chance for a client to NAK. 

> must support 
> > certificates.  Since the resources required to support 
> certificates is 
> > much larger than the resources required for TLS-PSK, a 
> combined method 
> > would not be optimal for use within an embedded environment.  There 
> > would also be substantial costs to adding support for additional 
> certification 
> > and testing programs have been developed which focus solely on 
> > certificate ciphersuites; rewriting those test suites would 
> be costly.
> > 
> implementation 
> > can solely implement TLS-PSK while remaining compliant.  
> This permits 
> > EAP TLS-PSK implementations to be optimized for embedded 
> environments.  
> > As a side benefit, this approach also eliminates multiple levels of 
> > negotiation, which had been raised as a potential problem.
> > 
> > 
> > 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 07 Mar 2007 12:45:49 +0200

We discussed this already several times and this lead me to work on a 
draft together with Thomas Otto:

http://tools.ietf.org/id/draft-otto-emu-eap-tls-psk-02.txt

Ciao
Hannes

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 07 Mar 2007 08:12:21 -0800

Hannes Tschofenig said:

>We discussed this already several times and this lead me to work on a draft 
>together with Thomas Otto:
>

Which begs the question:  what is the WG doing with this draft?

>From where I sit, it seems quite likely that EAP-TLS-PSK, if completed, will 
be deployed.  When TLS 1.2 is done, this method could eventually benefit 
from KDF negotiation, and should meet the criteria for FIPS 140-2 
certification.  Given the TLS code base in embedded systems, it should not 
be hard to add support for EAP-TLS-PSK within embedded devices.

I my doubts about EAP-GPSK on several of these dimensions.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 7 Mar 2007 13:28:28 -0800

Hi Joe, 

Let me separate this into different topics for clarity.  

> based ciphers does not solve this problem, but it helps. In an 
> enhanced EAP-TLS the initial message from the server could indicate 
> the supported ciphers giving the chance for a client to NAK.
> 
> 

1. TLS negotiations in EAP: 
---------------------------
I guess in a way, this is trying to perform some rudimentary TLS
ciphersuite negotiation at the EAP level. For regular TLS operation, I
can see clients connecting to just about any server. However, for EAP,
typically, the peer has an "association" with a certain server that at
least knows a list of methods that the peer or peers that have an
association with it support - that's how it knows what method to start
in the EAP Request following the EAP Response Identity. EAP doesn't
quite provide method negotiation per se - by using EAP NAKs, we can make
it soemthing of a negotiation. If the EAP server has no clue about the
peer attempting to authenticate or if the server does not have a
reasonable number of methods that it supports, the EAP exchange could
potentially go on with several NAKs and that wouldn't be good. By that
same principle, it seems like whatever would indicate to the server that
the client can do EAP-TLS-PSK (when that is a separate method) should
also indicate that the client can do EAP-TLS with PSK ciphersuites. 

2. TLS vs. EAP-TLS Implementations:
------------------------------------
I'm a bit concerned about supporting a subset of TLS in EAP-TLS. For
instance, consider a server that has a regular TLS implementation and
typically supports the PSK ciphersuites. For a client that talks TLS
directly to it, it allows negotiation of any ciphersuites, including the
PSK ones. However, for a client that talks TLS via EAP, it needs to make
sure that only a subset of the TLS ciphersuites are provided as an
option. So, in this case, EAP is not just a carrier for the TLS
authentication method - EAP then only supports one "profile" of TLS, so
to say. 

If we think that optimizations can be supported by having a separate
EAP-TLS-PSK method, we may still want to do that, but, precluding the
use of certain TLS ciphersuites with EAP-TLS seems restrictive. 

3. Client authentication in EAP-TLS:
------------------------------------
I also notice that client authentication is optional as written in
draft-simon-emu-rfc2716bis. When would peer authentication ever be
optional for EAP operation? I realize this is something that came from
TLS, since client authentication is truly optional in TLS (and that
makes sense in certain uses of TLS). However, in the context of EAP,
that seems strange. If we were to follow the same notions about optional
TLS elements as in RFC4346 (or 4346bis), the server certificate would
also then be optional. 

Vidya

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 7 Mar 2007 20:49:51 -0800

> Sent: Wednesday, March 07, 2007 8:12 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Emu] RFC4279 support in draft-simon-emu-rfc2716bis?
> 
> Hannes Tschofenig said:
> 

[Joe] The draft is not currently a working group item.  The pre-shared
key mechanism charter item is covered by EAP-GPSK.  There is a charter
item for enhanced EAP-TLS which could support TLS-PSK and other
enhancements.  

> >From where I sit, it seems quite likely that EAP-TLS-PSK, if 
> completed, 
> >will
> be deployed.  When TLS 1.2 is done, this method could 
> eventually benefit from KDF negotiation, and should meet the 
> criteria for FIPS 140-2 certification.  Given the TLS code 
> base in embedded systems, it should not be hard to add 
> support for EAP-TLS-PSK within embedded devices.
> 
[Joe] The KDF needs to be looked at, but I do not think it is
necessarily a show stopper, it does provide KDF agility.  Reports from
people who implemented EAP-GPSK indicate that it was simple to
implement. I have heard push back from embedded system implementers on
EAP-TLS stating that it is too complex, this may be a result of
certificate support I am not sure.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 7 Mar 2007 20:55:30 -0800

> Sent: Wednesday, March 07, 2007 1:28 PM
> To: Joseph Salowey (jsalowey); Bernard Aboba; [email-masked]
> I guess in a way, this is trying to perform some rudimentary 
> TLS ciphersuite negotiation at the EAP level. For regular TLS 
> operation, I can see clients connecting to just about any 
> server. However, for EAP, typically, the peer has an 
> "association" with a certain server that at least knows a 
> list of methods that the peer or peers that have an 
> association with it support - that's how it knows what method 
> to start in the EAP Request following the EAP Response 
> Identity. EAP doesn't quite provide method negotiation per se 
> - by using EAP NAKs, we can make it soemthing of a 
> negotiation. If the EAP server has no clue about the peer 
> attempting to authenticate or if the server does not have a 
> reasonable number of methods that it supports, the EAP 
> exchange could potentially go on with several NAKs and that 
> wouldn't be good. 

[Joe] EAP provides negotiation and it is even used in real networks.  I
agree it is not ideal, but it is what we have. 

>By that same principle, it seems like 
> whatever would indicate to the server that the client can do 
> EAP-TLS-PSK (when that is a separate method) should also 
> indicate that the client can do EAP-TLS with PSK ciphersuites. 
> 

[Joe] I'm not sure what principle you are referring to so I don't see
how it can be applied to this problem.  The client tells the server it
supports method x by responding to the server's challenge for method x.
The ciphersuite is not available in the initial challenge. One could
modify EAP-TLS such ciphersuites are advertised in the EAP-TLS start,
but this would interfere with backwards capability, hence there is a
charter item for enhanced TLS. 

> I'm a bit concerned about supporting a subset of TLS in 
> EAP-TLS. For instance, consider a server that has a regular 
> TLS implementation and typically supports the PSK 
> ciphersuites. For a client that talks TLS directly to it, it 
> allows negotiation of any ciphersuites, including the PSK 
> ones. However, for a client that talks TLS via EAP, it needs 
> to make sure that only a subset of the TLS ciphersuites are 
> provided as an option. So, in this case, EAP is not just a 
> carrier for the TLS authentication method - EAP then only 
> supports one "profile" of TLS, so to say. 
> 
[Joe] Most TLS libraries support "profiling" of TLS ciphersuites for
different applications and deployments.  

> If we think that optimizations can be supported by having a 
> separate EAP-TLS-PSK method, we may still want to do that, 
> but, precluding the use of certain TLS ciphersuites with 
> EAP-TLS seems restrictive. 
> 
[Joe] It is not necessary to put restrictions on an enhanced EAP-TLS
since it does not have the same backwards compatible expectations as
EAP-TLS.  

> I also notice that client authentication is optional as 
> written in draft-simon-emu-rfc2716bis. When would peer 
> authentication ever be optional for EAP operation? 
>I realize 
> this is something that came from TLS, since client 
> authentication is truly optional in TLS (and that makes sense 
> in certain uses of TLS). However, in the context of EAP, that 
> seems strange. If we were to follow the same notions about 
> optional TLS elements as in RFC4346 (or 4346bis), the server 
> certificate would also then be optional. 
> 

[Joe] There are EAP  use cases where peer authentication is not required
but server authentication is.  There are also instances where anonymous
ciphersuites are used, but the trade off in security is much more severe
with anonymous ciphersuites.

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 07 Mar 2007 20:59:40 -0800

>certificate support I am not sure.

In my experience, adding certificate support dramatically increases 
footprint.  For example, as I recall IKEv1/IPsec with AES CBC/HMAC-SHA1 is 
around 250 KB or so if we're just talking about pre-shared key 
authentication but if you add certificate support that is another 750 KB, 
which will be too big for some applications.

I would think that the same logic applies to EAP-TLS-PSK.  Of course that 
would require a stripped down implemenation of TLS that only supported 
TLS-PSK, no certificates.  I guess that doesn't exist yet?  If you had to 
pull in all of say, Open SSL plus add TLS-PSK support, that would almost 
certainly make it too large for many embedded applications.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 7 Mar 2007 21:08:10 -0800

> Sent: Wednesday, March 07, 2007 9:00 PM
> To: Joseph Salowey (jsalowey); [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> In my experience, adding certificate support dramatically 
> increases footprint.  For example, as I recall IKEv1/IPsec 
> with AES CBC/HMAC-SHA1 is around 250 KB or so if we're just 
> talking about pre-shared key authentication but if you add 
> certificate support that is another 750 KB, which will be too 
> big for some applications.
> 
> I would think that the same logic applies to EAP-TLS-PSK.  Of 
> course that would require a stripped down implemenation of 
> TLS that only supported TLS-PSK, no certificates.  I guess 
> that doesn't exist yet?  If you had to pull in all of say, 
> Open SSL plus add TLS-PSK support, that would almost 
[Joe] Yes OpenSSL is a commonly used toolkit, however I don't think one
of its design goals is a small footprint.