Multicast Key Management for IEEE 802.16n HR-Network

Document Number:IEEE C802.16n-10/0012r1

Date Submitted:2011-03-06

Source:Joseph Chee Ming Teo, Jaya Shankar, Yeow Wai Leong, Hoang Anh Tuan, E-mail: cmteo@i2r.a-star.edu.sgZheng Shoukang, Mar Choon Hock Institute for Infocomm Research1 Fusionopolis Way, #21-01, Connexis (South Tower)Singapore 138632 *<http://standards.ieee.org/faqs/affiliationFAQ.html>

Re:Call for contributions for 802.16n AWD

Base Contribution:N/A

Purpose:To be discussed and adopted by TG802.16n

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.

Copyright Policy:The contributor is familiar with the IEEE-SA Copyright Policy <http://standards.ieee.org/IPR/copyrightpolicy.html>.

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 >.

Introduction 802.16n SRD specifies requirement for Enhancements to

Unicast and Multicast communication (Section 6.2.1) HR-Network shall provide optimized MAC protocols for unicast and

multicast transmission to support applications of two-way communications such as Push to Talk (PTT) service among a group of HR-MS.

Examples of applications to be used in PTT service include: audio (e.g., speech, music) video still image text (formatted and non-formatted) file transfer

Use case scenario Public Protection and Disaster Relief (PPDR)

Different Groups of Rescue teams (e.g. firemen and police officers) would have to communicate with each other without/without backbone networks

Need for a common multicast key to encrypt/decrypt messages to prevent eavesdroppers or impersonation of legitimate multicast group members.

Introduction Multicast Key Management

Existing 802.16-2009 – Multicast & Broadcast Rekeying Algorithm (MBRA) Research papers highlighted that MBRA does not provide forward secrecy

and backward secrecy Forward secrecy – leaving users still able to decrypt secure multicast

messages after leaving the group Backward secrecy – joining users can decrypt secure multicast messages

sent before joining the group The 802.16n SRD specifies

Section 6.1.4.2 Multicast key Management HR-Network shall provide the security architecture that provides a

group of HR-MSs with authentication, authorization, encryption and integrity protection.

HR-Network shall provide multicast key management for the group of HR-MSs. The key shared within the group should be distributed securely and efficiently. HR-Network should support the group signaling procedure using multicast transmission for multicast key management efficiently.

Introduction Hence there is a need for enhanced multicast key

management compared to MBRA. Multicast Key Management should address the forward and

backward secrecy issue. Solution has to cover the various scenarios for secure

multicast communication without/without infrastructure

Use Case Scenarios Initial Group Formation

HR-MSX/BS

HR-MS1

HR-MSn

HR-MS2

HR-MS3HR-MS4

Controller node can be either HR-BS or an appointed HR-MS (Denoted as HR-MSX if HR-BS is not present)

Use Case Scenarios Join Event

HR-MSX/BS

HR-MS1

HR-MSj

HR-MS2

HR-MS3HR-MS4

Join

Currently not addressed by MBRA

Use Case Scenarios Leave Event Currently not

addressed by MBRA

HR-MSX/BS

HR-MS1

HR-MSl

HR-MS2

HR-MS3HR-MS4

Leave

We proposed procedures for Initial Group Formation Join Event Leave Event

Solution has to cover the various scenarios for secure multicast communication without/without infrastructure, i.e. solution has to be designed for

Infrastructureless – PKI based Infrastructure – Pre-shared key based

The “controller” can be either HR-BS (if present) or an appointed HR-MS (denoted HR-MSX) for PKI approach.

Details of Contribution

Assumes that there is network infrastructure, i.e. each multicast member (HR-MSi) shares a unicast security key MSKi with the HR-BS.

Initial Group Formation Procedure used to establish the Multicast key GTEK.

Join and Leave Procedures used to update the GTEK to achieve backward and forward secrecy.

Pre-shared key-based approach

Flow Diagram

Initial Group Formation Procedure – Pre-shared key-based approach

