Re: [STDS-802-16-MOBILE] Question regarding CMAC key derivation (7.5.4.6.1)

["Johnston, Dj" <dj.johnston@INTEL.COM>]

I've got a new revision 402r2 that addresses the 2nd and 3rd comments.
I'll upload it later once I'm sure it's ok.

The conventional method for dismbiguating bit representation and
endianess is to supply example vectors. This hasn't been done for CMAC
as far as I know. The corrigendum has them for CCM.

If there is no controversy over the details of the CMAC calculation, I
think these vectors can probably be published informally rather than
making a dramatic change to the spec at this stage. This has been done
in other 802 specifications. It usually takes a few weeks to get
together three independent implementations of vector generator code that
match so this doesn't fit with out draft publication schedules.

DJ


-----Original Message-----
From: Giesberts Pieter-Paul-apg035 [mailto:giesberts@MOTOROLA.COM] 
Sent: Monday, October 10, 2005 3:14 AM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: [STDS-802-16-MOBILE] Question regarding CMAC key derivation
(7.5.4.6.1)

Section 7.5.4.6.1 describes the Dot16KDF key derivation algorithms for
CMAC and HMAC.

The target string parameter of the CMAC calculation has the form "i |
astring | keylength", which asks for a concatenation of an integer (i),
a bitstring (astring) and another integer (keylength). This can only be
done in an unambiguous manner if there are agreements on the bit
representation of integers, which is currently lacking from the
algorithm specification. Given the keylengths used in the instances of
this algorithm in the standard it should be at least 16 bits, presumably
unsigned. And then there is endian-ness. Can someone clarify how these
numbers should be represented?
 
I also have two additional comments concerning this section: 
* The pseudo-code to specify the algorithm uses the same symbol <= to
mean "smaller than or equal to" in the line with the "for statement" and
to mean "is changed into" or  "becomes" in the next line. Though I think
most readers are likely to understand what is intended it may be
somewhat confusing.
* The operation Truncate(CMAC(xxx),128) seems meaningless if a CMAC is
always a 128-bit string. If it is not necessary, it might as well be
removed.