IEEE C802.16m-09/2955
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Text proposal on security context maintenance during zone switching (16.2.5)
Date
Submitted
2009-12-31
Source(s)
Xiangying Yang
Avishay Shraga
Chang Hong Shan
Muthaiah Venkatachalam
Intel
Re:
Call for LB #30b on “ P802.16m/D3”:
Target topic: “16.2.5”
Abstract
This contribution proposes text for security context maintenance during ZS preparation
Purpose
Adopt proposed text.
Notice
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.
Release
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.
Patent
Policy
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>.
E-mail: xiangying.yang@intel.com
Text proposal on security context maintenance during zone switching (16.2.5)
Xiangying Yang, Avishay Shraga, Chang Hong Shan, Muthaiah Venkatachalam
Intel
I.
Introduction
The text change propose to allow AMS to maintain two sets of valid security context in preparation for
zone switching, so that key agreement can be omitted during zone switching and thus service
interruption is minimized.
II.
Proposed Test
1
IEEE C802.16m-09/2955
Modify section 16.2.3.28 and section 16.2.5.1.5.6/7 as follows
--------------------------------text start----------------------------------------16.2.3.28 L2 Transfer message (AAI_L2_XFER)
The AAI provides a generic MAC control message called AAI_L2_XFER. This message acts as a generic service carrier
for various services including, but not limited to:
Device provisioning bootstrap message to AMS, GPS assistance delivery to AMS, ABS(es) geo-location unicast delivery to
AMS, 802.21 MIH transfer, messaging service, conveying WirelessMAN-OFDMA Advanced MAC control messages to
AMS in LZone etc.
This container is also used for 16m messages that are not processed by the BS, but are rather processed by network entities
beyond the BS. AAI_L2_XFER shall be transmitted only by authenticated AMSs.
The format of AAI_L2_XFER message is shown in Table 2
The enumeration of Tranfer-Type is as follows:
a)Transfer-Type = 1; GNSS assistance (DL)
b)Transfer-Type = 2; LBS measurement [Terrestrial meas. and GNSS pseudo ranges] (UL)
c)Transfer-Type = 3; Device Bootstrap (DL/UL)
d)Transfer-Type = 4; WirelessMAN-OFDMA network boundary indication (DL)
e)Transfer-Type = 5; ORAT-MSG (DL)
a)Sub-Type = 1: GERAN (GSM/GPRS/EGPRS)
b) Sub-Type = 2: UTRAN
c) Sub-Type = 3: E-UTRAN
d) Sub-Type = 4: TDSCDMA
e) Sub-Type = 5: CDMA2000
f)Transfer-Type = 6: SMS
a)Sub-Type = SMS data
b)Sub-Type = SMS confirmation
g)Transfer-Type = 7: MIH Frame
i)Sub-Type =1 : ES/CS MIH Capability Discovery
ii)Sub-Type =2 : Event Service
iii)Sub-Type = 3 : Command Service
iv)Sub-Type = 4 : Information Service
h)Transfer-Type = 8: WirelessMAN-OFDMA Advanced MAC control messages (only used in LZone)
ih)Transfer-Type = 89-127; reserved
ji)Transfer-Type = 128-255; Vendor specific types
Some of these messages have sub-types that are further defined in the type specific message payload. For example, for
Transfer-Type=1, the GNSS assistance may be for GPS, Galileo or other satellite systems, which would be specified as
sub-types of Transfer-Type=1.
16.2.5.2.1.5.6 Key update during zone switching from LZone to MZone
ABS shall include Nonce_BS in the zone switch information.
2
IEEE C802.16m-09/2955
AMS shall perform key agreement and network reentry procedure in MZone to derive new PMK, AK, CMAC keys and
TEKs to be used in MZone as follows.
•AMS derives new PMK, based on the NONCE_ABS and a NONCE_AMS.( key agreement MSG#1 is omitted since
the zone switching information containing the NONCE_ABS can be regarded as a key agreement challenging message.)
•On calculating AMSID*, AMS derives new AK and its CMAC key and TEK based on the new PMK.
•AMS sends AAI_RNG-REQ message containing key agreement MSG#2 attributes (e.g. NONCE_ABS,
NONCE_AMS and CMAC digest, which is based on the new CMAC key.)
•On receiving the AAI_RNG-REQ message, network entities derive new PMK, AK and CMAC keys. ABS validates
the AAI_RNG-REQ by CMAC tuple. If the CMAC is valid, ABS derives new TEKs and responds with AAI_RNGRSP message containing key agreement MSG#3 attributes (e.g. NONCE_ABS and NONCE_AMS) where the
AAI_RNG-RSP is transferred in encrypted manner by the new TEK.
•If the AMS decrypts and decodes successfully the AAI_RNG-RSP message, then the AMS regards it as completion of
a successful key agreement procedure.
AMS shall perform key agreement in LZone prior to zone switching command to derive new PMK, AK, CMAC keys and
TEKs to be used in MZone. The procedure is the same as defined in Figure 577, but carried on by using AAI_L2-Xfer
message in LZone. After successful key agreement in LZone, the AMS and ABS maintain a valid SAMZONE along with
security context that is ready to be use in MZone, in addition to the active SA LZONE currently being used in LZone. During
zone switch, AMS and ABS shall use this SAMZONE for the encryption and integrity protection of AAI_RNG-REQ and
AAI_RNG-RSP messages. After successful zone switch into MZone, SALZONE and associated context are discarded.
16.2.5.2.1.5.7 Key update during zone switch from MZone to LZone
Based on the current active PMKMZONEMZONE, new PMK to be used in Lzone is derived (e.g., PMKLZONE=
Dot16KDF(PMKMZONE,"PMK for LZONE") ), and CMAC_KEY_COUNT is set to 0.
New AK, KEK, CMAC keys are derived, based on PMKLZONE, according to Section 7.2.2.2. New TEKs are derived
according to Section 7.2.2.2 if in AAI_HO-CMD message HO process optimization bit #2 = 1 (Seamless handover).
Otherwise, prior to zone switch, TEKs to be used in LZone are obtained via TEK three-way handshake (as defined in
WirelessMAN-OFDMA specification) carried on by L2-Xfer message, in which TEK transfer is encrypted by KEK. If
Zone-Switching-Mode=1, the AMS shall also manage the old security context used to maintain communications in MZone
before zone switching to LZone finishes.
--------------------------------text end-----------------------------------------
3