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 | +---++-+---++ | 0x01 | 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 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
AW: [Emu] EAP-GPSK: Ciphersuites
Hi Lakshminath, I am not sure that the group wants to use CCM. (If you are referring to this part of your mail.) Ciao Hannes -Ursprüngliche Nachricht- Von: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] Gesendet: Dienstag, 22. August 2006 11:44 An: Hannes Tschofenig Cc: emu@ietf.org Betreff: Re: [Emu] EAP-GPSK: Ciphersuites 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-se cret-01.txt still supports AES-EAX: +---++-+---++ | CSuite/ | KS | Encryption | Integrity | Key Derivation | | Specifier || | | Function | +---++-+---++ | 0x01 | 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 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
[Emu] EAP-GPSK: Ciphersuites
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 | +---++-+---++ | 0x01 | 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 Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
