Security in IEEE 802.16-2009

The IEEE 802.16-2009 security sublayer is shown in Figure 8.1. In essence, the security sublayer provides for two functionalities: encapsulation and key management. Encapsulation is achieved through a set of defined cryptographic suites that match data encryption techniques to authentication algorithms. Key management refers to how encryption and authentication keys are exchanged and updated during a connection's lifetime.

The standard describes the components of the security sublayer as follows:

• PKM Control Management: Controls all security components.
• Traffic Data Encryption/Authentication Processing: Encrypts/Decrypts traffic and relevant authentication functions.
• Control Message Processing: Process various PKM-related MAC messages.
• Message Authentication Process: Executes message authentication function.
• RSA-based Authentication: Performs RSA-based authentication function using the SS's X.509 digital certification and the BS's X.509 digital certification. This stack is only engaged when RSA is selected as the authorization policy between an SS and a BS.
• EAP Encapsulation/Decapsulation: Provides interface with the EAP layer, when EAP-based authorization or the authentication EAP-based authorization is selected as an authorization policy between an SS and a BS.
• Authorization/SA Control: This stack controls the authorization state machine and the traffic encryption key state machine.
• EAP and EAP Method Protocol: Dependant on the usage of the upper layers, and is beyond standard's scope.

Security Associations

A Security Association (SA) is the basic security connection in IEEE 802.16-2009, and comprises a set of information that is shared between a BS and one or more of its client SSs. In a diversity handoff (MDHO or FBSS), this information can also be shared between the SS and BSs in the diversity set. During initialization, an SS established a Primary SA. Static SAs are maintained within the BS and Dynamic SAs are created on demand for the initiation and termination of service traffic flows. Both Static and Dynamic SAs can be shared by multiple SSs, for example, secure multicast. The contents of a SA include the SA's ID (SAID) that is unique to the SS, and key information required for traffic and signaling exchange in addition to their lifetimes.

Connections are mapped to SAs as follows.

• All transport connections shall be mapped to an existing SA.
• Multicast transport connections may be mapped to any Static or Dynamic SA.
• The secondary management connection shall be mapped to the Primary SA (however, no explicit mapping is required).
• Basic and primary management connections shall not be mapped to an SA.

In effect, and as the standard stipulates, “[a]ll MAC management messages shall be sent in the clear to facilitate registration, ranging and normal operation of the MAC.” Note that an SS's Primary SAID equals the SS's Basic CID.

Authentication

There are two manners in which an SS can be authenticated by the BS. The first, called RSA authentication, involves the SS sending an X.509 certificate in its Authentication Information to the BS. The certificate, provide by SS's manufacturer, contains the SS's MAC address in addition to its public key. The second authentication type is EAP based and can utilize either the X.509 certificate or a Subscriber Identity Module (SIM) card provided by the operator. Support for RSA authentication is mandatory in the version 1 of the standard's PKM and optional in PKMv1. EAP authentication is only supported in PKMv2.

Figure 8.1 Security Sublayer. Reproduced by permission of © 2009 IEEE.

The intent of the Authentication Information is informational, and it may be discarded by the BS. An SS's Authorization Request immediately follows an Authentication Information. In addition to reiterating the SS's X.509 certification, the request contains a list of cryptographic suites that the SS support. In its Authorization Reply, a BS validates the SS's identity, determines cryptographic suite for operation, and provides Authentication Key (AK) for the SS. The authentication key is encrypted with the SS's public key. Both the Request and Reply include randomly generated number to ensure key liveliness.

PKMv2 allows for mutual authentication, which is not supported in PKMv1. Mutual authentication enables SSs to authentication their BSs. This RSA exchange involves the BS additionally providing its X.509 certificate for the SS in the Authorization Reply.

For handovers, the standard allows for a preauthentication process whereby an MS and a target BS would establish an AK prior to handover to accelerate reentry. The exact mechanism for preauthentication is beyond the standard's scope.

Encryption

Traffic Encryption Key (TEK) is acquired once authorization is achieved. A separate TEK is maintained by the SS for each SAID through making a Key Request from the BS. A BS would respond with Key Reply where the key would be encrypted by a Key Encrypting Key (KEK) that is derivable from the AK. The manner in which all keys are derived is defined in the standard, in addition to the relevant key hierarchies (i.e., RSA, RSA-EAP, EAP without RSA, CMAC/HMA/C from AK). The standard also describes the context for each key, how it is obtained and the scope of its usage.

Table 8.1 Cryptographic suites defined in the standard. Reproduced by permission of © 2009 IEEE

At all times, the BS maintains two active sets of keying material per SAID where the lifetimes of the two keys overlap in order to maintain continuous encryption. A TEK is maintained as long as the SS's authorization is validated by the BS for the network, that is, active AK, and the SA.

Table 8.1. shows the cryptography suites as defined in the standard.