IEEE C802.16maint-07/046r1
Project
Title
IEEE 802.16 Broadband Wireless Access Working Group < http://ieee802.org/16 >
Clarification and detailed description of the use of CMAC_KEY_COUNT
Date
Submitted
2007-10-29
Source(s) Erik Colban
Navid Ehsan
Yair Borlas
Re:
Wee Peng Goh
NextWave Broadband Inc.*
Voice: [Telephone Number (optional)]]
E-mail: ecolban@nextwave.com
nehsan@nextwave.com
ybourlas@nextwave.com
wgoh@nextwave.com
*< http://standards.ieee.org/faqs/affiliationFAQ.html
>
IEEE Working Group 802.16 Letter Ballot #26 as announced in IEEE 802.16-07/049
Abstract
Purpose
Notice
Release
Patent
Policy
The specification of CMAC_KEY_COUNT is not sufficiently detailed to ensure interoperability and the desired level of security. This contribution proposes amendments to 802.16 Rev2/D1 that address this problem.
Adopt the proposed changes in 802.16 Rev2.
This document does not represent the agreed views of the IEEE 802.16 Working Group or any of its subgroups . It represents only the views of the participants listed in the “Source(s)” field above. It is offered as a basis for discussion. It is not binding on the contributor(s), who reserve(s) the right to add, amend or withdraw material contained herein.
The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.16.
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
< http://standards.ieee.org/guides/bylaws/sect6-7.html#6 > and
< http://standards.ieee.org/guides/opman/sect6.html#6.3
>.
Further information is located at < http://standards.ieee.org/board/pat/pat-material.html
> and
< http://standards.ieee.org/board/pat >.
Erik Colban and Navid Ehsan
NextWave Broadband Inc.
In defining the CMAC_KEY_COUNT variable, the following is not clear:
- When the RNG-REQ is sent with an updated CMAC_KEY_ COUNT, is the CMAC value of the RNG-
REQ calculated using the “new” CMAC_KEY_* or the “old” CMAC_KEY_*? Different implementation of this will result in interoperability issues.
1

-
IEEE C802.16maint-07/046r1
When should the MS increase the CMAC_KEY_COUNT; after successful ranging (by sending a new
RNG-REQ) or before starting handover ranging/reentry?
- If the handover ranging (or any other part of handover entry) is unsuccessful, can the MS decrease the
CMAC_KEY_COUNT to the value it used with the source base station?
- Can the MS increase the CMAC_KEY_COUNT if PN reaches 0xFFFFFFFF?
Furthermore, procedural specifications do not belong to the sections that describe the message formats. In subsections of 6.3.2.3, a parameter needs only be described briefly and should specify restrictions on the value of the parameter when used in the particular message if such restrictions apply. The description should reference the sections specifying the procedures related to the particular parameter or to the TLV subsection of section 11.
It should be explicitly mentioned that while the MS is in CMAC_KEY_Lock state, all RNG_REQ messages shall be sent with the “new” CMAC_KEY_U and all messages on the DL will be checked with the “new”
CMAC_KEY_D.
In order to clarify when the CMAC_KEY_COUNT is incremented, we propose adding the text “MS increments the CMAC_KEY_COUNT and then enters its CMAC_Key_Lock state”.
Add the text “after the RNG-RSP is received” to specify when the MS is considered to be “connected to the target BS” and shall exit the CMAC_Key_Lock state.
Add the text that to say that if the MS cancels a handover it resumes communication with the serving BS using the “old” CMAC_KEY_* but shall keep the “new” CMAC_KEY_COUNT. The BS shall not recalculate the
CMAC_KEY_* unless it receives a RNG_REQ from the MS that contains a CMAC_KEY_COUNT.
The BS has no way of notifying the MS that the CMAC_KEY_COUNT is increased. Therefore, it should be explicitly mentioned that “BS shall not increment this counter unless it receives an update in the RNG-REQ from MS.”
The standard does not currently prohibit the MS from incrementing the CMAC_KEY_COUNT when
CMAC_PN_* overflows. Therefore, an MS can potentially increment the CMAC_KEY_COUNT instead of requesting new AK, and notify the BS by sending a RNG-REQ with the new CMAC_KEY_COUNT. It is not clear whether BS should support such cases or not. Therefore we propose adding the text “MS and BS shall
NOT increment this counter to compensate for the overflow of CMAC_PN_*.”
2

