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.