1. IEEE802.16e Security support for Group Management in M2M environment
Document Number:
IEEE S802.16p-10/0109
Date Submitted:
Source:
Inuk Jung, Kiseon Ryu, JinSam Kwak
LG Electronics
Re: Call for contributions for the IEEE p Amendment working document
Venue:
IEEE Session #73
Base Contribution: IEEE p-10/0018r1
Purpose:
To be discussed and adopted by TGp.
Notice:
This document does not represent the agreed views of the IEEE 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
Patent Policy:
The contributor is familiar with the IEEE-SA Patent Policy and Procedures:
< and <
Further information is located at < and < >.

2. Overview of 802.16e Multi-cast traffic
Problem Statement
In IEEE802.16e, there are several secure ways of providing multi-cast service to a group of devices.
MTK based multi-cast traffic encryption
MTK is generated based on MGTEK
MGTEK is distributed in unicast manner, which is overhead expensive for M2M environments
MBRA for MBS service
MBRA is a multi-cast key update method
Not applicable for devices in Idle mode. Overhead wise, the full GTEK is multi-cast for update purpose.
Unnecessary key encryption phase
MGTEK is already a key for multi-cast traffic, which is not used for encrypting multi-cast traffic but is used only to derive MTK. Unnecessary complexity.
Currently, the type of multi-cast service is mainly considered to be multi-media services. Thus, contents critical information for controlling groups of all M2M devices within a cell is not supported. In other words, multi-cast services is provided by a independent multi-cast server. This may not always be the case for M2M networks, where BS controls M2M devices in groups in terms of MAC procedures (e.g., network entry, grouping, scheduling (e.g., for ranging), etc).
Also, full security key information (i.e., GTEK) is distributed with each key update (i.e., 128bits), which can be reduced to under 10 bits.

3. Necessity of Multi-cast Security
A cell-based (i.e., BS) multi-cast security method has several benefits, over security support depending on a network server in upper network layers
Flexibility of security provision in network
BS takes care of multi-cast security updates and key distribution provided by the server
Alleviates the servers’ burden of managing all the M2M groups
Overhead reduction
Multi-cast key is updated in broadcast manner

4. Signaling Procedure for M2MGTEK derivation
M2MGTEK derivation procedure
MAK is generated by higher layer and distributed to BSs
BS unicast it to each MS within a multi-cast group the MAK and the M2MGTEK_COUNT, which is initially set to 0
This unicast message is encrypted with each MSs TEK for secure transmission
Each MS that received this message, locally derives the M2MGTEK
After M2MGTEK derivation, each MS acknowledges its derivation by a response-ACK message. This response-ACK message includes the derived M2MGTEK, M2MGTEK_COUNT and its multi-cast ID
The procedures above are performed for each MS that joins a multi-cast group

5. Objective Multi-cast security of IEEE802.16e may be partially reused
MBRA provides procedure for multi-cast based key update
MAK may be reused as the master key input for generating MGTEK for M2M
New multi-cast security parameters to be defined
M2M Multi-cast key
Parameters for local derivation of multi-cast key at MS side
Key update procedure
The update procedure and key provisioning procedure can be reused with some modification to the existing MBRA method
Considering Idle mode devices
Indication of key distribution or update through AAI-PAG-ADV message
Overhead enhancement
Local key update through change count values

6. Key derivation function
MTK is used for MBS data traffic encryption. MGTEK is not used for encryption, hence one of them is unnecessary. Instead of generating MTK, MGTEK is sufficient for MBS traffic encryption.
MGTEK is already defined and randomly generated by BS. Therefore we need to define a new Group TEK for M2M devices, which shall be derived by a Key Derivation Function (KDF)  we may call it “M2MGTEK”
The GTEK for M2M multi-cast service is derived as follows:
M2MGTEK = Dot16KDF(MAK, M2MGTEK_COUNT, Multicast CID | “M2MGTEK”, 128)
Here, the MAK is generated by network side, which is outside the scope of IEEE standard
Here, the M2MGTEK_COUNT indicates the version of the currently used M2MGTEK, which the devices should apply to derive the M2MGTEK. The update of the M2MGTEK depends on the M2MGTEK_COUNT
Here, Multi-cast ID is the M2M Group ID

7. Generated from higher layer
Key Hierarchy
Generated from higher layer
Update seeds
for GTEK

8. Signaling Procedure for M2MGTEK update method
For Active state devices:
Upon the expiration of M2MGTEK or MAK lifetime or exhaustion of PN space, the network or BS initiates the M2MGTEK update procedure
BS increments the current M2MGTEK_COUNT by one. The BS multi-casts the multi-cast security update command, which includes the following parameters
M2MGTEK_COUNT – which is the incremented version of the current M2MGTEK_COUNT
Also the current M2MGTEK_COUNT may be included in periodically broadcasted messages, such as
MOB_NBR-ADV
PKM-RSP message with different PKM codes and attributes
Etc…

9. Signaling Procedure for M2MGTEK update method
For Idle state devices:
The device group associated with the multi-cast ID will expect to receive a multi-cast traffic at the Multi-cast Security Update Time (MSUT).
The BS will multi-cast a multi-cast security update message at the MSUT time, encrypted with the current M2MGTEK, which includes the following parameters
M2MGTEK_COUNT – seed for updating the M2MGTEK, which is the incremented M2MGTEK_COUNT value of the current version
Devices that received the multi-cast security update message will derive the new M2MGTEK via the M2MGTEK_COUNT value, MAK and multi-cast ID
The appliance instance, or time, of the update M2MGTEK may be defined as a predefined time during capability negotiation. Otherwise, the BS shall explicitly indicate the time in the some broadcast message (e.g., MOB_NBR-ADV, MOB_PAG-ADV)

10. Signaling Procedure for M2MGTEK update method
For Idle state devices (continued):
Upon the expiration of M2MGTEK or MAK lifetime or exhaustion of PN space, the network or BS initiates the M2MGTEK update procedure
BS increments the current M2MGTEK_COUNT by one. The BS sets the ‘Action Code’ in the MOB_PAG-ADV message to 0b11 and transmits it to the devices
Action Code 0b11: Receiving multi-cast traffic
Action Code 0b11 implies that multi-cast traffic is scheduled at the ‘N’th frame from the frame where MOB_PAG-ADV is received.
The ‘N’th frame is informed by the ‘Multi-cast traffic start time (MTST)’, which is included in the MOB_PAG-ADV only when Action Code is set to 0b11
The multi-cast ID (MCID) shall also be included, indicating that only devices that are party of the multi-cast ID shall receive the scheduled multi-cast traffic
Also within the MOB_PAG-ADV, if Action code is set to 0b11, the 1bit ‘Multi-cast security key update’ parameter is included, which indicate whether the purpose of the scheduled multi-cast traffic is for updating the M2MGTEK
If it is set to ‘1’ (i.e., TRUE), then the M2MGTEK_COUNT and update_time is included
Where the M2MGTEK_COUNT serves as the seed for updating the M2MGTEK at the MS side
Where update_time implies the appliance of the updated M2MGTEK