Re: [STDS-802-16] Error in CMAC value calculation in 16e/D11?

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

There is now a third version of 403 (C80216e-05/403r2) on the server.
I'll explain..

My inbox has been buzzing with discussion of 7.5.5.4.1.

Pieter first pointed out that the fields didn't align well and suggested
a solution that I wrote up in 403r1.

Others pointed out that the Key sequence number was meant to be the
AKID. I looked into this and looked at the old text (back when it was
D7). Looking at that I recognized the text as being something I'm pretty
sure I wrote. I didn't recognize this in D11 because various parts has
changed and my memory clearly doesn't work that well.

So the point of having the AKID in there is for it to be unique and bind
the CMAC value to the instance of the AK security context that was
created. Putting the 4 bit sequence number in there not only breaks the
alignment of the data, but breaks the point of the AKID. The key
sequence number is transmitted in the CMAC tuple, but the AK context
holds the mapping of the sequence number to the actual AKID, so the 64
bit AKID can be used in the computation, while the smaller 4 bit
sequence number is what is sent over the air in the management packets.

So I've prepared a version r2 of 403 that makes the change back to using
the AKID in the CMAC value calculation and puts in clarifying text
pointing to the AK context where the key sequence number, the AK and the
AKID are held.

This needs to be submitted today, but we have a week to discuss the
issue and r1 and r2 of 403 cover both cases, one with the alignment
fixed and one with the whole computation fixed, so the group resolution
could adopt one or the other. I believe that r2 is the correct option,
but I would appreciate confirmation from the other security people.

Thanks,
DJ

-- subnote.. Given that I assured my wife I'm taking a break from
standards for a while, I'm sure doing a bad job this week.
-- subsubnote.. I sent this to the mobile listserve earlier by mistake
and it didn't propagate as far as I can tell. If you get this twice,
don't be surprised.

-----Original Message-----
From: Johnston, Dj [mailto:dj.johnston@INTEL.COM]
Sent: Thursday, October 06, 2005 1:34 PM
To: 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