> -----Original Message----- > From: Charles Clancy [mailto:[EMAIL PROTECTED] > Sent: Monday, August 28, 2006 8:27 PM > To: [email protected] > Subject: Re: [Emu] EAP-GPSK: Ciphersuites > > Lots of interesting conversation... > > Being ciphersuite-modular doesn't mean we have to give up all > control or write a protocol that would work in every possible > case. I don't see any reason to add optimizations to support > CCM/EAX-like primitives when there's no reason to use them in > the first place. Both supporting them and using them adds > unnecessary complexity. > > IMHO, the ciphersuites should be AES-CBC with a suitable MAC > (I'm flexible here) and HMAC-256, with HMAC-256 mandatory to > implement because it would most easily achieve FIPS140-2 > certification. > > Is there general consensus on this part? There seems to be > more contention on which MAC should be used with an AES-based > ciphersuite.
[Joe] I personally would prefer to have a mandatory to implement encrypting ciphersuite. I'm also flexible when it comes to which AES MAC is used, either XCBC or OMAC is fine. > > -- > t. charles clancy, ph.d. <> [EMAIL PROTECTED] <> www.cs.umd.edu/~clancy > > Joseph Salowey (jsalowey) wrote: > > Hi Lakshminath, > > > > I have not seen a lot of support for use of CCM/EAX with or without > > the optimization of eliminating additional MAC algorithm on > the list. > > I think it would be useful to understand what the impact is on the > > current specification to support ciphers that provide both > integrity > > protection and encryption without requiring additional MAC > algorithms. > > Would the current spec need to be modified to support this? If so, > > what modifications are needed? > > > > Thanks, > > Joe > > > > > >>-----Original Message----- > >>From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] > >>Sent: Sunday, August 20, 2006 12:23 AM > >>To: Hannes Tschofenig; [email protected] > >>Subject: Re: [Emu] EAP-GPSK: Ciphersuites > >> > >>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 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-secr > >> > >>et-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
