1. July 21, 2008 Alcatel Lucent ABSTRACT: Proposed is key derivation for eHRPD RAN Handoff. RECOMMENDATION: Review and approve. Notice Contributors grant a free, irrevocable license to 3GPP2 and its Organization Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include portions of the contribution; and at the Organization Partner’s sole discretion to permit others to reproduce in whole or in part such contributions or the resulting Organizational Partner’s standards publication. Contributors are also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by the contributors to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on the contributors. Contributors specifically reserve the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of the contributors other than provided in the copyright statement above. Key Derivation for eHRPD Handoff 3GPP2 TSG-S WG4 3GPP2 TSG-X WG5 3GPP2 S40-20080715-003r1 3GPP2 X50-20080721-xxx

2. All Rights Reserved © Alcatel-Lucent 2008, ##### 2 | eHRPD Keying | June 2008 Overview We propose to use the GKE protocol (C.S0067) as an Access Network Keying Mechanism to generate Air Interface Security Associations. We propose to pre-compute multiple Security Associations, and indicate from the RNC to the UE which specific Association to use with the Target BS. We also propose a minor enhancement to the GKE protocol for improved efficiency while generating multiple Access Network Security Associations.

3. All Rights Reserved © Alcatel-Lucent 2008, ##### 3 | eHRPD Keying | June 2008 GKE as it is today GKE requires the PMK key between the RNC and AT.  The PMK can be computed as the result of Access Authentication. RNC identifies each instance of GKE by a 3-bit SessionKeyIndex [i]  There could be up-to 8 valid instances pre-computed in advance. Each instance generates one Security Association SKey[i] - a set of (j=3) keys  SKey[i] = prf(PMK|PMK-length, ANNonce|ATNonce|Nonce-length, j, …)  One of generated keys is used for internal GKE purposes (MICKey[i]);  Other two keys are used for HRPD Ciphering and Message Integrity. Each instance requires bidirectional exchange of ANNonce & ATNonce.  E.q., to generate 8 sets of session keys, the GKE needs to be run 8 times. The RNC can indicate to the AT which Security Association to use with the target BS by sending the SessionKeyIndex [i] value.

4. All Rights Reserved © Alcatel-Lucent 2008, ##### 4 | eHRPD Keying | June 2008 Access Network Key Generation

5. All Rights Reserved © Alcatel-Lucent 2008, ##### 5 | eHRPD Keying | June 2008 Key Distribution with GKE to support BS HO.

6. All Rights Reserved © Alcatel-Lucent 2008, ##### 6 | eHRPD Keying | June 2008 Enhanced GKE Define the 4-bit SessionKeySubIndex [k] parameter, default = 1  The 4 MSBits of the Reserved field in the KeyRequest Message (C.S0067 Sec.1.6.2.1.) represent the [k-1] value.  Define NGKEPSessionKeyLen = NGKEPSessionKeyLen x (k), where k is simply a multiplier of the total length of computed key material  Resulting (k) x 384-bit keys will be generated in one GKE run (Sec.1.6.1.3) Treat each 384-bit portion as SKey[i] associated with SessionKeySubIndex [k].  i.e. SKey[2,4] represents the 384-bit portion #4 of the SKey(2)  Note: Only the MICKey[i,1] is used for internal GKE signing. To enforce the use of specific SKey[i,k], the access network creates and includes the InUseSessionKeyIndex attribute in an AttributeUpdateRequest message sent on the Control Channel.  The Most Significant Nibble of the InUseSessionKeyIndex (Sec. 1.7) is set = [k-1], thus identifying which particular portion of the SKey[i] is to be used.

7. All Rights Reserved © Alcatel-Lucent 2008, ##### 7 | eHRPD Keying | June 2008 Key Distribution with Enhanced GKE to support BS HO.

8. All Rights Reserved © Alcatel-Lucent 2008, ##### 8 | eHRPD Keying | June 2008 Summary of the GKE Enhancement RNC-specific PMK is generated by the HSGW and is sent to the RNC. RNC and UE execute the GKE, and generate key material of required length. Each 384-bit portion of the generated key material is uniquely indexed. RNC informs the UE which Key Index to use with the Base Station. To change the Security Association either with current Serving Base Station or with next Target Base Station, the RNC tells the UE which index to use.  Up-to 16 Security Associations can be generated with 1 run of GKE, or up-to 128 Security Associations can be pre-computed and simultaneously co-exist.  Any of these Security Associations can be invoked for refresh of handoff.  Once the Security Association is revoked, it is purged. When RNC and UE run out of pre-computed keys, another GKE is executed.

