RE: [Emu] EMU PSK Method work Item

> 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.
Agreed. That's what I proposed. Notice I wrote TLS based EAP method, not
EAP-TLS. Having a requirement statement on the "small footprint" of the
PSK is the key to evaluate whether we can do it within a single EAP
method or not.

> -----Original Message-----
> From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] 
> Sent: Wednesday, February 01, 2006 12:56 PM
> To: Hao Zhou (hzhou); Joseph Salowey (jsalowey); emu@ietf.org
> Subject: RE: [Emu] EMU PSK Method work Item
> 
> 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: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] 
> On Behalf 
> > > Of Joseph Salowey (jsalowey)
> > > Sent: Monday, January 30, 2006 12:22 AM
> > > To: emu@ietf.org
> > > 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
> > > Emu@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/emu
> > >
> >
> >_______________________________________________
> >Emu mailing list
> >Emu@ietf.org
> >https://www1.ietf.org/mailman/listinfo/emu
> 

_______________________________________________
Emu mailing list
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu