PKM Version 2: Multicast and Broadcast

1 Multicast and Broadcast Services Support

PKMv2 supports strong protection from theft of multicast and broadcast service by encrypting MBS defined in the IEEE 802.16e amendment.

MBS requires a MBS GSA. It is the set of security information that multiple BS and one or more of its client SSs share but not bound to any MS authorization state to support secure and access-controlled MBS content reception across the IEEE 802.16 network. Each MBS capable of MS may establish a MBS SA during the MS initialization process. MBS GSAs shall be provisioned within the BS. A MBS GSA's shared information includes the cryptographic suite employed within the GSA and key material information such as MAKs and MGTEKs. The exact content of the Marin General Services Authority (MGSA) is dependent on the MGSA's cryptographic suite. As like any other unicast SAs, MBS GSA is also identified using 16-bit SAIDs. Each MS shall establish one or more MBS GSA with its serving BS. Using the PKMv2 protocol, an MS receives or establishes an MBS GSA's keying material. The BS and MBS content server must ensure that each client MS only has access to the MGSAs it is authorized to access. An SA's keying material (e.g., MAK and MGTEK) has a limited lifetime. When the MBS content server or BS delivers MBS SA keying material to an MS, it also provides the MS with that material's remaining lifetime. It is the responsibility of the MS to request new keying material from the MBS server or BS before the set of keying material that the MS currently holds expires at the MBS server or BS.

2 Optional Multicast Broadcast Rekeying Algorithm

When the Multicast Broadcast Rekeying Algorithm (MBRA) is supported, the MBRA is used to refresh traffic keying material efficiently not for the unicast service, but for the multicast or the broadcast service.

Note that an SS may get the traffic keying material before an SS is served with the specific multicast service or the broadcast service. The initial GTEK request exchange procedure is executed by using the key request and key reply messages that are carried on the primary management connection. The GTEK is the TEK for multicast or broadcast service. Once an SS shares the traffic keying material with a BS, the SS does not need to request new traffic keying material. A BS updates and distributes the traffic keying material periodically by sending two key update command messages.

A BS manages the M&B (Multicast & Broadcast) TEK grace time for the respective GSA-ID in itself. The GSA-ID is the SA-ID for multicast or broadcast service. This M&B TEK grace time is defined only for the multicast service or the broadcast service. This parameter means time interval (in seconds), before the estimated expiration of an old distributed GTEK. In addition, the M&B TEK grace time is longer than the TEK grace time managed in an SS.

A BS distributes updated traffic keying material by sending two key update command messages before old distributed GTEK is expired. The usage type of these messages is distinguished according to the key push modes included in the key update command message. The purpose of the key update command message for the GKEK update mode is to distribute the GKEK. The key update command message for the GKEK update mode is carried on the primary management connection. A BS intermittently transmits the key update command message for the GKEK update mode to each SS to reduce the BS's load in refreshing traffic key material. The GKEK is needed to encrypt the new GTEK. The GKEK may be randomly generated in a BS or an ASA server.

A BS transmits the PKMv2 group key update command message for the GTEK update mode carried on the broadcast connection after the M&B TEK grace time starts. The aim of the key update command message for the GTEK update mode is to distribute new GTEK and the other traffic keying material to all SSs served with the specific multicast service or the broadcast service. This GTEK is encrypted with already transmitted GKEK.

An SS shall be capable of maintaining two successive sets of traffic keying material per authorized GSA-ID. Through operation of its GTEK state machines, an SS shall check whether it receives new traffic keying material or not. If an SS gets new traffic keying material, then its TEK grace time is not operated. However, if it does not have that, then an SS shall request a new set of traffic keying material a configurable amount of time, the TEK grace time, before the SS's latest GTEK is scheduled to expire.

If an SS receives two valid key update command messages and shares new valid GKEK and GTEK with a BS, then that SS does not need to request a new set of traffic keying material.

If an SS does not receive at least one of the two key update command messages, then that SS sends the key request message to get a new traffic keying material. A BS responds to the key request message with the key reply message. In other words, if an SS does not get valid new GKEK or GTEK, then the GTEK request exchange procedure initiated by an SS is executed.

An SS tries to get the GTEK before an SS is served with the specific service. The initial GTEK request exchange procedure is executed by using the key request and key reply messages that are carried on the primary management connection.

A BS must be capable of maintaining two successive sets of traffic keying material per authorized GSA-ID. That is, when GKEK has been changed a BS manages the M&B TEK grace time for the respective GSA-ID in itself. Through operation of its M&B TEK grace time, a BS shall push a new set of traffic keying material. This M&B TEK grace time is defined only for the multicast service or the broadcast service in a BS. This parameter means time interval (in seconds) before the estimated expiration of an old distributed GTEK. That is, the M&B TEK grace time is longer than the TEK grace time managed in an SS.

