RE: [Emu] EMU PSK Method work Item

["Bernard Aboba" <[e-mail]>]

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.

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.



>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: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Joseph Salowey (jsalowey)
> > Sent: Monday, January 30, 2006 12:22 AM
> > To: [e-mail]
> > 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
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/emu
> >
>
>_______________________________________________
>Emu mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/emu



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