Security Supporting Multicast in IEEE 802.16N

IEEE C802.16n-11/0048

Security Supporting Multicast in IEEE 802.16n

Eunkyung Kim, Sungcheol Chang, Sungkyung Kim, Hyun Lee, Chulsik Yoon

ETRI

Introductions

HR-Network shall provide optimized MAC protocols for unicast and multicast transmission. In addition, section 6.2.1 in SRD (i.e., IEEE 802.16n-10/0048[1]) of IEEE 802.16n describes some requirements related to service provided on HR-Network to support unicast and multicast communication.

This document provides the detail description of security operation for multicast operationmeeting the requirements [1][4]in IEEE 802.16n for the 802.16n Amendment Draft Standard focusing on the multicast key management

Key management in WirelessMAN-OFDMA AAI

WirelessMAN-OFDMA Advanced System uses the PKM protocol to achieve:

• Transparent exchange of authentication and authorization messages

• Key agreement

• Security material exchange

PKM protocol provides mutual authentication and establishes shared secret between AMS and ABS. The shared secret is then used to exchange or drive other keying material. This two-tiered mechanism allows the frequent traffic key refreshing without incurring the overhead of computation intensive operations.

Figure 1 and Figure 2 show the process to calculate the AK yielding an MSK and the unicast key hierarchy starting from AK based on PMKv3, respectively.

As shown Figure 1 and Figure 2, all PKMv3 keys (excluding MSK) are derived directly/indirectly from the MSK.

Figure 1– AK from PMK (Pairwise Master Key (PMK) is derived from the MSK and this PMK is used to derive the Authorization Key (AK).)

Figure 2– CMAC key and TEK derivation from AK (AK is used to derive Traffic Encryption Key (TEK) and Cipher-based Message Authentication Code (CMAC) key.)

Multicast Key Management in IEEE 802.16n

Similar to unicast key management, multicast traffic can be encrypted using multicast specific key management based on PMKv3 as described in Figure 3. As shown Figure 3, Multicast CMAC (MCMAC) key and Multicast TEK (MTEK) are derived from Multicast AK (MAK). MAK is a shared key among an HR-BS and a group of HR-MSs in an HR multicast group and the MAK is encrypted and transmitted to each HR-MS using unicast security key.

Figure 3– MCMAC Key and MTEK derivation from MAK

Multicast Security Association (MSA)

In addition to sharing between ABS and AMS for unicast, some shared security association (i.e., Multicast Security Association; MSA) is proposed. MSA is an SA for the multicast transport/control flow and it provides keying material. Security key related to parameter to support multicast and the context is secured till the key expires.

References

[1]IEEE 802.16n-10/0048, “802.16n System Requirements Document including SARM annex,” January 2011.

[2]IEEE Std. 802.16-2009, “IEEE Standard for Local and metropolitan area networks; Part 16: Air Interface for Broadband Wireless Access Systems,” May 2009.

[3]IEEE 802.16m-09/0034r3, “IEEE 802.16m System Description Document (SDD),” June 2010.

[4]IEEE C802.16gman-10/0014, “Group Calls and Multicast Operation for Public Safety and Public Protection,” May 2010.

Proposed Textfor the 802.16nAmendment WorkingDocument (AWD)

Note:

The text in BLACK color: the existing text in the 802.16nAmendment Draft Standard

The text in RED color: the removal of existing 802.16nAmendment Draft Standard Text

The text in BLUE color: the new text added to the 802.16nAmendment Draft Standard Text

[------Start of Text Proposal------]

[Remedy1: Adapt the followingchange in Section 16.2.5.2.2 Security in the 802.16n AWD]

[Change section 16.2.5.2.2 as indicated:]

16.2.5.2.2 SA Management

A security association (SA) is the set of information required for secure communication between ABS and AMS. SA is shared between ABS and its client AMS across the AAI network. SA is identified using an SA identifier (SAID). The SA is applied to the respective unicast flows. AAI supports unicast static SA only and SAs are mapped one-by-one to cryptographic methods. (see Table 758)

SA is used to provide keying material for unicast transport/control flows. Once an SA is mapped to an unicast transport flow, the SA is applied to all the data exchanged within the unicast transport flow. Multiple flows may be mapped to the same SA. The indication to the receiver that the MAC PDU is encrypted or not is indicated by the FID 0x1 and 0x0 in AGMH respectively for unicast control flows, and indicated by SA which is associated to FID in AGMH and SPMH for unicast transport flows.

The Flow ID in the AGMH is used to indicate whether the PDU contains control message encrypted based on security level. Whether each control message is encrypted or not is decided based on the security level which the message is associated with (see Table 677).

