Hi Joe,
Since we are talking about a Authentication and Key establishment
protocol, any optimizations that come with combined modes are not
really crucial. On the other hand, it is not too difficult to use
them without multiple integrity checksums. If there is interest,
sure I can help specify that.
We started with EAX and I was curious about why and did some
investigation. Others did too and suggested CCM perhaps to reuse the
802.11i choice of algorithm. When the discussion about two integrity
checksums started, we were quick to move off of combined modes.
I submit that we don't need to rule them out. Let's specify how to
use them properly. We don't need to belabor the topic so much
really. As I noted, I am willing to put the time to write the text.
thanks,
Lakshminath
At 04:10 PM 8/28/2006, 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