A BS distributes updated GTEK by using two key update command messages when the GKEK has been changed, or by using one (the second) key update command message otherwise, around the M&B TEK grace time, before the already distributed GTEK expires. Those messages are distinguished according to a parameter included in that message, "key push modes." A BS transmits the first key update command message to each SS served with the specific service before the M&B TEK grace time. The first key update command message is carried on the primary management connection. A BS intermittently transmits the first key update command message to each SS to reduce the BS's load for key refreshment. The purpose of the first key update command message is to distribute the GKEK. This GKEK is needed to encrypt the updated GTEK. The GKEK is also encrypted with the SS's KEK. The GKEK may be randomly generated in a BS or an ASA server.

A BS transmits the PKMv2 group key update command message carried on the broadcast connection after the M&B TEK grace time. The aim of the second key update command message is to distribute the GTEK to the specific service group. This GTEK is encrypted with transmitted GKEK before the M&B TEK grace time.

An SS must also be capable of maintaining two successive sets of traffic keying material per authorized GSA-ID. Through operation of its GTEK state machines, an SS checks whether it receives new traffic keying material or not. If an SS gets new traffic keying material, then its TEK grace time is not operated. However, if it does not have that, then the SS requests a new set of traffic keying material for the TEK grace time before the SS's latest GTEK is scheduled to expire.

PKM Version 2: Mutual Authentication

Mutual authentication can take place in one of the two modes of operation. In the first mode, only mutual authentication is used. In the other mode, mutual authentication is followed by EAP authentication. In this second mode, the mutual authentication is performed only for initial network entry and only EAP authentication is performed in the case that authentication is needed for re-entry. SS mutual authorization, controlled by the PKMv2 authorization state machine, is the process of:

1.  The BS authenticating a client SS's identity.

2.  The SS authenticating the BS's identity.

3.  The BS providing the authenticated SS with an AK, from which a KEK and message authentication keys are derived.

4.  The BS providing the authenticated SS with the identities (i.e., the SAIDs) and properties of primary and static SAs for which the SS is authorized to obtain keying information.

After achieving initial authorization, an SS should periodically seek reauthorization with the BS. This reauthorization is also managed by the SS's PKMv2 authorization state machine. An SS must maintain its authorization status with the BS to be able to refresh aging TEKs and GTEKs. TEK state machines manage the refreshing of TEKs. The SS or BS may run optional authenticated EAP messages for additional authentication.

The SS sends an authorization request message to its BS immediately after sending the authentication information message. This is a request for an AK, as well as for the SAIDs identifying any static security SAs that the SS is authorized to participate in. The authorization request includes:

§  A manufacturer-issued X.509 certificate.

§  A list of cryptographic suite identifiers, each indicating a particular pairing of packet data encryption and packet data authentication algorithms that the SS supports.

§  The SS's basic CID. The basic CID is the first static CID that the BS assigns to an SS during initial ranging—the primary SAID is equal to the basic CID.

§  A 64-bit random number generated in the SS.

In response to an authorization request message, a BS validates the requesting SS's identity, determines the encryption algorithm and protocol support it shares with the SS, activates an AK for the SS, encrypts it with the SS's public key, and sends it back to the SS in an authorization reply message. The authorization reply includes:

§  The BS's X.509 certificate.

§  A pre-PAK encrypted with the SS's public key.

§  A 4-bit PAK sequence number, used to distinguish between successive generations of AKs.

§  A PAK lifetime.

§  The identities (i.e., the SAIDs) and properties of the single primary and zero or more static SAs for which the SS is authorized to obtain keying information.

§  The 64-bit random number generated in the SS.

§  A 64-bit random number generated in the BS.

§  The RSA signature over all the other attributes in the auth-reply message by BS, used to assure that the authenticity of the earlier PKMv2 RSA-Reply messages.

An SS must periodically refresh its AK by reissuing an authorization request to the BS. Reauthorization is identical to authorization. To avoid service interruptions during reauthorization, successive generations of the SS's AKs have overlapping lifetimes. Both SS and BS must be able to support up to two simultaneously active AKs during these transition periods. The operation of the authorization state machine's authorization request scheduling algorithm, combined with the BS's regimen for updating and using a client SS's AKs, ensures that the SS can refresh TEK keying information without interruption.

PKM Version 2: Three-Way Handshake

