Presentation is loading. Please wait.

Presentation is loading. Please wait.

May 14, 2007 Simon Mizikovsky, Zhibi Wang, Alcatel-Lucent ABSTRACT: A security architecture for the UMB RAN-AGW is provided. Multiple PMIP tunnels from.

Similar presentations


Presentation on theme: "May 14, 2007 Simon Mizikovsky, Zhibi Wang, Alcatel-Lucent ABSTRACT: A security architecture for the UMB RAN-AGW is provided. Multiple PMIP tunnels from."— Presentation transcript:

1 May 14, 2007 Simon Mizikovsky, Zhibi Wang, Alcatel-Lucent ABSTRACT: A security architecture for the UMB RAN-AGW is provided. Multiple PMIP tunnels from the RAN to the AGW for the same AT are supported. RECOMMENDATION: Review and approve. Liaise to TSG-S WG4. 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. UMB Security Architecture 3GPP2 TSG-A.4 3GPP2 A40-20070514-xxx

2 2 UMB Security-Architecture

3 3 UMB Security – Access Authentication  Access Authentication with HAAA.  EAP Access Authenticator is in the SRNC  Allows user/device to establish and maintain security association for the radio link and authorization for usage of RAN resources  EAP for Access Authentication is transported between SRNC and AT using the UMB route.  EAP for Access Authentication is transported between SRNC and the HAAA Server using DIAMETER protocol.  Following successful access authentication, local IP address(es) (Simple IP address and/or HoA/CoA/CCoA) are assigned  The MSK (Master Session Key) is delivered to the Access Authenticator (SRNC) from the HAAA.  MSK is bootstrapped to derive local Ciphering and Integrity Keys for the Air Link security.  Re-authentication of AT when a new eBS is added to the active set through EAP-ER or a full EAP

4 4 Initial Access Authentication Need to update this slide with 3-way between SRNC and AT and between eBS1 and AT.

5 5 UMB Security- LAAA Bootstrapping Procedure  SRNC selects Local AAA (LAAA) for Efficient Re-authentication.  Allows LAAA Load Balancing, and may be based on local policies.  The SRNC send the LAAA ID(s) to AT using the UMB route.  The AT executes the EAP bootstrapping procedure (as per EAP-ER Internet Draft) with the LAAA_ID included  Upon successful validation of the bootstrapping request, the EAP server delivers the DSRK to the selected LAAA for future re- authentications.  The LAAA receives the DSRK.  AT computes the DSRK  After this procedure, the LAAA becomes the EAP Server for Re- Authentication.

6 6 LAAA Bootstrapping Procedure

7 7 Fast Re-Authentication (EAP-ER)  Once LAAA is Bootstrapped, AT can re-authenticate with LAAA instead of accessing HAAA.  Fast Re-Authentication uses EAP-ER procedure between AT and LAAA, with the eBS as the Authenticator.  Re-authentication Counter (SQN) is used for replay protection.  The new rMSK is delivered to the eBS and computed by the AT.  Mutually authenticated key exchange between eBS and AT establishes new keys for Air Interface protection.

8 8 Fast Re-Authentication (EAP-ER) on a Serving eBS1

9 9 Addition of eBS to the Route Set  AT can request addition of a new eBS to the Route Set  Addition will be requested and conducted through the current serving eBS (FLSA and RLSA).  EAP-ER between AT and LAAA with the new eBS as Authenticator will establish the rMSK.  The mutually authenticated key agreement between new eBS and AT (via the Serving eBS) will establish keys for Air Interface protection.

10 10 eBS2 is Added to the Route Set (EAP-ER)

11 11  Concern: Latency of EAP-ER Transactions.  Acceptable for Idle-to-Active Transition and most cases of adding the eBS to the Active Set.  Unacceptable for Handoff to a new eBS which was just added to the Active Set.  Concerns: EAP-ER is an IETF Internet Draft, and not an RFC.  This may prevent EAP-ER based re-authentication from being deployed, and full EAP with HAAA will be required for above cases.  Solution:  Create the Transient Key at the Serving (Primary) eBS and send it to a new Target eBS as it is added to the Active Set.  Use this Transient Key to create a Short Lived SA between Target eBS and AT.  Use this Short Lived SA while executing EAP-ER or even Full EAP. Then deprecate the Transient Key. UMB Security - Re-authentication – Concerns and solutions

12 12 “Rapid Handoff” and Use of Transient Keys

13 13  AT sends over RLSS (eBS1) the request to add a new eBS (eBS2) to the active set.  RLSS (eBS1) forwards the request directly to the new eBS2.  Alt.1: eBS1 generates Transient Key for eBS2 (tMSK2).  Alt.2: eBS2 requests and receives session info and Transient Key tMSK2 from SRNC.  eBS2 uses the tMSK2 to compute the tCK2 for Ciphering and tIK2 for Integrity.  tCK=prf(tMSKx, eBSx_ID, AT_ID, TTL, "Transient Ciphering key");  tIKx=prf(tMSKx, eBSx_ID, AT_ID, TTL, "Transient Integrity key").  These keys have a short TTL and can be used for air interface protection if AT attempts to handoff to the eBS2 immediately (~20-50 mSec)  eBS2 issues the Re-Authentication Request towards AT via the FLSS.  AT conducts and completes the EAP or EAP-ER over the FLSS and eBS2 as RLSS.  The RL is tunneled via the eBS1 because there is no PMIP binding for the eBS2 yet.  eBS2 acts as the Authenticator.  Once the EAP or EAP-ER is completed, new rMSK2 is created and tMSK2 is erased.  The 3-way key agreement is executed via the FLSS and eBS2 as RLSS, and rCK2 and rIK2 are computed.  Addition of eBSx is completed and eBSx sends Route ID Mapping to all ANs in active set. UMB Security - Use of Transient Key before Re-Authentication

