C80216m_09/1085r3
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Proposed AWD Text for Security Association Management
Date
Submitted
2009-04-27
Source(s)
GeneBeck Hahn, KiSeon Ryu and Ronny
YongHo Kim
Voice: +82-31-450-7188
E-mail: gbhahn@lge.com, ksryu@lge.com and
ronnykim@lge.com
LG Electronic Inc.
LG R&D Complex, 533 Hogye-1dong,
Dongan-gu, Anyang, 431-749, Korea
Re:
IEEE 802.16m-09/xxx. ”Call for Comments and Contributions on Project 802.16m Amendment
Working Document”
Target topic "Security Association Management"
Abstract
This contribution proposes the text of security association management section to be included in
the 802.16m amendment working document.
Purpose
To be discussed and adopted by TGm for the IEEE 802.16m amendment working document
Notice
Release
Patent
Policy
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>.
Proposed AWD Text for Security Association Management
Gene Beck Hahn, Ki Seon Ryu and Ronny Yong Ho Kim
LG Electronics
1
C80216m_09/1085r3
1. Introduction
This contribution proposes the amendment text to illustrate the 802.16m security association management and
is intended as a section to be included in 802.16m amendment. The proposed text is developed so that it might
be combined with 802.16 Rev2/D9 [1], it is compliant to the 802.16m SRD [2] and SDD [3]. This contribution
follows the tentative outline and style guide presented in [4]. The text proposal is based on 802,16m SDD [3]. In
Section 2, the changes with regard to 802.16m SDD are outlined, which is aimed at helping the understanding of
the amendment text.
2. Modification from the SDD and Key Descriptions
The text proposed in this contribution is based on Subclause 10.6.4 in 802.16m SDD [3]. The modifications
to the current SDD text are summarized below:

Updated the security association management section.
Subclause 10.6.4 of 802.16m SDD [3] defined a high level view of security association management.
We added the detailed descriptions on the features of the cryptographic suites and keying materials that
shall be shared between AMS and ABS for specific SAID.

Inserted Subclause 15.2.3.4.1, 15.2.3.4.2, 15.2.3.4.2.1 and 15.2.3.4.2.2.
We added Subclauses 15.2.3.4.1, 15.2.3.4.2, 15.2.3.4.2.1 and 15.2.3.4.2.2 to explain the contents of SA,
dynamic SA creation and mapping respectively. The contents of SA and dynamic SA creation/mapping
follow the corresponding features of 802.16 Rev2/D9 except the use of NONCE used for local TEK
derivation [1].
3. References
[1] IEEE P802.16 Rev2 / D9, “Draft IEEE Standard for Local and Metropolitan Area Networks: Air Interface
for Broadband Wireless Access,”
[2] IEEE 802.16m-07/002r7, “802.16m System Requirements Document (SRD)”
[3] IEEE 802.16m-08/003r7, “The Draft IEEE 802.16m System Description Document”
[4] IEEE 802.16m-08/043, “Style guide for writing the IEEE 802.16m amendment”
[5] IEEE 802.16m-08/050, “IEEE 802.16m Amendment Working Document”
4. Text Proposal for Security Sections of IEEE 802.16m Amendment
2
C80216m_09/1085r3
============================= Start of Proposed Text =============================
15.2.3.4 Security Association Management
A security association (SA) is the set of security information required for secure communication between
ABS and AMS.
An SA is shared between an ABS and its client AMS across the 802.16m network. The SA is identified using
an SA identifier (SAID). The SA is applied to the respective flows once an SA is established.
IEEE 802.16m supports unicast SA only
Unicast SA is used to provide keying material to unicast transport connections. The SA is applied to all the
data exchanged within the connection. Multiple connections may be mapped to the same unicast SA. Two types
of SAs are defined in IEEE 802.16m: Static and Dynamic. Unicast SA can be static or dynamic. Static SAs are
assigned by the ABS during network (re-)entry. Dynamic SAs are established and eliminated dynamically. The
ABS may map each transport connection to the dynamic SA.
The unicast SA is used to provide keying material for unicast management connections.
However, SA is not equally applied to all the management messages within the same management connection.
According to the value of MAC header fields, the SA is selectively applied to the management connections.
If AMS and ABS decide “No authorization” as their authorization policy, no SAs will be established. In this
case, Null SAID is used as the target SAID field in service flow creation messages. If authorization is performed
but the AMS and ABS decide to create an unprotected service flow, the Null SAID may be used as the target
SAID field in service flow creation messages (DSA-REQ/RSP).
An SA’s shared information shall include the cryptographic suite employed in the respective SA. The shared
information may include TEKs. The exact content of the SA is dependent on the SA’s cryptographic suite.
Using the PKM protocol, an AMS requests from its ABS an SA’s keying material. The ABS shall ensure that
each client AMS only has access to the SAs it is authorized to access.
A SA’s keying material has a limited lifetime. When the ABS delivers SA keying material to an AMS, it also
provides the AMS with that material’s remaining lifetime. It is the responsibility of the AMS to request the new
keying material from the ABS before the set of keying material that the AMS currently holds expires at the ABS.
Should the current keying material expire before a new set of keying material is received, an AMS shall perform
network entry.
In certain cryptographic suites, key lifetime may be limited by the exhaustion rate of a number of space, e.g.,
the PN of AES CCM mode [i.e, CTR mode with cipher block chaining message authentication code (CBCMAC)]. In this case, the key ends either at the expiry of the key lifetime or the exhaustion of the number space,
which ever is earliest.
15.2.3.4.1 Security Association
A SA contains keying material that is used to protect unicast connections. The contents of SA are as follows:

The SAID, a 4-bit identifier for the SA. The SAID shall be unique within a ABS.
3
C80216m_09/1085r3

TEK0 and TEK1, 128-bit encryption keys, generated locally at ABS and AMS respectively

NONCE0 and NONCE1, 8-bit random numbers used to derive TEK0 and TEK1 respectively

The NONCE refresh timer NONCE0 and NONCE1, a NONCE refresh timer value

PN0 and PN1, 22-bit packet numbers for use by the link cipher

The Cryptographic Suite, encryption method either AES-CCM or AES-CTR
15.2.3.4.2 Dynamic SA creation and mapping
Dynamic Security Associations are SAs that a ABS establishes and eliminates dynamically. AMSs learn the
mapping of a particular privacy-enabled service flow to the specific SA through the exchange of DSx-REQ/RSP
messages:
15.2.3.4.2.1 Dynamic SA creation
The ABS may dynamically establish SAs by issuing a SA ADD message. Upon receiving a SA Add message,
the AMS shall start a TEK state machine for each SA listed in the message.
15.2.3.4.2.2 Dynamic mapping of SA
When creating a new service flow, an AMS may request an existing SA be used by passing the SAID of the
SA in a DSA-REQ or DSC-REQ message. The ABS checks the AMS’s authorization for the requested SA and
generates appropriate response using a DSA-RSP or DSC-RSP message correspondingly.
With ABS-initiated dynamic service creation, a ABS may also map a new service flow to an existing SA that
is supported by a specific AMS. The SAID of the SA shall be communicated to the AMS in DSA-REQ or DSCREQ message.
============================= End of Proposed Text =============================
4