9. All Rights Reserved © Alcatel-Lucent 2008, ##### 9 | eHRPD Keying | June 2008 Intra-HSGW Inter-RNC Active Handoff

10. All Rights Reserved © Alcatel-Lucent 2008, ##### 10 | eHRPD Keying | June 2008 Intra-HSGW Inter-RNC Active Handoff Summary AT requests the HO to a T-BS in another AN (T-RNC) served by the same HSGW S-RNC Transfers remaining unused Key Sets to the T-RNC using A16 signaling. T-RNC selects an available Key Set and sends it to the T-BS. T-RNC sends the Index of the selected Key Set to the S-RNC, which is forwarded through the S-BS to the AT. AT accesses the T-BS in a secure mode using prescribed Key Set. The T-RNC receives the AN-specific PMK from the HSGW in the A11 RRP. When buffer of available Key Sets in the T-RNC is depleted, T-RNC executes a new GKE with AT to replenish the buffer.

11. All Rights Reserved © Alcatel-Lucent 2008, ##### 11 | eHRPD Keying | June 2008 Intra-HSGW Inter-RNC Idle Handoff

12. All Rights Reserved © Alcatel-Lucent 2008, ##### 12 | eHRPD Keying | June 2008 Intra-HSGW Inter-RNC Idle Handoff Summary AT exits the Idle mode accessing T-BS in another AN (T-RNC) served by the same HSGW  AT uses and identifies the Key Set used with S-BS before entering Idle. T-RNC requests the Session Transfer from S-RNC using A13 Signaling. S-RNC Transfers the Current KeyInUse and remaining unused Key Sets to the T-RNC using A13 signaling. T-RNC validates the AT access using the reported KeyInUse. T-RNC selects an available Key Set and sends it to the T-BS and to the AT. AT accesses the T-BS in a secure mode using prescribed Key Set. The T-RNC receives the AN-specific PMK from the HSGW in the A11 RRP. When buffer of available Key Sets in the T-RNC is depleted, T-RNC executes a new GKE with AT to replenish the buffer.

13. All Rights Reserved © Alcatel-Lucent 2008, ##### 13 | eHRPD Keying | June 2008 Inter-HSGW Handoff (Active Handoff example)

14. All Rights Reserved © Alcatel-Lucent 2008, ##### 14 | eHRPD Keying | June 2008 Inter-HSGW Active Handoff The AT informs S-AN of a decision to HO to T-AN, associated with T-HSGW. S-RNC transfers the Session to T-RNC using A16 Signaling, including remaining unused Key Sets. T-RNC selects an available Key Set and sends it to the T-BS and to the AT.  AT will use the prescribed Key Set to secure data for the T-BS. The T-RNC informs the T-HSGW of the new session. T-HSGW receives the Session information context from S-HSGW Once A10 is established, the T-HSGW executes new EAP-AKA with AT, derives the new PMK for the T-RNC, and sends it to T-RNC in the A11 RRP. When buffer of available Key Sets in the T-RNC is depleted, T-RNC executes a new GKE with AT, using the new PMK, to replenish the buffer.

15. All Rights Reserved © Alcatel-Lucent 2008, ##### 15 | eHRPD Keying | June 2008 Inter-HSGW Idle Handoff The AT exits the Idle mode accessing T-AN (T-RNC) served by the T-HSGW.  AT uses and identifies the Key Set used with S-BS before entering Idle. T-RNC requests the Session Transfer from S-RNC using A13 Signaling.  S-RNC returns the Current KeyInUse and remaining unused Key Sets. T-RNC validates the AT access using the reported KeyInUse. T-RNC selects an available Key Set and sends it to the T-BS and to the AT.  AT will use the prescribed Key Set to secure data for the T-BS. The T-RNC informs the T-HSGW of the new session. T-HSGW receives the Session information context from S-HSGW Once A10 is established, the T-HSGW executes new EAP-AKA with AT, derives the new PMK for the T-RNC, and sends it to T-RNC in the A11 RRP. When buffer of available Key Sets in the T-RNC is depleted, T-RNC executes a new GKE with AT, using the new PMK, to replenish the buffer.

16. All Rights Reserved © Alcatel-Lucent 2008, ##### 16 | eHRPD Keying | June 2008 Summary We propose to use the Enhanced GKE protocol to generate multiple sets of Security Keys between the AT and Serving AN, using currently valid PMK.  The Serving AN informs the AT which pre-computed Key Set to use. When session is transferred to another AN, remaining unused Key Sets are transferred with session context, and can be selected by T-AN to secure data. As Key Sets are depleted, they are replenished by executing the GKE again. After the session is transferred to another HSGW, the new EAP-AKA is executed, and new PMK is created. This new PMK will be used when next GKE is executed.