14 14 Transient key use before Re-Authentication (assuming EAP-ER) (Adding eBS3 to active set) eBS1 (RLSS) S-RNC Device Authenticator and User Authenticator For access (MSK) eBS2 (DAP) (FLSS) eBS3 (tMSK, tIK, tCK) AGW HAAA AT (MSK,EMSK, DSRK, rMSK1..2, TSK1..2, tIK, iCK) AT requests to add eBS3 to the active set ( 6) AT and eBS3 perform EAP-ER auth (detail see next slide) LAAA (DSRK) eBS3 asks AT to do re-Authentication (2) Session Info request (tMSK) (5) (3) eBS3 uses tMSK to calculate the tIK and tCK (1) (4) AT and eBS3 communicate using tIK and tCK if it is needed before re- authentication (7) (8) eBS3 uses rMSK to do 3 way key exchange with AT to derive CK, IK and use the new session keys with AT (7) Route ID mapping

15 15 Re-Authentication Architecture based on EAP-ER (similar for full EAP) eBS1 (DAP) (MSK, TSK1) S-RNC Device Authenticator and User Authenticator For access (MSK) eBS2 (rMSK2, TSK2) eBSn (rMSK3,TSK3) AGW HAAA AT (MSK,EMSK, DSRK, rMSK1..n, TSK1..n) EAP/RLP EAP/AAA 3 Way-Key exchange MSK PMN-HA, PMN-HA-SPI, delivered To eBS1 3 Way-Key exchange 3Way Key exchange LAAA (DSRK) LAAA Attachment rMSK, PMN-HA, PMN-HA-SPI, delivered to eBS after Re-auth (1) (3) (2) (4) (5) (6) (8) (7) rMSK PMN-HA, PMN-HA-SPI, delivered to eBS after Re-auth

16 16 UMB Security – Bootstrapping Micro Mobility (PMIP)  PMIP tunnel setup for micro mobility management:  No need for CMIP re-registration for local mobility  PMIP-RK – Micro Mobility Root Key – derived from DSRK that is generated from EMSK  The PMIP MN-HA Key (PMN-HA) and PMN-HA-SPI, derived from PMIP-RK, delivered to the Access Authenticator by the LAAA during the Authentication procedure.  Access Authenticator sends the PMN-HA key and PMN-HA-SPI to PMIP Client for PMIP Binding authentication.  PMIP HA (AGW) retrieves the PMN-HA key from LAAA to validate Binding Updates.  Diameter protocol is used for this transaction.

17 17 PMIP Security Bootstrapping

18 18 Reverse traffic-Multiple PMIP Bindings  Any eBS that is added to the active set establishes the PMIP binding with AGW  RRQ/RRP or BU/BA are signed by PMN-HA key specific to the eBS–AGW pair.  The PMN-HA keys are distinguished by the unique PMIP-SPI.  The PMN-HA key & PMIP-SPI for the binding are derived from the PMIP-RK.  Transient Key (tMSK) is not bootstrapped for establishing the PMIP binding.  Before new binding is established, the AT traffic is tunneled through other Base Stations which already have active PMIP binding with the AGW.  In cases of “Rapid Handoff” to the newly added eBS, both RL and FL traffic is tunneled by the new eBS through other Base Stations while Re- Authentication and PMIP binding processes are in progress.  FL Traffic towards AT will flow through the DAP – FLSA.  The RL Traffic will flow to the AGW through any RLSA eBS with established PMIP tunnel.  Typical Firewall will drop packets if eBS forwards packets to AGW without established binding (DoS prevention).

19 19 Simultaneous RL Multiple PMIP Binding

20 20 UMB Security – Macro Mobility (CMIP) Authentication  The IP Services Authentication with HAAA through CMIP Authentication  AGW acts as Authenticator and CMIP FA.  CMIP Client establishes binding (sends RRQ or BU) with CMIP FA in the AGW through the established PMIP tunnel.  The CMIP MN-HA key is Bootstrapped from MIP-RK by the AT (UIM).  The MIP-RK is derived from the EMSK after successful EAP procedure.  The CMIP RRQ/BU is forwarded to the CMIP HA.  CMIP HA requests and receives the CMIP MN-HA key from the HAAA, based on the realm of CMIP NAI.  DIAMETER protocol is used for this transaction.  CMIP HA validates CMIP binding.  To assist with additional security, optional MN-FA and FA-HA keys can also be distributed.

21 21 Key Hierarchy rRK PMIP-RK EMSK rMSK 1 rMSK m … TSK 1 TSK m rIK PMIP-RK … MSK TSK Long Term Credential DSRK1 … MIP-RK Re-authentication key hierarchy PMIP tunnel service keys PMN-HA PMN-HA-SPI … HOKEY solution (e.g., draft-vidya-eap-er) DSRKn CMIP tunnel service keys PMN-HA PMN-HA-SPI

22 22 UMB Security- DAP change  The serving eBS can be changed in a time frame of tens of ms  The DAP will not be changed as fast as the serving eBS  When there is a trigger for DAP change: (1)The target DAP sets up the new PMIP tunnel with the AGW using PMN-HA key and PMN-HA-SPI that were sent to the eBS during the Re-Authentication (2)The context exchange with the source DAP (3)The traffic go through new PMIP tunnel (4)Some old traffic still in the old DAP cache will be delivered to the serving eBS.


Download ppt "May 14, 2007 Simon Mizikovsky, Zhibi Wang, Alcatel-Lucent ABSTRACT: A security architecture for the UMB RAN-AGW is provided. Multiple PMIP tunnels from."

Similar presentations


Ads by Google