The AK can be derived in one of the three different ways depending on the authentication scheme used. Before the three-way handshake begins, both the BS and SS derive a shared KEK and the HMAC/CMAC keys. The PKMv2 three-way handshake sequence proceeds as follows.

1. During the initial network entry or reauthorization, the BS sends PKMv2 SA-TEK-Challenge (including a random number BS_Random) to the SS after protecting it with the HMAC/CMAC tuple. If the BS does not receive PKMv2 SA-TEK-Request from the SS within SAChallenge-Timer, it resends the previous PKMv2 SA-TEK-Challenge up to SAChallengeMaxResends times. If the BS reaches its maximum number of resends, it initiates another full authentication or drops the SS.

2. If HO Process Optimization Bit #1 is set, indicating that PKM authentication phase is omitted during network re-entry or handover, the BS begins the three-way handshake by appending the SAChallenge tuple TLV to the RNG-RSP. If the BS does not receive PKMv2 SA-TEK-Request from the MS within SaChallengeTimer (suggested to be several times greater than the length of SaChallengeTimer), it may initiate full reauthentication or drop the MS. If the BS receives an initial RNG-REQ during the period that PKMv2 SA-TEK-Request is expected, it shall send a new RNG-RSP with another SaChallenge TLV.

3. The SS sends PKMv2 SA-TEK-Request to the BS after protecting it with the HMAC/CMAC. If the SS does not receive PKMv2 SA-TEK-Response from the BS within SATEKTimer, it must resend the request. The SS may resend the PKMv2 SA-TEK-Request up to SATEKRequestMaxResends times. If the SS reaches its maximum number of resends, it must initiate another full authentication or attempt to connect to another BS. The SS includes, through the security negotiation parameters attribute, the security capabilities that it included in the SBC-REQ message during the basic capabilities negotiation phase.

4. Upon receipt of PKMv2 SA-TEK-Request, the BS confirms that the supplied AKID refers to an AK that is available. If the AKID is unrecognized, the BS ignores the message. The BS also verifies the HMAC/CMAC. If the HMAC/CMAC is invalid, the BS ignores the message. The BS must verify that the BS_Random in the SA TEK Request matches the value provided by the BS in the SA Challenge message. If the BS_Random value does not match, the BS shall ignore the message. In addition, the BS must verify the SS's security capabilities encoded in the security negotiation parameters attribute against the security capabilities provided by the SS through the SBC-REG message. If security negotiation parameters do not match, the BS should report the discrepancy to higher layers.

5. Upon successful validation of the PKMv2 SA-TEK-Request, the BS sends PKMv2 SATEK-Response back to the SS. The message includes a compound TLV list each of which identifies the primary and static SAs, their SA identifiers (SAID), and additional properties of the SA (e.g., type, cryptographic suite) that the SS is authorized to access. In case of HO, the details of any dynamic SA that the requesting MS was authorized in the previous serving BS are also included. In addition, the BS must include, through the security negotiation parameters attribute, the security capabilities that it wishes to specify for the session with the SS (these will generally be the same as the ones insecurely negotiated in SBC-REQ/RSP). Additionally, in case of HO, for each active SA in previous serving BS, corresponding TEK, GTEK, and GKEK parameters are also included. Thus, SA_TEK_Update provides a short-hand method for renewing active SAs used by the MS in its previous serving BS. The TLVs specify SAID in the target BS that shall replace active SAID used in the previous serving BS and also "older" TEK-parameters and "newer" TEK-parameters relevant to the active SAIDs. The update may also include multicast/broadcast Group SAIDs (GSAIDs) and associated GTEK parameter pairs. In case of unicast SAs, the TEK-parameters attribute contains all of the keying material corresponding to a particular generation of an SAID's TEK. This would include the TEK, the TEK's remaining key life-time, its key sequence number, and the CBC IV. The TEKs are encrypted with KEK. In case of group or multicast SAs, the TEK-parameters attribute contains all of the keying material corresponding to a particular generation of a GSAID's GTEK. This would include the GTEK, the GKEK, the GTEK's remaining key lifetime, the GTEK's key sequence number, and the CBC IV. The type and length of the GTEK is equal to the ones of the TEK. The GKEK should be identically shared within the same multicast group or the broadcast group. Contrary Key-Update Command, the GTEKs and GKEKs are encrypted with KEK because they are transmitted as a unicast here. Multiple iterations of these TLVs may occur suitable to recreate and reassign all active SAs and their (G)TEK pairs for the SS from its previous serving BS. If any of the SA parameters change, then those SA parameters encoding TLVs that have changed will be added. The HMAC/CMAC is the final attribute in the message's attribute list.

