Re: [STDS-802-16-MOBILE] Error in CMAC value calculation in 16e/D11?
And 403r1 gets the change marks correct.
DJ
-----Original Message-----
From: Johnston, Dj
Sent: Thursday, October 06, 2005 1:34 PM
To: 'Giesberts Pieter-Paul-apg035'; STDS-802-16-MOBILE@listserv.ieee.org
Subject: RE: [STDS-802-16-MOBILE] Error in CMAC value calculation in
16e/D11?
If people are minded to putting the below proposed fix into 16e,
document C80216e-05_403.pdf that I've just uploaded makes the change.
DJ
-----Original Message-----
From: Giesberts Pieter-Paul-apg035 [mailto:giesberts@MOTOROLA.COM]
Sent: Thursday, October 06, 2005 1:44 AM
To: STDS-802-16-MOBILE@listserv.ieee.org
Subject: [STDS-802-16-MOBILE] Error in CMAC value calculation in
16e/D11?
I have a question concerning Section 7.5.4.4.1 (page 245) of
P802.16e/D11:
This section specifies that the CMAC message digest shall be applied on
the following concatenated items:
* CMAC Key Sequence Number (4 bits)
* CMAC_PN (32 bits)
* CID (16 bits)
* Zero padding (16 bits)
* MAC_Management_Message excluding the CMAC Tuple TLV (multiple of 8
bits)
The text further states that the 16-bit padding is included for the
header to align with AES block size. However, the effect of the 16 bit
padding is that the MAC_Management_Message is prepended with 68 bits
before it is digested. When alignment is intended at 128 bits, as is
suggested by the reference to AES Block Size, the padding should be 76
bits.
In some earlier contributions there was talk of a 64-bit AK sequence
number (the same as the 64-bit AKID). It is possible that the intention
has been that the "key sequence number" in the CMAC pre-pended string is
a 64-bit value (e.g. the AKID). In that case the 16-bit padding makes
sense. But that is contradicted by the text: it explicitly states that
the Key Sequence Number is a 4-bit value.
When indeed the 4-bit CMAC key sequence number is intended, it is more
convenient to define this as an 8-bit value, filled with 4-bits 0
similar as in the CMAC Tuple definition (Section 11.1.2.2, page 527).
This avoids shift operations on the other fields in the pre-pended
string. In this case, the padding should be 72 bits.
Is my understanding correct and should padding be changed from 16 to 76
bits or, preferably, should the sequence number be prepended with 4 '0'
bits and the padding be changed from 16 to 72 bits?
Kind regards,
Pieter-Paul Giesberts