Hi Joe,
a ciphersuite consisting of AES-CBC and AES-CMAC seems reasonable,
but we should strive to make sure that the method that derives keys
for these algorithms is FIPS-140 approved, so that a module
implementing all three methods can be validated. The KDFs defined in
draft-dang-nistkdf-01.txt meet this requirement, but would require
that a hash function like SHA-256 be present. Still, this seems like
a decent way to go because at least it keeps SHA-256 out of the data-
processing path, and the alternate ciphersuite that you mention has
it there.
David
On Oct 3, 2006, at 3:04 PM, Joseph Salowey ((jsalowey)) wrote:
Here is my suggestion for resolving the ciphersuite issue:
We need to define a small set (preferably one, maybe two) of mandatory
to implement ciphersuites for GPSK. The mandatory to implement ciphers
should exercise the features of GPSK. This would suggest that it
should
be a block cipher based ciphersuite. It seems a reasonable choice is
AES-CBC with AES-CMAC. This makes use of a single base algorithm
using
relatively simple modes of operation.
The HMAC-SHA256 ciphersuite should also be described, but is not
mandatory to implement.
Does this seem reasonable? Any objections?
Thanks,
Joe
_______________________________________________
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