6. Upon receipt of PKMv2 SA-TEK-Response, an SS verifies the HMAC/CMAC. If the HMAC/CMAC is invalid, the SS ignores the message. Upon successful validation of the received PKMv2 SA-TEK-Response, the SS installs the received TEKs and associated parameters appropriately. The SS also must verify the BS's security negotiation parameters of TLV encoded in the security negotiation parameters attribute against the security negotiation parameters of TLV provided by the BS through the SBC-RSP message. If the security capabilities do not match, the SS should report the discrepancy to upper layers. The SS may choose to continue the communication with the BS. In this case, the SS may adopt the security negotiation parameters encoded in SA-TEK-Response message.

Handover Process | WiMAX Mobility Management

According to the scope of node movement, mobility can be divided into micro-mobility and macro-mobility. On the link layer, most access networks provide mobility by having an access router keep track of the specific AP to which a MS is attached. The localized mobility between pico-cells (probably heterogeneous cells) in the same subnet and the mobility between subnets in one domain is called micro-mobility, whereas the mobility between domains in wide-area wireless networks is called macro-mobility. The mobility solutions like Mobile IP are classified as macro-mobility. But Mobile IP is not suitable for micro-mobility due to its signaling overhead, handover latency, and transient packet loss.

1 Hard Handover and Soft Handover

Hard handover is mandatory to be supported in mobile WiMAX networks. Hence, break-before-make operations may happen during the handover process. In other words, link disconnection may occur and throughput may degrade. Therefore, various levels of optimization are demanded to reduce association and connection establishment with the target BS. These optimization methods are not clearly defined in the IEEE 802.16e specification, so they should be supported on specific WiMAX systems and products.

On the contrary, soft handover is optional in mobile WiMAX networks. Two schemes, macro-diversity handover (MDHO) and fast Base Station switching (FBSS) are supported. In case of MDHO, MS receives from multiple BSs simultaneously during handover, and chooses one as its target BS. As for FBSS, the MS receives from/transmits to one of several BSs (determined on a frame-by-frame basis) during handover, such that the MS can omit the decision process of selecting the target BS to shorten the latency of handover.

2 MAC Layer Handover Procedure

The handover procedure in IEEE 802.16e-2005 is divided into MAC- and PHY-layer handover. Looking at the MAC-layer handover procedure, it is divided into the network topology acquisition phase and the handover process phase according to its performing sequence.

In the network topology acquisition phase, as illustrated in Figure 1, three functions are performed, namely network topology advertisement, MS scanning for neighboring BSs, and association procedure. After receiving a neighbor advertisement message broadcast from the serving BS, the MS gets all the neighboring BSs of its current serving BS. The MS can then perform synchronization with each neighboring BS, and then continue to the handover process phase.

Figure 1: Network topology acquisition phase for handover.

Figure 1: Network topology acquisition phase for handover.

During the handover procedure, the process includes handover decision, handover initiation, and ranging procedures, followed by authorization and registration procedures. These procedures include cell reselection, handover decision and handover initiation, synchronization with new DL, acquisition of UL parameters, ranging, MS reauthorization, reregistration, and termination with the serving BS. These are shown in Figure 2 and Figure 3.

Figure 2: Handover decision, handover initiation, and ranging procedures.

Figure 3: Authorization and registration procedure.

When the MS migrates from its serving BS to its target BS, the following process is executed. First, the MS conducts cell reselection based on the information obtained from the network topology acquisition stage. The handover decision and the handover initiation can be originated by both MS and BS using the MOB_MSHO-REQ/MOB_BSHO-REQ message. When the target BS is decided, the MS sends a MOB_HO-IND message to the serving BS and the actual handover process begins as illustrated in Figure 2.

In the ranging process, the MS can synchronize to the DL of the target BS and obtain DL and UL parameters using the DCD/UCD message. Then RNG_REG/RNG_RSP messages are exchanged to complete the initial ranging process. It may be done in a contention-based or non-contention-based manner.

If the RNG_REG contains the serving BSID, the target BS can obtain the MS information from the serving BS through the backbone network. If the MS is already associated with the target BS at the previous stage, some steps may be omitted. Therefore, the neighboring BS scanning and association should be done right after the handover initiation by utilizing preobtained information before the channel condition changes.

If all physical parameter adjustments are done successfully, the network re-entry process is initiated. Figure 3 shows this procedure. It includes MS authorization and new BS registration. The target BS requests MS authorization information via its backbone network. The new BS registration is performed by REG_REQ and REG_RSP messages. This includes capabilities negotiation, MS authorization, key exchange, and registration. After successful registration with the target BS, the MS can send a MOB_HO-IND message to the serving BS to indicate that handover is completed.