Subject: RE: [Emu] EMU PSK Method work Item

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Wed, 1 Feb 2006 11:01:51 -0500

Joe:

I wonder whether we should look at the strong shared secret method
alone. It seems we might achieve this goal and the two other work group
items, TLS-based EAP method and existing password database support,
using a single EAP method, e.g., a TLS based EAP method supporting PSK.
This would save us the work of trying to define two or three EAP
methods. One thing might help us is to define what exactly is "strong
shared secret", "compact", and "simple" in a requirement or problem
statement. They might be expressed in turns of desired number of
exchanges, computing power, cipher suites limitations, etc. The security
requriements are already addressed by RFC 4017. I suggest we do the same
for the other two items. Then we can evaluate whether it is feasible to
achieve the three goals with a single EAP method and go from there.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Joseph Salowey (jsalowey)
> Sent: Monday, January 30, 2006 12:22 AM
> To: [email-masked]
> Subject: [Emu] EMU PSK Method work Item
> 
> The first work item on the EMU charter is to start work on a 
> shared secret EAP method.  The item on the charter is:
> 
> "A mechanism based on strong shared secrets that meets RFC 
> 3748 and RFC 4017 requirements. This mechanism should strive 
> to be simple and compact for implementation in resource 
> constrained environments."
> 
> The emphasis here is to create a simple, secure mechanism to 
> support pre shared secret keys.  Support for optional 
> enhancements may be considered in the design as long as it 
> does not bog down the progress of the work item.  Current 
> work in this area which should be considered in the design including:
> 
> EAP-PAX - draft-clancy-eap-pax-06.txt
> EAP-PSK - draft-bersani-eap-psk-09.txt
> EAP-SAKE - draft-vanderveen-eap-sake-00.txt
> EAP-IKEv2 - draft-eronen-ipsec-ikev2-eap-auth-04.txt
> TLS-PSK - RFC4279
> 
> Please send email to the chairs if you are interested in 
> participating as a contributor on the shared secret method 
> design team along with a description of your experience.
> 
> _______________________________________________
> 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: "Bernard Aboba" <[email-masked]>
Date: Wed, 01 Feb 2006 09:55:39 -0800

It seems we might achieve this goal and the two other work group
>using a single EAP method, e.g., a TLS based EAP method supporting PSK.

One of the attractions of PSK is to implement it on an embedded device.  So 
while it is possible to address the PSK work item using a TLS-derived 
protocol, attempting to glom this onto the EAP-TLS specification is a bad 
idea. Since EAP-TLS *requires* certificate support, adding PSK on to it 
would effectively require embedded devices to include certificate support 
just to support PSK, whether they needed to support certificates or not.  
This would greatly increase the required footprint.

Of course, EMU WG could create a new protocol based on TLS that would 
*require* PSK support and allow optional certificate support.  However, this 
would not be EAP-TLS but something new.

---

From: Thomas Otto <[email-masked]>
Date: Wed, 1 Feb 2006 22:08:41 +0100

Am Mittwoch, 1. Februar 2006 17:01 schrieb Hao Zhou (hzhou):

> requriements are already addressed by RFC 4017. 

I do not think that the security requirements of RFC 4017 are comprehensive.
We should re-think about the requirements. What about, for instance, 

* strong identity protection?
* denial-of-service resistance?
* non-repudiation?

They are not covered by RFC 4017, but seem to be worth to be taken into
account.

My advise is to define a requirement catalogue apart from RFC 4017.
Therefore, the current EAP deployments should be analyzed (e.g. EAP is used
in 802.11, 802.16, IKEv2, TLS, 3G networks...) and the specific 
characteristics of these environments elaborated. Second, intended / future 
application scenarios should be taken into account (mesh networks, p2p, ...). 

And: We should define a metric, that is, each requirement should get a weight
factor. One example: The assertion: "avoid TLS and public key cryptography
with regard to shared secret methods, because public key cryptography is 
too expensive. 
There are a lot of ways to make TLS lightweight, e.g. by exploting the session
resumption mode, or by using pre-shared key ciphersuites, or by variing  the 
cryptographic key strength (e.g. do we really need 3072-modp DH or does it
suffice to take 2048 bit group).  To answer cryptographic-related functions, 
cryptographicexperts should be asked for their advise.
So, the argument to avoid public key cryptography is weak and must be refined.
Next to the categorization of mandatory, recommended and optional, one might
refine the value of the security requirement by a weight factor.