If authorization is performed successfully, SAID 0x01 is applied to flows for confidentiality and integrity, and SAID 0x02 for confidentiality only. In addition, for high reliable multicast service, SAID 0x03 is applied to flows for confidentiality and integrity.SAID 0x01 shall be applied to control flows as defined in Table 674. However, SAID 0x02 can be applied to transport flows only If the AMS and ABS decide to create an unprotected transport flow, the Null SAID(i.e., SAID 0x00) is used as the target SAID. SAID 0x03 can be applied to high reliable multicast transport flow(See Table 758).

Table 758 – SA mapping with protection level

Using PKM protocol, AMS shares the SAsí’ keying material with ABS. An SA contains keying material that

is used to protect unicast flows (see SA context in 16.2.5.4.4).

16.2.5.2.2.1 Mapping of flows to SAs

The following rules for mapping flows to SAs apply:

a) The unicast transport flows shall be mapped to an SA.

b) The multicast or broadcast transport flows shall be mapped to Null SA.

c) The encrypted unicast control flows shall be mapped to the Primary SA.

d) The non-encrypted unicast control flows shall not be mapped to any SA.

e) The broadcast control flows shall not be mapped to any SA.

f) The high reliable multicast transport flows shall be mapped to any multicast SA.

The actual mapping is achieved by including the SAID of an SA in the DSA-xxx messages together with theFID.

Control messages which the Primary SA is applied to are predetermined according to the control messageprotection level depending on each control message type and its usage. Even if non-encrypted unicast controlflows shall not be mapped to any SA, CMAC-based integrity protection can be applied per control messageaccording the control message protection level (see 16.2.5.3.3).

[Remedy2: Add the following text into Section 17.3.10 Security in the 802.16n AWD]

17.3.9.3 Multicast key management

HR-Network shall support multicast key management as described in 17.3.10.x.

[Remedy3: Add the following text into Section 17.3.10 Security in the 802.16n AWD]

17.3.10 Security

HR-Network shall support not degrade the security performance achieved with WirelessMAN-AAI in hierarchical network topology as described in 16.2.5.

HR-Network also shall support secure communication and session establishment among HR-stations, and between HR-stations and external AAA-servers.

17.3.10.x Security for multicast communication

PKMv3 as described in 16.2.5.2 provides HR-stations with strong protection from theft of service by encrypting connections between HR-MSs and HR-BSs.

PKMv3 also shall provide HR-stations with strong protection from theft of service by encrypting multicast connections between HR-MSs and HR-BSs, as defined in this subsection.

If a DL multicast connection is to be encrypted, each HR-MS participating in the connection shall have an additional security association (SA) (i.e., multicast SA), allowing that connection to be encrypted using keys that are independent of those used for other encrypted transmissions between HR-MSs and the HR-BS.

Similar to unicast key management, multicast traffic can be encrypted using multicast specific key management based on PMKv3 as described in Figure aaa. Multicast CMAC (MCMAC) key and Multicast TEK (MTEK) are derived from Multicast AK (MAK). MAK is a shared key among an HR-BS and a group of HR-MSs in an HR multicast group and the MAK is encrypted and transmitted to each HR-MS using unicast security key.

Figure aaa– MCMAC Key and MTEK derivation from MAK

Shared security association (i.e., Multicast Security Association; MSA) is an SA for the multicast transport/control flow and it provides keying material. Security key related to parameter to support multicast and the context is secured till the key expires.

17.3.10.x.1Security context for multicast communication

The multicast security context is a set of parameters linked to a key in each hierarchy that defines the scope while thekey usage is considered to be secure.

Examples of these parameters are key lifetime and counters ensuring the same encryption will not be usedmore than once. When the context of the key expires, a new key should be obtained to continue working.The purpose of this sub clause is to define the context that belongs to each key, how it is obtained and thescope of its usage.

17.3.10.x.1.1 MAK context

The MAK context includes all parameters associated with the MAK. This context is created whenever a new MAK is derived.

This context shall be deleted whenever the MAK is no longer valid or used.

The MAK context is described in Table bbb.

Table bbb – The MAK context

17.3.10.x.1.2 MSA context

The MSA context is the set of parameters managed by each MSA in order to ensure MTEK management and usagein secure way.

The MSA context holds MTEK context and additional information that belongs to the MSA itself.

17.3.10.x.1.2 MTEK context

The MTEK context includes all relevant parameters of a single MTEK and is described in Table ccc.

Table ccc – The MTEK context

17.3.10.x.1.3 MSA context

The MSA context is described in Table ddd.

Table ddd – The MSA context

[------End of Text Proposal------]

1