Hi David,
I have a problem with the suggested approach for a couple of reasons:
* There is no problem with the currently defined cipher suites. The
design team has just picked something; Different cipher suites got
proposed during the design team discussions and almost all of them got
removed from the document. As you saw from the discussions and my previous
mail to the EMU mailing list it seems that there is a shift towards AES
CBC. That's fine with me.
I agree with Hannes here.
To date, EMU documents have been consistent with respect to the choice of
ciphersuites - rmandating 3DES/HMAC-SHA1 ciphersuites today, transitioning
to AES CBC tommorrow.
Introducing a dependency on AES CCM for EAP GPSK is not advisable at this
time, since FIPS 140-2 certified libraries for AES CCM are not common today,
whereas support for AES CBC is more widespread.
* I don't like the split into two documents since it makes a simple
protocol complicated. For EAP-GPSK I don't think that we will see 10+
cipher suites being proposed.
The goal for EAP GPSK was to produce a simple, low footprint method that
could be implemented easily in embedded devices. Splitting the
specification in two parts, and introducing 10+ ciphersuites runs counter
to that goal and and could risk introducing interoperability problems.
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
