HANDOFF SECURITY

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.

 

Figure 1: PKMv2 Authorization and authentication procedure.

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.

HANDOFF WITH UMTS AND WIFI

Mobile WiMAX intends to combine the advantages of both WiFi networks and third generation networks such as UMTS while intercommunicating with both.

1 Handoff with UMTS

If we carefully examine the reference models of both WiMAX and UMTS networks, we will notice that they share many similarities. For instance, the WiMAX ASN may be directly mapped to the UMTS terrestrial radio access network (UTRAN) while the CSN may be mapped to the UMTS core network as their functionalities are distributed in the same fashion. 

Moreover, the QoS classes of service provided by both technologies enable a direct transfer of traffic flows from one network to another. In fact, the UMTS conversational class may be mapped to the UGSs class, the UMTS streaming class to the nrtPS, the UMTS interactive service class to the (extended) rtPS, and the UMTS background class to the BE class. Regarding security, both UMTS and WiMAX networks support mutual authentication and provide integrity, replay protection, confidentiality, and nonrepudiation guarantees. Nevertheless, moving from WiMAX to UMTS will induce degradation in the provided data rates. Network planning authorities may choose between deploying loose or tight coupling between WiMAX and UMTS networks depending on the degree of integration of both networks. 

When loose coupling is implemented, access to the 3G AAA services is guaranteed by the packet data gateway (PDG) edge routers connected to the WiMAX network or routed through the Internet. PDG routers provide a tunnel termination gateway (TTG) between the WiMAX network and the mobile core network while providing charging gateway interfaces, IP address allocation, authentication in external networks, and single access to mobile core network packet data domain services. 

Meanwhile, WiMAX and UMTS traffics are separated so that WiMAX providers can implement their own mobility, authentication, and billing mechanisms while signing roaming agreements with 3G providers. 3G providers will benefit from extending the coverage of their networks while reducing the deployment costs and serving rural or inaccessible areas. However, loose coupling requires the implementation of higher level mobility management protocols that need to be media independent; thus adding complexity and latency when roaming between different access networks. To address this issue, each network should share its admission control and resource management information with the neighboring networks.

When tight coupling is implemented, WiMAX and UMTS networks will use the same core network components including gateways, AAA entities, and infrastructure. More specifically, the WiMAX network will be connected to the UMTS gateway GPRS support node (GGSN) and the packet-switching domain of the UMTS core network. The UMTS considers the WiMAX network as a radio network controller (RNC); therefore, mobile terminals need to implement the UMTS protocol stacks. Compared to loose coupling, tight coupling facilitates the management procedures as the same billing and authentication, and mobility protocols can be used for both networks. Besides, vertical handoff may be easily initialized and optimized as the core network possesses a clear view of resource status in both networks. However, introducing WiMAX traffic into the UMTS network should be preceded by adapting some core network entities to handle new types of load and traffic patterns to avoid capacity conflicts. Last but not least, the tight-coupling approach is less flexible in coverage extensions than loose coupling; consequently, it is generally practical to adopt it when WiAMX and UMTS networks are owned by the same operator and the integration is implemented by means of adding patches to the existing components.

2 Handoff with WiFi

IEEE 802.11e standard aims at providing QoS guarantees at the LAN scale by specifying differentiations mechanisms at the WiFi MAC layer. However, WiFi networks-limited coverage prevents them from providing continuous Internet-related services and real-time applications support anywhere and at any time. On the other hand, IEEE 802.16e, from which inherits mobile WiMAX, faces some problems related with energy saving and quality providing in some indoor areas. Consequently, integrating WiMAX and WiFi is a hot topic that is currently attracting an increasing number of researchers. A multilayer network protocol architecture that aims at addressing QoS and mobility issues for integrating WiFi and WiMAX. In fact, they designed a two-tier network that considers a 802.16e cell as overlay cell that overlays a few WiFi cells and 802.11e cells as underlay cell cluster. When the MS stills under the coverage of WiFi cells, handoff will be performed horizontally as WiFi can provide high bandwidth and good performance. The AP, which offers the highest bandwidth value and reduces the unnecessary handover probability due to signal strength dropping down, will be selected as target AP. Analyze multiple parameters in a cross-layer fashion to optimize the handoff decision. Examples of such parameters, which are adopted during the simulation, include residential time, WiMAX-cell capacity, and blocking and dropping probability.