HR-MSX/BS HR-MSi

MulticastGrpInfo

Multicast_MSG_#1Multicast_MSG_#1

Multicast_MSG_#2

Flow Chart

Initial Group Formation Procedure – Pre-shared key approach

Initial Group Formation Procedure – Pre-shared key-based approach

Step 1: HR-BS sends the multicast group information message (MulticastGrpInfo message) to all potential members of the multicast group comprising of HR-MSi for 1 ≤ i ≤ n, where MulticastGrpInfo = MulticastGrpID|HR-BSAddr.

Step 2: Each HR-MSi for 1 ≤ i ≤ n first generates nonce NHR-MSi. Next, HR-MSi computes the MAC θHR-MSi = MAC(MSKi|MulticastGrpID|THR-MSi|NHR-MSi|HR-BSAddr|HR-MSiAddr) and sends Multicast_MSG_#1 message to HR-BS, where Multicast_MSG_#1 = MulticastGrpID|THR-MSi|NHR-MSi|HR-BSAddr|HR-MSiAddr|θHR-MSi.

Step 3: HR-BS first verifies the received timestamps and nonces for freshness and θHR-MSi for 1 ≤ i ≤ n. If the verifications are correct, then HR-BS generates nonce NHR-BS, GTEK and computes θHR-MSi' = MAC(MSKi|GTEK|NHR-BS|NHR-MSi|HR-BSAddr|HR-MSiAddr). HR-BS then encrypt and obtain ci = EMSKi(GTEK, GTEK_lifetime, HR-MSiAddr, HR-BSAddr). Finally, HR-BS sends Multicast_MSG_#2 message to HR-MSi for 1 ≤ i ≤ n, where Multicast_MSG_#2 = MulticastGrpID|THR-BS|NHR-BS|HR-MSiAddr|HR-BSAddr| NHR-MSi|ci|θHR-MSi'.

Step 4: Each HR-MSi for 1 ≤ i ≤ n first verifies the received timestamp and nonces for freshness and decrypts ci using MSKi and obtains GTEK and GTEK_lifetime. Next, each HR-MSi verifies θHR-MSi'. If the verification is correct, then HR-MSi can commence secure multicast.

Flow Diagram

Join Procedure – Pre-shared key based approach

Flow Chart

Join Procedure – Pre-shared key-based approach

Join Procedure – Pre-shared key-based approach

Step 1: New mobile station HR-MSj first generates nonce NHR-MSj. Next, HR-MSj computes the MAC θHR-

MSj = MAC(MSKj|MulticastGrpID|THR-MSj|NHR-MSj|HR-BSAddr|HR-MSjAddr) and sends Join_MG_MSG_#1 message to HR-BS, where Join_MG_MSG_#1 = MulticastGrpID| THR-MSj|NHR-MSj|HR-BSAddr| HR-MSjAddr|θHR-MSj.

