All Rights Reserved © Alcatel-Lucent 2007, ##### 1 | Presentation Title | January 2007 UMB Security Evolution Proposal Abstract: This contribution proposes a security architecture for evolved UMB network. Source: Alcatel-Lucent Semyon Mizikovsky Zhibi Wang Alec Brusilovsky Sarvar Patel Date: January 25, 2007 Recommendation: Review and adopt proposal for UMB Security Architecture.

All Rights Reserved © Alcatel-Lucent 2007, ##### 2 | Presentation Title | January 2007 Architecture Highlights  There are two levels of authentication:  Link Layer/ Access Authentication  Authentication of access subscription held in a UIM, authorizing access to network resources.  Can be done by “Owner” of subscription – Home Service Provider (HSP).  Can be combined with Device Validation if HSP “owns” the Device.  Can be contingent on a success of Device Validation.  Planned to be based on EAP, therefore requires Authenticator in the Serving Network, also called Layer 2 Authenticator.  Mobility Authentication  Authentication of Bindings required to preserve IP session micro- and macro-mobility.  Does not require Authenticator, as it is not based on EAP protocols. Therefore the term Layer 3 Authenticator is misleading.  Current 1xEV-DO Rev.A MobileIP Authentication uses its own keys unrelated to the Access level keys. We propose to bootstrap MIP keys from Access Authentication.  There is an additional Device Validation procedure  Validation of device shell, MAC address integrity, ESN, Model Number compliance, Manufacturer TAG ID, SKU, etc.  Can be done by serving CSN (“Owner” of device subsidy) by validating Device Certificate, but can not protect from cloning.  To satisfy Authentication security requirements, needs the pre-provisioned secret in the secure memory (UIM?), which links it to Access Authentication.  If based on EAP and not combined with Access Authentication, requires a separate Authenticator in the Serving Network.

All Rights Reserved © Alcatel-Lucent 2007, ##### 3 | Presentation Title | January 2007 Levels of Authentication and Key Distribution Framework UIM Device CMIP AAA Mobility Subscription Device and Access Subscription Device Ownership Access Auth HA AG CMIP FA PMIP HA PMIP MN-HA, FA-HA MN-FA, FA-HA, PMIP-RK MIP-RK, PMIP-RK (P)MN-HA X Y Access-Specific protocols and transactions Access-Agnostic protocols and transactions eBS 9 (P)MN-HA1 MSK, PMIP-RK

All Rights Reserved © Alcatel-Lucent 2007, ##### 4 | Presentation Title | January 2007 Process steps 1.User Authentication is executed between the UIM and Subscription Holder – Home AAA. The UIM terminates the EAP Method. The EAPoHRPD is terminated between MS Shell and Access Authenticator.  At initial access, the Device may be validated first, using EAP between MS Shell and Access Authenticator. EAPoHRPD protocol is used on this link. 2.User/Subscription Authentication is done by EAP Server - Home AAA that terminates the EAP Method. RADIUS or DIAMETER protocol is used between User Authenticator / NAS and the AAA Server.  Device Validation is done by EAP Server – AAA that validates Device Credentials. RADIUS or DIAMETER protocol is used between Device Authenticator / NAS and the AAA Server.  The MSK (Master Session Key) is delivered to the Access Authenticator from the AAA. It is used to derive local Ciphering and Integrity Keys for the Air Link security.  The PMIP-RK is delivered to the Access Authenticator from the AAA. It is used for Proxy MIP Binding authentication.  Access Authenticator generates the (P)MN-HA Key from PMIP-RK and loads it into the PMIP Client.

All Rights Reserved © Alcatel-Lucent 2007, ##### 5 | Presentation Title | January 2007 Process Steps (cont) 3.PMIP Client established binding with PMIP HA in the AG. The (P)MN-HA key is used to sign the binding request. 4.PMIP HA in AG requests the (P)MN-HA key from the Mobility AAA. RADIUS or DIAMETER protocol is used for this transaction. 5.If Access AAA and Mobility AAA have a ‘Bootstrapping’ agreement, than bootstrapping of MIP-RK and PMIP-RK from EMSK is requested from Access AAA. Otherwise, Mobility AAA just uses its own pre-configured keys for MIP. The MIP-RK and PMIP-RK are returned to Mobility AAA, which computes (P)MN-HA key and returns it to the PMIP HA. PMIP HA validates PMIP binding. 6.CMIP Client establishes binding (sends RRQ) with CMIP FA in the AG through the established PMIP tunnel. The CMIP MN-HA key for authenticating this binding is computed from MIP-RK by the UIM. 7.The CMIP RRQ is forwarded to the CMIP HA. 8.CMIP HA requests and receives the MN-HA key from the Mobility AAA. RADIUS or 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. 9.As Mobile moves to another eBS, the (P)MN-HA key is sent to the target PMIP Client by the Anchored Access Authenticator.