july 21, 2008 alcatel lucent abstract: proposed is key derivation for ehrpd ran handoff....

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 | eHRPD Keying | June 2008 All Rights Reserved © Alcatel-Lucent 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.


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.


Access Network Key Generation

PMK

KDF

MICKey

SKey

Tr

un

c

AuthKey

Tr

un

c

EncKey

Tr

un

cANNonce ATNonce

GKEC.S0067


Key Distribution with GKE to support BS HO.

MS S-BS T-BS RNC

Run [i] = n GKE Instance

PMKPMK

Select [i] = m

Send KEYS[m]

Key InUse [i] = m

Select [i] = m

Secure data with KEYS[m]

Request HO to T-BS

Select [i] = n

Send KEYS[n]HO to T-BS, Key InUse [i] = n

Select [i] = n

Secure data with KEYS[n]

Run [i] = m GKE Instance


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.


Key Distribution with Enhanced GKE to support BS HO.Key Distribution with Enhanced GKE to support BS HO.

MS S-BS T-BS RNC

Run [i] = m GKE Instance

PMK PMK

Select [i] = m and [k] = x

Send KEYS[m][x]

Key InUse [i][k] = m, x

Secure data with KEYS[m][x]

Request HO to T-BS

Send KEYS[m][y]HO to T-BS, Key InUse [i][k] = m, y

Select [i] = m and [k] = y

Secure data with KEYS[m][y]




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.

S.Mizikovsky

Add RNC-RNC and HSGW-HSGW scenarios.Also check on ANID, PMK_ID in KeyREQ.Check on EHMAC256.ANID - unique within HSGW.


Intra-HSGW Inter-RNC Active HandoffIntra-HSGW Inter-RNC Active Handoff

MS S-BS T-BS T-RNC

Run [i] = m GKE Instance; PMK_ID1

PMK1PMK1, PMK_ID1

Send KEYS[m][x]

Key InUse [i][k] = m,x; PMK_ID1


Request HO to T-BS

Send KEYS[m][y]

HO to T-BS, Key InUse [i][k] = m, y; PMK_ID1





S-RNC

A16 Session Transfer Request; Transfer Unused Key Sets

A16 Session Tx Resp; Key InUse [i][k] = m, y


HSGW

A11 RRQ

A11 RRP; PMK2, PMK_ID2


Intra-HSGW Inter-RNC Active Handoff SummaryIntra-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.


Intra-HSGW Inter-RNC Idle HandoffIntra-HSGW Inter-RNC Idle Handoff

MS S-BS T-BS T-RNC

Secure Session Setup with KEYS[m][x]

Send KEYS[m][y]Key InUse [i][k] = m, y; PMK_ID1



Select [i] = m and [k] = x used before entering Idle Mode


S-RNC

A13 Session Transfer Request;

A13 Session Tx Resp; Transfer KEYS[m][x] and Unused Key Sets

HSGW

A11 RRQ

A11 RRP; PMK2, PMK_ID2

Run [i] = n GKE Instance; PMK_ID2


Intra-HSGW Inter-RNC Idle Handoff SummaryIntra-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.


Inter-HSGW Handoff (Active Handoff example)Inter-HSGW Handoff (Active Handoff example)

MS S-AN T-AN

Current Session

A11' RRQKey InUse [i][k] = m, x


GKE with PMK_ID2


S-HSGW T-HSGW

Current Session

Session HO Decision

A16 Session TransferUnused Key Sets

HO Req

HO Rsp

A11' RRP

Data Session

EAP-AKA, agree on New MSK

A11' Registration Update; New PMK and PMK_ID2

A11' Registration Update ACK


Inter-HSGW Active HandoffInter-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.


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.


Inter-HSGW Idle HandoffInter-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.


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.


SummarySummary

•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.

july 21, 2008 alcatel lucent abstract: proposed is key derivation for ehrpd ran handoff....

Documents