Step 2: HR-BS first verifies the received timestamps and nonces for freshness and θHR-MSj. If the verifications are correct, then HR-BS generates nonce NHR-BS', GTEK' and computes θHR-BS = MAC(GTEK'|NHR-BS'|HR-BSAddr|MulticastGrpID) and θHR-MSj' =MAC(MSKj|GTEK'|NHR-BS'|NHR-MSj|HR-BSAddr|HR-MSjAddr). HR-BS then encrypt and obtain cj = EMSKj(GTEK', GTEK'_lifetime, HR-MSjAddr, HR-BSAddr). HR-BS also encrypts using the existing GTEK and obtains c' = EGTEK(GTEK', GTEK'_lifetime, HR-BSAddr, NHR-BS') Finally, HR-BS sends Multicast_Join_MSG_#2 message to HR-MSi for 1 ≤ i ≤ n and Multicast_Join_MSG_#3 message to HR-MSj respectively, where Multicast_Join_MSG_#2 = MulticastGrpID|THR-BS'|NHR-BS'|HR-BSAddr| c'|θHR-BS and Multicast_Join_MSG_#3 = MulticastGrpID|THR-

BS'|NHR-BS'|HR-MSjAddr|HR-BSAddr|NHR-MSj|cj| θHR-MSj'.

Step 3a: Each HR-MSi for 1 ≤ i ≤ n first verifies the received timestamp and nonce for freshness. If the verifications are correct, then each HR-MSi decrypts c' and obtains the new GTEK', and GTEK'_lifetime. Next, each HR-MSi verifies θHR-BS. If the verification is correct, then HR-MSi can commence secure multicast.

Step 3b: HR-MSj first verifies the received timestamp and nonces for freshness. If the verifications are correct, then HR-MSj uses MSKj to decrypt c_j and obtains GTEK' and GTEK'_lifetime. Next, HR-MSj verifies θHR-MSj'. If the verification is correct, then HR-MSj can commence secure multicast.

Flow Diagram

Leave Procedure – Pre-shared key-based approach

Flow Chart

Leave Procedure – Pre-shared key-based approach

Leave Protocol – Pre-shared key-based approach

Step 1: HR-BS generates nonce NHR-BS', new group key GTEK' and computes θHR-MSi' = MAC(MSKi|GTEK'|NHR-BS'|HR-BSAddr|HR-MSiAddr|MulticastGrpID) for 1 ≤ i != l ≤ n. HR-BS then uses the shared key MSKi with the remaining HR-MSi for 1 ≤ i != L ≤ n to encrypt and obtain ci' = EMSKi(GTEK',GTEK'_lifetime, HR-BSAddr, NHR-BS'). Finally, HR-BS sends Multicast_Leave_MSG_#1 messages to remaining HR-MSi for 1 ≤ i != L ≤ n, where Multicast_Leave_MSG_#1 = MulticastGrpID|THR-

BS'|NHR-BS'|HR-BSAddr|ci'|θHR-MSi'.

Step 2: Each remaining HR-MSi for 1 ≤ i != L ≤ n first verifies the received timestamp and nonce for freshness. If the verifications are correct, then each remaining HR-MSi uses its shared key MSKi to decrypt ci ' and obtains the new GTEK' and GTEK'_lifetime. Next, each remaining HR-MSi verifies θHR-MSi'. If the verification is correct, then each remaining HR-MSi can commence secure multicast.

Uses the X.509 Certificates (defined in Standards 802.16-2009)

Initial Group Formation Procedure used to establish the unicast security key MSKi (with each HR-MSi (multicast member) AND Multicast key GTEK.

Join and Leave Procedures used to update the GTEK to achieve backward and forward secrecy. Also establish unicast security key MSKj with new joining nodes.

PKI-based approach

Flow Diagram

Initial Group Formation Procedure – PKI-based approach

HR-MSX/BS HR-MSi

MulticastGrpInfo

Multicast_MSG_#1Multicast_MSG_#1

Multicast_MSG_#2

Flow Chart

Initial Group Formation Procedure – PKI-based approach

HR-MSX/BS sends the multicast group information MulticastGrpInfo to all potential members of the multicast group comprising

of HR-MSi for 1 <= i <= n

Each HR-MSi generates nonce, computes the signature and sends

Multicast_MSG_#1 to HR-MSX/BS.

HR-MSX/BS verifies the received timestamps, nonce, messages and MACs. If the verifications are correct, HR-MSX/BS generates its nonce,

the GTEK and MSKi for 1 <= i <= n and computes the MAC. HR-MSX/BS then encrypts

the secret keys using each HR-MSi’s public key, computes the signatures for each message

and sends Multicast_MSG_#2 to each HR-MSi.

Each HR-MSi verifies the received timestamp, nonces and signature. If the

verification is correct, each HR-MSi decrypts and obtains MSKi, GTEK and their lifetimes.

Each HR-MSi then verifies the MAC and commence secure multicast if the

verification is correct.

Initial Group Formation Procedure – PKI-based approachStep 1: HR-MSX/BS sends the MulticastGrpInfo message to all potential members of the multicast group comprising of HR-MSi for 1 ≤ i ≤ n, where MulticastGrpInfo = MulticastGrpID|HR-MSX/BSAddr|Cert(HR-MSX/BS).

Step 2: Each HR-MSi for 1 ≤ i ≤ n first generates nonce NHR-MSi. Next, HR-MSi computes the signature σHR-

MSi = SIGN(MulticastGrpID|THR-MSi|NHR-MSi|HR-MSX/BSAddr|HR-MSiAddr) and sends Multicast_MSG_#1 message to HR-MSX/BS, where Multicast_MSG_#1 = MulticastGrpID|THR-MSi|NHR-

MSi|HR-MSX/BSAddr|HR-MSiAddr |σHR-MSi|Cert(HR-MSi).

Step 3: HR-MSX/BS first verifies the received timestamps and nonces for freshness and the certificate Cert(HR-MSi) and signature σHR-MSi for 1 ≤ i ≤ n. If the verifications are correct, then HR-MSX/BS generates nonce NHR-MSX/BS, GTEK and MSKi for 1 ≤ i ≤ n and computes key confirmation/message authentication code θHR-MSi = MAC(MSKi|GTEK|NHR-MSX/BS|NHR-MSi|HR-MSX/BSAddr|HR-MSiAddr). HR-MSX/BS then uses HR-MSi's public key to encrypt and obtain ci = EHR-MSi_PK(MSKi, GTEK, MSKi_lifetime, GTEK_lifetime, HR-MSiAddr, HR-MSX/BSAddr). Finally, HR-MSX/BS computes signature σHR-MSi' = SIGN(MulticastGrpID|THR-MSX/BS|NHR-MSX/BS|HR-MSiAddr|HR-MSX/BSAddr|NHR-

MSi|ci|θHR-MSi) and sends Multicast_MSG_#2 message to HR-MSi for 1 ≤ i ≤ n, where Multicast_MSG_#2 = MulticastGrpID|THR-MSX/BS|NHR-MSX/BS|HR-MSiAddr|HR-MSX/BSAddr|NHR-MSi|ci|θHR-MSi|σHR-MSi'.

Step 4: Each HR-MSi for 1 ≤ i ≤ n first verifies the received timestamp and nonces for freshness and the signature σHR-MSi'. If the verifications are correct, then each HR-MSi decrypts ci = EHR-MSi_PK(MSKi, GTEK, MSKi_lifetime, GTEK_lifetime, HR-MSiAddr, HR-MSX/BSAddr) and obtains MSKi, GTEK, MSKi_lifetime and GTEK_lifetime. Next, each HR-MSi verifies θHR-MSi. If the verification is correct, then HR-MSi can commence secure multicast.

Flow Diagram

Join Procedure – PKI-based approach

Flow Chart

Join Procedure – PKI-based approach

Join Procedure – PKI-based approach

Step 1: New mobile station HR-MSj first generates nonce NHR-MSj. Next, HR-MSj computes the MAC θHR-

MSj = MAC(MSKj|MulticastGrpID|THR-MSj|NHR-MSj|HR-BSAddr|HR-MSjAddr) and sends Join_MG_MSG_#1 message to HR-BS, where Join_MG_MSG_#1 = MulticastGrpID| THR-MSj|NHR-MSj|HR-BSAddr| HR-MSjAddr|θHR-MSj.

Step 2: HR-BS first verifies the received timestamps and nonces for freshness and θHR-MSj. If the verifications are correct, then HR-BS generates nonce NHR-BS', GTEK' and computes θHR-BS = MAC(GTEK'|NHR-BS'|HR-BSAddr|MulticastGrpID) and θHR-MSj' =MAC(MSKj|GTEK'|NHR-BS'|NHR-MSj|HR-BSAddr|HR-MSjAddr). HR-BS then encrypt and obtain cj = EMSKj(GTEK', GTEK'_lifetime, HR-MSjAddr, HR-BSAddr). HR-BS also encrypts using the existing GTEK and obtains c' = EGTEK(GTEK', GTEK'_lifetime, HR-BSAddr, NHR-BS') Finally, HR-BS sends Multicast_Join_MSG_#2 message to HR-MSi for 1 ≤ i ≤ n and Multicast_Join_MSG_#3 message to HR-MSj respectively, where Multicast_Join_MSG_#2 = MulticastGrpID|THR-BS'|NHR-BS'|HR-BSAddr| c'|θHR-BS and Multicast_Join_MSG_#3 = MulticastGrpID|THR-

BS'|NHR-BS'|HR-MSjAddr|HR-BSAddr|NHR-MSj|cj| θHR-MSj'.

Step 3a: Each HR-MSi for 1 ≤ i ≤ n first verifies the received timestamp and nonce for freshness. If the verifications are correct, then each HR-MSi decrypts c' and obtains the new GTEK', and GTEK'_lifetime. Next, each HR-MSi verifies θHR-BS. If the verification is correct, then HR-MSi can commence secure multicast.

Step 3b: HR-MSj first verifies the received timestamp and nonces for freshness. If the verifications are correct, then HR-MSj uses MSKj to decrypt c_j and obtains GTEK' and GTEK'_lifetime. Next, HR-MSj verifies θHR-MSj'. If the verification is correct, then HR-MSj can commence secure multicast.

Flow Diagram

Leave Procedure – PKI-based approach

Flow Chart

Leave Procedure – PKI-based approach

Leave Procedure – PKI-based approach

Step 1: HR-MSX/BS generates nonce NHR-MSX/BS', new group key GTEK' and computes θHR-MSi' = MAC(MSKi|GTEK'|NHR-MSX/BS'|HR-MSX/BSAddr|HR-MSiAddr|MulticastGrpID) for 1 ≤ i \!= L ≤ n. HR-MSX/BS then uses the shared key MSKi with the remaining HR-MSi for 1 ≤ i != L ≤ n to encrypt and obtain ci' = EMSKi(GTEK',GTEK'_lifetime, HR-MSX/BSAddr, NHR-MSX/BS'). Finally, HR-MSX/BS sends Multicast_Leave_MSG_#1 messages to remaining HR-MSi for 1 ≤ i != L ≤ n, where Multicast_Leave_MSG_#1 = MulticastGrpID|THR-MSX/BS'|NHR-MSX/BS'|HR-MSX/BSAddr|ci'|θHR-MSi'.

Step 2: Each remaining HR-MSi for 1 ≤ i != L ≤ n first verifies the received timestamp and nonce for freshness. If the verifications are correct, then each remaining HR-MSi uses its shared key MSKi to decrypt ci ' and obtains the new GTEK' and GTEK'_lifetime. Next, each remaining HR-MSi verifies θHR-MSi'. If the verification is correct, then each remaining HR-MSi can commence secure multicast.

GTEK Derivation Used to encrypt data packets for multicast service and

shared amongst the HR-MSs in the multicast group Randomly generated by HR-MSX/BS or from the

authentication server Shall be encrypted using HR-MS’s public key , MSKi/MSKj

pre-shared key or existing GTEK in the Join protocol.

MSKi/MSKj Derivation Key shared between HR-MSi/HR-MSj with Controller HR-

MSX/HR-BS. Used as an encryption key and MAC key Can be randomly generated by HR-MSX/BS in PKI-approach Pre-established in the pre-shared key approach Refreshed/rekeyed periodically to maintain key freshness.

Key Derivation

Proposed text for IEEE802.16n AWD[-------------------------------------------------Start of Text Proposal---------------------------------------------------]

Please refer to C80216n-11_0012r1.doc for proposed text.

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

Proposed new Multicast Key Management protocols for IEEE 802.16n networks

Initial Group Formation Join Protocol Leave Protocol

PKI-based approach Pre-shared key based approach

Conclusion and Misc