> -----Original Message----- > From: Hannes Tschofenig [mailto:[EMAIL PROTECTED] > Sent: Monday, August 28, 2006 11:37 AM > To: Joseph Salowey (jsalowey) > Cc: Charles Clancy; Lakshminath Dondeti; [email protected] > Subject: Re: [Emu] EAP-GPSK: Ciphersuites > > Hi Joe, > > I don't think that we on-the-fly want to use new algorithms > as they come available.
[Joe] Not sure what you mean by on the fly, but I think it would be bad to have to rewrite large portions of EAP-GPSK to make use of a new algorithm. Based on Bernhard's experience with > EAP-TLS I got the impression that most EAP implementers and > users are not really excited about updating their > implementation whenever a new algorithm becomes available. > [Joe] However, new algorithms are implemented and requirements for algorithm agility exist. > Furthermore, if new algorithms become available we need to > specify a ciphersuite that makes sense for the given environment. > > The most difficult part with protocol design is to sometimes > say NO when features and optimizations are proposed. > [Joe] True, but an analysis of the cost and benefits should be done. It is also not good to end up with a protocol that is obsolete when a new algorithm is required. > Ciao > Hannes > > > Joseph Salowey (jsalowey) schrieb: > > We want to define GPSK as a framework that can accommodate new > > algorithms when they are available. I believe that Lakshminath is > > looking to allow optimizations within this framework in the > case where > > a combined mode cipher is used. At this point I'm not sure > how much > > complexity this would add to the specification. If it can be done > > simply then it might be worthwhile pursuing, perhaps David > McGrew's > > AEAD specification would help here. > > > > > > > >> -----Original Message----- > >> From: Charles Clancy [mailto:[EMAIL PROTECTED] > >> Sent: Tuesday, August 22, 2006 4:05 AM > >> To: Lakshminath Dondeti > >> Cc: [email protected] > >> Subject: Re: [Emu] EAP-GPSK: Ciphersuites > >> > >> Interesting idea, but what does it gain you? Why not just use an > >> AES-CBC and CMAC ciphersuite? > >> > >> -- > >> t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy > >> > >> Lakshminath Dondeti wrote: > >>> I guess we agree to disagree. The addition integrity checksum is > >>> spurious in my view and I believe we can define things so that > >>> combined modes can be employed without encrypting > anything, so I am > >>> somewhat confused here. What's your opinion on the latter > >> part of my email? > >>> thanks, > >>> Lakshminath > >>> > >>> At 05:12 PM 8/22/2006, Hannes Tschofenig wrote: > >>>> Hi Lakshminath, > >>>> > >>>> Lakshminath Dondeti schrieb: > >>>>> At the expense of generating some confusion, here is my > >> take on this: > >>>>> The objection is to having to carry multiple integrity > >> checksums in > >>>>> GPSK, if we used the combined mode *and* an integrity algorithm. > >>>> I don't agree with you. There is no reason to optimize a > >> few bits in > >>>> a pre-shared secret method. > >>>> Note that we are not talking about a protocol for data transfer. > >>>> We wanted the flexibility to use different cipher suites. > >> We do not > >>>> only want to use cipher suites that provide authenticated > >> encryption > >>>> (since we almost have nothing to encrypt; currently 1 bit > >> and almost > >>>> no EAP method provides this functionality). > >>>> > >>>> Ciao > >>>> Hannes > >>>> > >>>>> I think CCM is fine for instance, the only catch is that > >> we need to > >>>>> make sure and define AAD for CCM carefully to include > appropriate > >>>>> data into the integrity checksum calculation. So, once > we define > >>>>> CCM as the mode, we shouldn't need AES-CMAC-128 if > >> encryption is being used. > >>>>> I would suggest using CCM and specifying the use of it > >> fully so it > >>>>> can be used without misunderstandings. If you want me to > >> put some > >>>>> time into writing that up, let me know. > >>>>> cheers, > >>>>> Lakshminath > >>>>> At 10:55 PM 8/20/2006, Hannes Tschofenig wrote: > >>>>>> Hi all, > >>>>>> > >>>>>> the current version of the document > >>>>>> > >> http://tools.ietf.org/wg/emu/draft-clancy-emu-eap-shared-secret-01. > >>>>>> txt > >>>>>> still supports AES-EAX: > >>>>>> > >>>>>> > >>>>>> > >> > +-----------+----+-------------+---------------+--------------------+ > >>>>>> | CSuite/ | KS | Encryption | Integrity | Key > >>>>>> Derivation | > >>>>>> | Specifier | | | | > >>>>>> Function | > >>>>>> > >>>>>> > >> > +-----------+----+-------------+---------------+--------------------+ > >>>>>> | 0x000001 | 16 | AES-EAX-128 | AES-CMAC-128 | > >>>>>> GKDF-128 | > >>>>>> > >>>>>> > >> > +-----------+----+-------------+---------------+--------------------+ > >>>>>> At the IETF#66 EMU meeting AES CCM was suggested. > >>>>>> > >>>>>> Later, it got the impression that AES-CBC was more > appreciated. > >>>>>> Should we update the draft with AES-CBC? > >>>>>> > >>>>>> Ciao > >>>>>> Hannes > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> Emu mailing list > >>>>>> [email protected] > >>>>>> https://www1.ietf.org/mailman/listinfo/emu > >>> > >>> _______________________________________________ > >>> Emu mailing list > >>> [email protected] > >>> https://www1.ietf.org/mailman/listinfo/emu > >> _______________________________________________ > >> Emu mailing list > >> [email protected] > >> https://www1.ietf.org/mailman/listinfo/emu > >> > > > > _______________________________________________ > > Emu mailing list > > [email protected] > > https://www1.ietf.org/mailman/listinfo/emu > > > > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
