C80216m_09/1071r1
Project
IEEE 802.16 Broadband Wireless Access Working Group <http://ieee802.org/16>
Title
Proposed AWD Text for Security Architecture
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 Architecture"
Abstract
This contribution proposes the text of security architecture 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 Architecture
Gene Beck Hahn, Ki Seon Ryu and Ronny Yong Ho Kim
LG Electronics
1
C80216m_09/1071r1
1. Introduction
This contribution proposes the amendment text to illustrate the 802.16m security architecture and is intended
as a section to be included in 802.16m amendment. The proposed text is developed so that it can be combined
with 802.16 Rev2/D9 [1], it is compliant to 802.16m SRD [2] and 802.16m SDD [3]. This contribution follows
the tentative outline and style guide in [4]. The text proposal is based on current 802,16m SDD [3]. In Section 2,
the main 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.1 in 802.16m SDD [3]. The modifications
to the current SDD text are summarized below:

Updated the security architecture presented in Figure 1.
Subclause 10.6.1 of IEEE 802.16m SDD [3] defined a high level view of functional blocks of security
architecture. We added the detailed descriptions on the security architecture of 802.16m. Also, changes
related to the security management and encryption/integrity protection have been made.

Inserted Subclauses 15.2.3.1.1, 15.2.3.1.2, 15.2.3.1.3, 15.2.3.1.4 and 15.2.3.1.5.
We added Subclauses 15.2.3.1.1, 15.2.3.1.2, 15.2.3.1.3, 15.2.3.1.4 and 15.2.3.1.5 describing the secure
encapsulation of MAC PDUs, key management, authentication, mapping of connections to SAs and the
cryptographic suites for 16m security respectively. These sections essentially inherit the corresponding
features of 802.16 Rev2/D9 [1] and reflect the newly introduced functions for 802.16m [3].
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 Inclusion in the 802.16m Amendment Working Document
2
C80216m_09/1071r1
============================= Start of Proposed Text =============================
15.2.3.1 Security Architecture
The security functions provide subscribers with privacy, authentication, and confidentiality across the IEEE
802.16m network. It does this by applying cryptographic transforms to MAC PDUs carried across connections
between AMS and ABS.
Also, the security functions provide operators with strong protection from theft of service. The ABS protects
against unauthorized access to these data transport services by securing the associated service flows across the
network. The security functions employ the authenticated client/server key management protocol in which the
ABS controls distribution of keying material to the client AMS. Additionally, the basic security mechanisms are
strengthened by adding digital certificate based AMS device authentication to the key management protocol.
If during pre-authentication capabilities negotiation, an AMS specifies that it does not support IEEE 802.16m
security, steps of authorization and key exchange shall be skipped. The ABS, if provisioned so, shall consider
the AMS authenticated; otherwise, the AMS shall not be serviced. Neither the key exchange nor data encryption
performed.
The security architecture of WirelessMAN-OFDMA Advance System consists of the following functional
entities; the AMS, the ABS, and the Authenticator.
Figure 1 describes the protocol architecture of security services.
Scope of IEEE 802.16m Specifications
Scope of recommendations (Out of scope)
EAP Method
EAP
Authorization/SA Control
Location
Privacy
EAP Encapsulation
/Decapsulation
Enhanced Key
Management
PKM Control
MPDU Encryption/Authentication
Security Functions
Figure 1: Functional Blocks of IEEE 802.16m Security Architecture
Within AMS and ABS, the security architecture is divided into two logical entities:
 Security Management Entity
 Encryption and Integrity Entity
3
C80216m_09/1071r1
Security management controls all security components. Besides, this offers the interface with the EAP layer,
when the EAP-based authorization or the authenticated EAP-based authorization is selected as an authorization
policy between AMS and ABS. Security Management controls both the authorization state machine and traffic
encryption key state machine. Finally, this provides the secure distribution of keying data from the ABS to the
AMS. Through security management, the AMS and ABS synchronize keying data; in addition, the ABS uses the
security management to enforce conditional access to network services.
Security management entity functions include :
 Overall Security Management and Control
 EAP Encapsulation/Decapsulation for Authentication
 Privacy Key Management Protocol (e.g. Key Generation/Derivation/Distribution, Key State
Management)
 Authentication and Security Association (SA) Control
 Location Privacy
Encryption and integrity protection secures MPDU across 802.16m network. This defines a set of supported
cryptographic suites, i.e., pairing of MPDU encryption and authentication algorithms, and the rules for applying
those algorithms to MPDU. This encrypts or decrypts the MPDU and executes the authentication function for
MPDU. Also, this executes MPDU authentication function. The CMAC can be supported.
Encryption and integrity protection entity functions include :
 Transport Data Encryption/Authentication Processing
 Management Message Authentication Processing
 Management Message Confidentiality Protection
15.2.3.1.1 Secure Encapsulation of MAC PDUs
MAC header information specific to encryption is allocated in the MAC header format. Encryption is always
applied to the transport MPDUs when required by the selected ciphersuite. However, the management MPDUs
shall be selectively encrypted according to the MAC header information
15.2.3.1.2 Key Management
The key management allows for EAP-based mutual authentication. It also supports periodic re-authentication,
re-authorization and key refresh. It uses strong encryption algorithms to perform key exchanges between AMS
and ABS.
The authentication establishes a shared secret (i.e., AK) between the AMS and ABS. The shared secret is then
4
C80216m_09/1071r1
used to secure subsequent derivation of TEKs. This two-tiered mechanism for key management permits refresh
of TEKs without incurring the overhead of computation-intensive operations.
ABS authenticates AMS during initial authorization exchange. Each AMS presents unique operator-specific
credential. ABS associates AMS‘s authenticated identity to a paying subscriber and hence to the data services
that subscriber is authorized to access.
Since ABS authenticates AMS, it may protect against an attacker employing cloned AMS that masquerades
as legitimate subscriber’s AMS.
The key management adheres to a client/server model, where the AMS requests keying material and the ABS
responds to those requests. This model insures that individual AMS receive only keying material for which they
are authorized.
15.2.3.1.3 Authentication
IEEE 802.16m offers EAP based authentication method. Through authentication, AMS obtains authorization,
keying material from ABS and periodic reauthorization/key refresh.
EAP authentication uses Extensible Authentication Protocol [IETF RFC 3748] in conjunction with operatorselected EAP method (e.g., EAP-TLS [IETF RFC 2716]). The EAP method uses a particular kind of credential such as X.509 certificate in the case of EAP-TLS, or a Subscriber Identity Module in the case of EAP-SIM.
The particular credentials and EAP methods that are to be used are outside of the scope of this specification.
However, the EAP method selected shall fulfill the “mandatory criteria” listed in section 2.2 of RFC 4017. Use
of EAP method not meeting these criteria may lead to security vulnerabilities.
During re-authentication, the EAP transfer messages are protected with the CMAC tuple. The ABS and AMS
shall discard unprotected EAP transfer messages, or EAP transfer messages with invalid CMAC digests during
re-authentication.
15.2.3.1.4 Mapping of connections to SAs
The following rules for mapping connections to SAs apply :
a) All transport connections can be mapped to an existing SA.
b) All management connections can be mapped to an existing SA.
The actual mapping is achieved by including the SAID of an existing SA in the DSA-xxx messages together
with the CID.
5
C80216m_09/1071r1
15.2.3.1.5 Cryptographic Suite
A cryptographic suite is the SA’s set of methods for MPDU encryption, authentication. AES-CCM and AESCTR are adopted as the ciphersuites of IEEE 802.16m.
============================= End of Proposed Text = m============================
6