The proposed network stack supports three IEEE 802.11 physical layers which are 802.11b, 802.11g, and 802.11n, providing data rates of 11, 54, and 250 Mbps. The network stack also includes IEEE 802.16 and IEEE 802.16e physical and MAC layers. A handover layer based on the IEEE 802.21 standard lies between the lower layers and the network layer implementing the Fast Mobile IPv6 protocol. Management entities are present at each layer and implement all the required provisioning, maintenance, operation, and administration functions. They are also in charge of communicating with servers processing the QoS policies, the mobility decisions, and the profiles storage. To define unified layer 2 abstractions in the IEEE 802.21 to support layer 3 fast handoff. Moreover, WiFi/WiMAX and Fast Mobile IP interaction is achieved by the IEEE 802.21 primitives. They also base the handoff decision on the analysis of different link parameters such as signal strength, velocity of MNs, delay, service level prediction, etc. For instance, the target cell selection is speed sensitive, which means that the MNs are directed to the appropriate cell layer according to their velocity to decrease the blocking and dropping probabilities. A handoff protection mechanism consisting in reserving two free guard channels for handoff usage in advance to minimize the dropping of handoff calls. The proposed mobility management scheme depends on three types of arrival hosts in the WiFi cell.

 If a filtered MN arrives in the WiFi cell from neighboring WiMAX cells and overlaid WiMAX cell, the scheme does not change its state. However, if a nonfiltered MN arrives in the WiFi cell from overlaid WiMAX cell and initial session itself, and if the residential time is longer than the residential time threshold and the WiMAX cell has enough capacity, then it will be overflowed to the WiMAX cell to reduce the handoff probability. Otherwise, it will be assigned to the WiFi cell. Overflow thresholds to reduce the dropping of a handoff call and the blocking of a new call. When a nonfiltered MN arrives in the WiFi cell and the blocking and dropping probabilities of the WiMAX cell are less than the overflow threshold, it will be overflowed into the WiMAX cell. Otherwise, it will be assigned to the WiFi cell.

IEEE 802.21 HANDOFF STANDARD | HETEROGENEOUS HANDOFF

IEEE 802.21 specifications aim at defining a framework that supports information exchange between entities belonging to different access networks and helps in taking handoff decisions; they also define a set of functional components that have to execute those decisions. The proposed framework is built around the media independent handover function (MIHF), which lies between layer 2 and layer 3 and provides higher layers with abstracted services through a unified interface. Three services can be distinguished: the event service, the command service, and the information service.

Media independent event services (MIES): In general, handover is triggered by multiple events that may occur at the terminal or the network level. The MIES provides event classification, event filtering, and event reporting corresponding to dynamic changes in link characteristics, link status, and link quality. Figure 1 shows that events can be classified into link events and MIH events. Besides, the event model follows the subscription/notification procedure. More specifically, the MIHF registers link event notifications with the interface while any upper-layers entity may register for an MIHF event notification. Link events are generated by both the physical and the MAC layers and then sent to the MIHF which has to report them to any entity that has registered an MIH event or a remote MIH event. MIH events are generated by the MIHF and may be local or remote. Local events occur at the client level while remote events take place in the network entities. Both link and MIH events are classified into six categories, which are administrative, state change, linkparameter, predictive, link synchronous, and link transmission. The most common events include link up, link down, link parameters change, link going down, link handover imminent, etc. Upon being notified about certain events, the upper layer uses the command service to control the links to switch to a new PoA when needed.

Figure 1: Media-independent event services.

Media independent command service: The media independent command service (MICS) enables MIH users to manage and control link behavior relevant to handovers and mobility. More specifically, MICS commands aim at gathering information about the status of the connected links along with transferring higher-layer mobility and connectivity decisions to lower layers. As shown in Figure 1, upper layers generate MIH commands which may be local or become remote depending on the destination entity. These MIH commands are translated by the MIHF to link commands which differ depending on the access network being used. Examples of MIH commands include MIH poll, MIH scan, MIH configure, and MIH switch. These intend to poll connected links to get informed about their most recent status, to scan for newly discovered links, to configure the new links and then to switch between the available links.

Media independent information service: Mobile terminals need to discover the heterogeneous neighboring networks and communicate with their entities to optimize the handoff process and facilitate seamless handoff when roaming across these networks. To address this issue, media independent information service (MIIS) provides the capability for obtaining the necessary information for handovers. Such information includes neighbor maps, link-layer information, and availability of services related to a particular geographic area. MIIS enables all layers to share IEs required for making handoff decisions; it also specifies the information structure and its representation while implementing a query/response type mechanism. Information may be either static such as the names and providers of the mobile terminals neighboring networks or dynamic such as channel information, MAC addresses, security information, etc. MIIS fulfils quick data transfer understood by different access technologies with very little decoding complexity. In fact, reports can be transferred either by means of type-length value (TLV) or using a schema referred to as resource description framework (RDF) which is represented in eXtensible Markup Language (XML). As layer 2 information may not be available or may not be rich enough to make intelligent handoff decisions, higher-layer services may be consulted to assist in the mobility decision making process.

Service access points: service access points (SAPs) represent the API through which the MIHF can communicate with the upper-layer and the lower-layer entities using IEEE 802.1 primitives. More specifically, we distinguish three types of SAPs: lower-layer SAPs, upper-layer SAPs, and management plane SAPs. Lower-layer SAPs vary according to the network access type as defined by each MAC and PHY relative to the corresponding access technology. On the other hand, upper-layer SAPs define the interface between the MIHF and upper-layer mobility management protocols or policy engines implemented within a client or a network entity. Finally, management SAPs describe the interfaces between the MIHF and the management plane of various networks.