[LinkSec] Ciphersuites, associated data and auth-only modes
During the conference call discussion on ciphersuites, I agreed to come
back with a revised ciphersuite table that includes what was discussed
in the call. I think the reflector discussion has moved things along a
bit as well.
So here goes. A fixed width font will help here..
The ciphersuite selector is [OUI || ID]. This will be specified from a
negotiation that happens elsewhere.
________________________________________________________________________
| Selector | | |
|
| OUI | ID | Name | Section | M/O
|
|_____________________|______________________________|____________|_____
|
| 00:00:00 | 0 | NULL | a.b.c | M
|
| 00:00:00 | 1 | AES-CCM-128 | d.e.f | M
|
| 00:00:00 | 2 | AES-OCB-128 | g.h.i | O
|
| 00:00:00 | 3 | OMAC [or HMAC-SHA256/PMAC?] | j.k.l | O
|
| 00:00:00 | 4-240 | Reserved | m.n.o |
|
| 00:00:00 | 241-255 | Playpen area | p.q.r |
|
|___________|_________|______________________________|____________|_____
|
* A Non zero OUI will indicate a vendor proprietary mode.
* OUI=00:00:00 with 240<ID<256 are reserved for playpen use. These may
be used for experimental purposes but should not be used in products.
Rational:
NULL: To allow link security to be turned off for those that
want to
AES-CCM-128 : A mandatory default mode to address lower speeds (
say. < 500mbps ) and a default for crossing provider bridges.
AES-OCB-128 : An optional mode, but in all practical senses
mandatory if you need to go faster (say > 1Gbps )
HMAC-SHA256 : An authentication only mode. Could be one of
HMAC-SHA, OMAC, PMAC or others TBD
Reserved : Reserved for future standardized modes
Playpen : To allow experimental use without risk of ID collision
with other products
Non zero OUI : To permit vendor proprietary modes
Points for discussion..
There is this idea that products that have a high line speed will need
to use OCB mode to achieve the necessary crypto speed. The hope is
therefore that any two fast products will support OCB and will be able
to interoperate. However there is a grey area between around 500mbps and
4gbps where you could squeeze CCM to perform and so there is the risk of
non interoperability. Maybe we should specify where the dividing line
really is in order to eliminate the grey area. E.G. "AES-OCB-128 is
mandatory above 1.1 gbps".
Auth only mode : Our choices are wider here. HMAC-SHAn is known and
loved, but there are alternatives that use the same underlaying block
cipher as the crypto modes (a nice property), parallel modes (PMAC),
really fast modes (UMAC), Almost NIST approved modes (OMAC) and the list
could go on.
Associated data: CCM obviously handles a chosen length of associated
data. It is less obvious with OCB however Rogaway has described an AD
algorithm extension to OCB that does just this
(http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-back.htm#associated-data),
so I see no problem with associated data, or having to encrypt header
data just to authenticate it.
Comments?
DJ
David Johnston
Intel Corporation
Chair, IEEE 802 Handoff ECSG
Email : dj.johnston@intel.com
Tel : 503 380 5578 (Mobile)
Tel : 503 264 3855 (Office)