IEEE C802.16maint-07/046r1
Page 92, line 46: Modify section as follows:
The following TLV shall be included whenever the CMAC Tuple is included in the RNG-REQ message during the entry, re-entry, secure Location Update, or handover.
CMAC_KEY_COUNT
This field contains the MS’s current value of the CMAC_KEY_COUNT, which is used to generate the
CMAC_KEY_U used to generate the CMAC Tuple included in this message. See 7.2.2.2.9.
Page 525, line 38: Modify section as follows:
7.2.2.2.9 Message authentication keys (HMAC/CMAC) and KEK derivation
Message authentication code keys are used to sign management messages in order to validate the authenticity of these messages. The message authentication code to be used is negotiated at SS Basic
Capabilities negotiation.
There is a different key for UL and DL messages. Also, a different message authentication key is generated for a broadcast message (this is DL direction only) and for a unicast message.
In general, the message authentication keys used to generate the CMAC value and the HMAC-Digest are derived from the AK.
An alternative method of CMAC key generation, namely CMAC-0, may be used in the limited mobility environments as described in Annex I.
The keys used for CMAC key and for KEK are as follows:
CMAC_PREKEY_U | CMAC_PREKEY_D | KEK ⇐ Dot16KDF(AK, SS MAC Address | BSID |
“CMAC_KEYS+KEK”, 384)
CMAC_KEY_GD ⇐ Dot16KDF(GKEK, “GROUP CMAC KEY”,128) (Used for broadcast MAC message such as a PKMv2 Group-Key-Update-Command message)
CMAC_KEY_U ⇐ AES
CMAC_PREKEY_U
(CMAC_KEY_COUNT)
CMAC_KEY_D ⇐ AES
CMAC_PREKEY_D
(CMAC_KEY_COUNT)
The MS and the network shall each maintain a CMAC_KEY_COUNT counter, which are normally kept synchronized. The synchronization of the value of this counter among BSs within the network is outside the scope of this standard. The value of this counter shall be reset to zero by both the MS and the network upon successful completion of authentication or re-authentication, and shall be incremented for each MS access to a BS. Before the MS either re-enters the network, hands over to a target BS, or performs a secure
Location Update, the MS shall increment the CMAC_KEY_COUNT, re-compute new values of
CMAC_KEY_* based on the updated CMAC_KEY_COUNT, reset CMAC_PN_* to zero, and then enter its CMAC_Key_Lock state as part of this process. Before handover, the MS shall additionally cache the current values of CMAC_KEY_* and CMAC_PN_* used at the serving BS. While in this state, the MS
3

IEEE C802.16maint-07/046r1 shall not update the value of its CMAC_KEY_COUNT counter. Any RNG-REQ message sent while in the
CMAC_Key_Lock state, whether to the same or other potential target BS, shall include the
CMAC_KEY_COUNT. When the MS either receives a RNG-RSP message from the target BS or cancels handover and remains connected to its current serving BS, it exits the CMAC_Key_Lock state. If the MS cancels the handover, the MS shall resume communication with the serving BS without generating new
CMAC_KEY_* values and without resetting the CMAC_PN_* values to zero, but continue with the values that were last used in communication with the serving BS. The MS shall keep the updated
CMAC_KEY_COUNT to be incremented again at the next occurrence of a network re-entry, handover or secure Location Update, but may purge the CMAC_KEY_* associated with that CMAC_KEY_COUNT value and the CMAC_PN_* values used at other BSs. When the MS completes handover or when the
Resource Retain timer expires, the MS may purge the cached values of CMAC_KEY_* and CMAC_PN_* used at the serving BS.
If the target BS receives and authenticates an RNG-REQ message containing a CMAC_KEY_COUNT value higher than the network’s value of this counter, the value of the CMAC_KEY_COUNT in the network shall be set to that of the MS. Otherwise, the network shall increment this counter if and only if it can determine that the MS has entered and exited the CMAC_Key_Lock state. A BS shall recomputed new values of CMAC_KEY_* only after receiving a RNG_REQ that contains a CMAC_KEY_COUNT TLV.
The MS and BS shall not increment this counter to compensate for the overflow of CMAC_PN_*.
The preprocessed value of CMAC_PREKEY_* is treated as the Cipher Key of the Advanced Encryption
Standard (AES) algorithm AES128 (FIPS197). The CMAC_KEY_COUNT is treated as the Input Block
Plain Text of this algorithm. The AES128 algorithm is executed once. The Output Block Cipher Text of this algorithm is treated as the resulting CMAC_KEY_*. When CMAC_KEY_COUNT is used as an input of
AES128 algorithm, 112 zero bits are prepadded before the 16-bit CMAC_KEY_COUNT where the
CMAC_KEY_COUNT is regarded as most-significant-bit first order. The AES input is also defined as most-significant-bit first order. The keys used for HMAC key and for KEK are as follows: HMAC_KEY_U
| HMAC_KEY_D | KEK ⇐ Dot16KDF(AK, SS MAC Address | BSID | “HMAC_KEYS+KEK”, 448)
HMAC_KEY_GD ⇐ Dot16KDF(GKEK, “GROUP HMAC KEY”, 160) (Used for broadcast MAC message such as a PKMv2 Group-Key-Update-Command message) Exceptionally, the message authentication keys for the HMAC/CMAC Digest included in a PKMv2 Authenticated-EAP-Transfer message are derived from the EIK instead of the AK The keys used for CMAC key and for KEK are as follows: CMAC_KEY_U | CMAC_KEY_D ⇐ Dot16KDF(EIK, SS MAC Address | BSID |
“CMAC_KEYS”, 256) The keys used for HMAC key and for KEK are as follows: HMAC_KEY_U |
HMAC_KEY_D ⇐ Dot16KDF(EIK, SS MAC Address | BSID | “HMAC_KEYS”, 320)
4