That's for now, bottom line and start point for further discussions: RFC 4017
is not comprehensive.

Thomas

---

From: Thomas Otto <[email-masked]>
Date: Wed, 1 Feb 2006 22:08:41 +0100

Thomas

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 01 Feb 2006 15:36:27 -0800

>the specific characteristics of these environments elaborated. Second, 
>intended / future

Thomas is correct that RFC 4017 only expresses requirements for WLAN 
authentication in IEEE 802.11 infrastructure networks.  However, the 
requirements for usage in other scenarios such as mesh may be different.

We have seen interest in use of EAP in mesh network scenarios, but so far it 
has been difficult to see how existing methods can be applied to those 
scenarios.  For example, TLS is a client/server protocol so that EAP-TLS is 
also client/server.  That means that in a peer to peer situation a node may 
need two certificates - a TLS client cert and a TLS server certificate.  It 
also must implement both the EAP TLS peer and EAP TLS server roles.   That 
may be more than is reasonable in an embedded device.

Other issues arise as well.  For example, a method which focuses on 
verifying the client claim of identity, but does not allow the server to 
identify itself will not work well in a peer-to-peer environment, since two 
EAP authentications (one in each direction) would be required.

---

From: Magnus Nyström <[email-masked]>
Date: Thu, 2 Feb 2006 14:53:27 +0100 (W. Europe Standard Time)

But could not EAP-TLS be modified/updated to also allow "pure" TLS-PSK, 
without requiring use of server certificates? AFAICS this would still be 
TLS, not "TLS-derived" or "based on TLS".

-- Magnus

On Wed, 1 Feb 2006, Bernard Aboba wrote:

>> It seems we might achieve this goal and the two other work group items, 
>> TLS-based EAP method and existing password database support, using a 
>> single EAP method, e.g., a TLS based EAP method supporting PSK.
>
> One of the attractions of PSK is to implement it on an embedded device. 
> So while it is possible to address the PSK work item using a TLS-derived 
> protocol, attempting to glom this onto the EAP-TLS specification is a 
> bad idea. Since EAP-TLS *requires* certificate support, adding PSK on to 
> it would effectively require embedded devices to include certificate 
> support just to support PSK, whether they needed to support certificates 
> or not.  This would greatly increase the required footprint.
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 02 Feb 2006 08:38:11 -0800

>TLS, not "TLS-derived" or "based on TLS".

RFC 2716 requires support for certificate authentication.   Making this 
optional would break backward compatibility of a protocol that has been 
widely deployed.  Depending on the behavior of existing implementations it 
might be possible to add PSK as an optional feature -- but this would not 
satisfy the needs of embedded device developers, so you'd probably need a 
separate PSK-only method anyway.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 04 Feb 2006 14:35:20 -0500

>>>>> "Bernard" == Bernard Aboba <[email-masked]> writes:

    >> But could not EAP-TLS be modified/updated to also allow "pure"
    >> TLS-PSK, without requiring use of server certificates? AFAICS
    >> this would still be TLS, not "TLS-derived" or "based on TLS".

    Bernard> RFC 2716 requires support for certificate authentication.
    Bernard> Making this optional would break backward compatibility
    Bernard> of a protocol that has been widely deployed.  Depending
    Bernard> on the behavior of existing implementations it might be
    Bernard> possible to add PSK as an optional feature -- but this
    Bernard> would not satisfy the needs of embedded device
    Bernard> developers, so you'd probably need a separate PSK-only
    Bernard> method anyway.

Bernard, I think a simpler and more constructive way of saying what
you're trying to say here is that "yes, you could do that but you
would need a new type code and you would need to separate it from the
existing spec."

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 04 Feb 2006 16:51:01 -0800

>would need a new type code and you would need to separate it from the

An EAP method with a new type code that is separated from the existing spec 
would not be EAP-TLS.  It would be a new protocol.  So as to avoid 
confusion, it would be best to use a different name, such as "EAP-TLS-PSK".

---

From: Jari Arkko <[email-masked]>
Date: Tue, 07 Feb 2006 15:35:02 +0200

Bernard Aboba wrote:

>
> An EAP method with a new type code that is separated from the existing 
> spec would not be EAP-TLS.  It would be a new protocol.  So as to 
> avoid confusion, it would be best to use a different name, such as 
> "EAP-TLS-PSK".

Right.

--Jari