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.
--
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
