Managing subscribers mobility while guaranteeing security implies managing handoff security which includes maintaining authentication, service flows, and key distribution between the BSs involved in the handoff process.
1 KEY MANAGEMENT PROTOCOL
IEEE 802.16e specifications guarantee authentication by using a public-key interchange protocol which establishes the keys and then uses them for authenticating the communicating entities. These keys are then used to produce other keys that will protect management messages integrity and transport the traffic encryption keys (TEKs). Two privacy key management protocols are defined: the PKMv1 and the PKMv2. PKMv2 is an enhancement of the PKMv1 as it enables both device and user authentication and defines a new key hierarchy while supporting advanced encryption standard (AES)-block cipher-based message authentication code (CMAC), AES keys wraps, and multicast and broadcast services (MBS). WiMAX 802.16e defines the Privacy Key Management Protocol (PKMv2) which enables an authentication scheme based on Extensible Authentication Protocol (EAP). The EAP-based authentication begins at the initial network entry when the MS sends an EAP Start message to its managing BS containing uniquely a message header. Next, the MS and the BS start an EAP conversation by exchanging an EAP Transfer message without HMAC/CMAC digest. If the BS has to send an EAP Success message during the EAP conversation, it should send an EAP payload to the MS with PKMv2 EAP Complete message signed by a newly generated EAP integrated key (EIK). The MS can then validate the message and possess EIK and pairwise master key (PMK). Nevertheless, if the MS and the BS negotiate the double EAP mode consisting in the authenticated EAP after EAP, the BS will wait for the EAP Start message before beginning the second round of the EAP authorization. After ending the authorization process, both the MS and the BS will generate the authorization key (AK) according to the primary authentication key (PAK), PMK, and PMK2 in their possession. After that, a security association-TEK three-way handshake will be performed. Note that the authenticated-EAP authorization procedure protects the EAP payload by a HMAC or a CMAC digest using the EIK generated at the first EAP round.
2 AUTHENTICATION
The mobile WiMAX specifications efine the AAA framework as the provider of the authentication services, the authorization services, and the accounting services. The authentication services consist in achieving the device, the user or the combined device, and user authentication along with the mutual authentication while the authorization services include the delivery of information to configure the session for access, mobility, QoS, and other applications. Accounting services manage the information required for both prepaid and postpaid billing and any information that may be used for auditing session activity by both the home NSP and visited NSP. The ASN defines one or more network access server(s) (NASs) which are viewed as the first AAA client where AAA messages originate and authentication and authorization attributes are delivered to AAA applications including the authenticator, the mobility applications (Proxy-Mobile IP, PMIP; foreign agent, FA), and the QoS applications. Mobile WiMAX specifications state that authentication and authorization have to be based on EAP. Different EAP methods can be supported but they need to support the provisioned credential types.
User authentication is based on PKMv2 which is used to transfer EAP over the IEEE 802.16 air interface between the MS and the BS. The authenticator may not be located at the BS level; therefore, the BS may forward the EAP messages using the authentication relay protocol to the authenticator. The latter will encapsulate the EAP messages with conformance to the AAA protocol packets format and then forward them via one or more AAA proxies to the AAA server within the CSN of the home NSP. The AAA server keeps the matching between the subscription and the correspondent subscriber. When the MS is roaming, multiple AAA brokers with AAA proxies may be involved in the authentication process. Mobile WiMAX specifications impose the use of simple or double EAP authentication schemes for achieving device authentication and reject the RSA-based authentication in this case. The EAP methods used for authenticating mobile WiMAX devices have to generate the master session key (MSK) and the extended master session key (EMSK). The network access identifier (NAI) is used as identifier within EAP-based user and device network access authentication. Device credentials are either a device cert or a device PSK while the EAP device identifier should be an AMC address or an NAI in the form of MAC_address@NSP_domain depending on where the device authentication terminates. The PKMv2 procedure occurring at the network entry of the MS is depicted in Figure 1.
First, the initiation of the network entry according to the IEEE 802.16e specifications begins by a successful ranging that is followed by the exchange of SBC messages between the MS and the ASN. That SBC negotiation consists in negotiating the PKM version, PKMv2 security capabilities, and authorization policy. When the 802.16 air link is established between the BS and the MS, a link activation notification is sent to the authenticator that will immediately begin the EAP sequence. The EAP exchange may then begin; it results in the attribution of a particular NAI realm. The shared master session key (MSK) and the EMSK are then established in both the MS and the AAA server. The MSK will be transferred to the authenticator in the ASN within a RADIUS accept message while the EMSK will be retained at the home AAA server. The MS and the authenticator will generate the pairwise master key (PMK) from the MSK. Besides, the MS and the AAA server will generate the mobility keys from the EMSK, thus marking the end of the authentication part of the authorization flow. The authenticator and the MS will generate the AK from the PMK and then the key distributor entity at the authenticator level will deliver the AK and its context to the key receiver entity in the serving BS. The key receiver entity will cash the received information and generate the subsequent subordinate IEEE 802.16e keys from the AK and its context. The MS and the BS will also process the PKMv2 three-way handshake procedure which provides the MS with the list of SA descriptors identifying the primary and the static SAs. At this step, the MS and the BS may use the newly acquired AK for MAC management messages protection. For each SA, the MS will request two TEKs from the BS. The managing BS will randomly generate the keys, encrypt them using the symmetric KEK key and then transfer them to the BS. Next, the MS will process a network registration and the authenticator will be informed of its competition. Finally, the authenticator will trigger the service flow and the DP establishment process. During handoff, the PKMv2 procedure needs to be optimized. For instance, when the mobile moves within the same mobility domain, the AK will be validated by signing and verifying a frame via the CMAC using the AK that is newly derived from the same PMK as long as the PMK remains valid. The AK validation also needs to be combined with ranging. Last but not least, it should be possible to share the TEK within the same mobility domain when handover procedure between two BSs can transfer TEK context information. If the TEK is shared between a set of BSs, those BSs are considered as the same security entities within the same trusted domain.
3 DATA AND CONTROL TRAFFIC PROTECTION
IEEE 802.16e designers tried to address the security flaws of the IEEE 802.16d related to the protection of the control and the data traffic. For instance, IEEE 802.16e specifications introduce the new data link cipher Advanced Encryption Standard Counter with cipher-block-chaining MAC referred to as AES-CCM (counter with cipher-block chaining message authentication code). CCM mixes the counter mode encryption for data confidentiality with the CBC-MAC for data authenticity. This new cipher addresses the most fundamental deficiency of the original data protection scheme which is the lack-of-a-data-authenticity mechanism. The AES-CCM has been selected for many reasons. First, the U.S. National Institute of Standards and Technology has stated that CCM will become an approved mode for AES. Second, this mode is used in IEEE 802.11i. CCM can protect authenticated but unencrypted data so that the encryption scheme protects the GMH. Third, no intellectual property claims have been made against CCM. When using the AES-CCM cipher, the transmitter has to define a unique nonce that is a per-packet encryption randomizer. As specified by IEEE 802.16i standard, IEEE 802.16e adds a packet number to each MPDU to ensure each nonce’s uniqueness while the receiver should verify that the received packets correctly decrypt under AES-CCM and have a monotonically increasing packet number. A traffic encryption state machine with periodic TEK refresh improves the data traffic protection.
The control message’s protection is achieved using the AES based CMAC where CMAC refers to the cipher-based MAC or the MD5-based HMAC schemes. When adopting AES-CMAC, the computation of the keyed hash value defined in the CMAC Tuple should use the CMAC Algorithm with AES. The DL authentication key CMAC_KEY_D will be used to authenticate messages in the DL direction while the UL authentication key CMAC_KEY_U authenticates messages in the UL direction. Theses keys are generated from the AK .
Compared to the checksum mechanism and the error-detecting codes, AES-CMAC guarantees stronger data integrity as it is able to detect intentional and unauthorized data modifications as well as accidental nonmalicious modifications. AES-CMAC achieves the security goals of the HMAC; nevertheless, it is more appropriate to use it for information systems in which the symmetric key block cipher AES is more available than a hash function.
4 SECURITY OF HETEROGENEOUS HANDOFF
Handover between different access networks is a hot research issue because it involves numerous challenges such as security, QoS provision, and billing. If we consider the handoff between IEEE 802.16e or mobile WiMAX and 3G, we will notice that the provided security services should be readdressed. For instance, an MS that accesses Internet services while switching from IEEE 802.16e to the 3G network or vice versa needs to properly process the authorization, authentication, and accounting steps to be able to maintain the ongoing session. If that MS has to execute AAA procedures all over again, the AAA server will be excessively requested while the handoff delay will increase as the MS will perform complicated processes. For all these reasons, the efficiency of the network will be reduced while the ongoing session may be interrupted. Authentication issue in case of vertical handover between IEEE 802.16e and 3G networks. The exemplary network environment they defined is made up of an IEEE 802.16e network, a 3G network, an AAA server, and an interbase station protocol (IBSP) mobility agent server. The 3G network includes an SGSN, a RNC, and multiple 3G BSs. The IEEE 802.16e network is made up of multiple BSs and an Access Router (AR) responsible for managing the wireless areas of several BSs.
When the MS tries to access the Internet from the IEEE 802.16e network via the BS, the managing BS of that MS will access the AAA server via the AR and then execute the AAA processes. After achieving AAA, the MS will be able to access the Internet while other IEEE 802.16e BSs will share the information on that MS by receiving the IBSP message multicasted from the managing BS. The IBSP message is first unicasted using UDP by the managing BS to the IBSP mobility agent server which is in charge of forwarding it. If the MS changes its managing BS but stills in the same IEEE 802.16e network during the session, the new managing BS will multicast the IBSP message throughout the entire network and update the location information of the MS without consulting the IBSP mobility agent server. The IBSP should guarantee the secure exchange of the MSs security context occurring between the current BS and the new BS during handoff. The 3G BS encompasses a virtual BS, a Node-B (NB), and a virtual BS-to-NB (VBS2NB) communication controller. The virtual BS is the representative BS of the 3G network which may be connected to Internet via the SGSN. When it receives the UDP packet with the IBSP message, the 3G BS treats it so that the IEEE 802.16e and the 3G networks can share the same information. The VBS2NB enables the NB to communicate with the virtual BS. The IBSP mobility agent server plays the role of intermediate between the IEEE 802.16e and the 3G networks. It is composed of an IBSP processing module, a representative BS list, and an MS database. The IBSP processing module treats the IBSP messages so that they may be shared between BSs in both access networks connected by the ISP. The representative BS list contains IP addresses of representative BSs in all access IEEE 802.16e and 3G networks that may be connected to each other by the ISP. The MS database contains all information related to the MS and found in the IBSP message such as the authentication key, the BSID, and the accounting information. That database is updated every time the MS enters a new access network. When the MS roams from the IEEE 802.16e network to the 3G network, the MS should issue a request to the 3G BS while the NB in the BS should generate a request for authentication information on the MS to the VBS2NB controller by using the MS-related information. The VBS2NB issues a request for authentication to the virtual BS. The latter should verify whether it possesses the requested authentication information. In that case, the BS will provide that information to the VBS2NB; otherwise, the BS should indicate that it has failed in providing the required data. The VBS2NB will transmit the information to the NB which will decide whether to perform an authentication process on the MS based on the received information. Next, the NB issues a request for PPP connecting the MS to the SGSN via the RNC without requiring generating additional authentication request for authenticating the MS to the SGSN. When the MS returns to the IEEE 802.16e network, the same procedures will be executed in the reverse order.
