Security Framework for (e)HRPD 1 S GPP2 TSG-S WG4 Source: QUALCOMM Incorporated Contact(s): Anand Palanigounder Recommendation: For Discussion Notice QUALCOMM Incorporated grants a free, irrevocable license to 3GPP2 and its Organizational 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 all or portions of this contribution; and at the Organizational Partner’s sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner’s standards publication. QUALCOMM Incorporated is 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 QUALCOMM Incorporated 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 QUALCOMM Incorporated. QUALCOMM Incorporated specifically reserves 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 QUALCOMM Incorporated other than provided in the copyright statement above.

Overview Scope & Goal Security Considerations – “Assets” of the system Requirements – Security Requirements – Other Requirements Proposed Design for AALS 2

Scope and Goal Scope: Specify how to use AALS with HRPD and eHRPD Access Networks Goals: Specify a security framework for (e)HRPD access security that – Minimizes changes to the existing core and access network elements 3

SECURITY CONSIDERATIONS 4

The following “Assets” are in scope Confidentiality of User data – Includes user data sent/received by the AT, preventing tracking of used resources/services Integrity of Signaling Exceptions: – Messages required to establish the security context – Emergency calls for unauthenticated ATs 5

Existing HRPD Default Protocols* 6 The HRPD Security Layer provides security services to upper layers The Default Protocols are “None” * Figure from C.P C v0.5

Existing HRPD Non-Default Protocols* 7 The Non-Default Protocols of Security Layer * Figure from C.P C v0.5

REQUIREMENTS 8

AALS Security Requirements Authentication – Mutual authentication support is required EAP-AKA (HRPD) or EAP-AKA’ (eHRPD) for authentication Signaling – Encryption and integrity protection of all signaling that terminates at the AALS layer; – The exceptions are: Messages required to establish the security context Emergency calls for unauthenticated UEs Any messages that are identified explicitly by the specifications as being not protected User Data – Encryption of the user plane data Security Protocols – Specify allowed AALS profile(s) for the Security Protocols (e.g., encryption, integrity and key exchange) Mechanisms to perform Key Update/change 9

PROPOSED DESIGN 10

AALS Security Architecture Encryption always terminated at the AN in the HRPD Air-interface Application Layer – May allow encryption to be “turned on” on a per RLP flow basis – How the AN determines which RLP flows require encryption is FFS AALS Signaling integrity terminated at AN 11

AALS Authentication Requirements HRPD: EAP-AKA between the UE and PDSN/AAA as defined in X.S0011-E is required for AALS – Use of CHAP between the UE and PDSN/AAA with AALS is not acceptable from security perspective eHRPD: EAP-AKA’ with HSGW & EPC core as defined in X.S0057 is required with AALS – No other authentication method supported in eHRPD PDSN / HSGW derives PMK (from the MSK of the EAP authentication ) and sends it to the AN No changes to HRPD Access (A12) Authentication – i.e., use of CHAP authentication is acceptable with AALS for A12 12

AALS & Security Layer Protocols Key Exchange – Use of GKE/MKE defined in C.S0067-A with AALS acceptable from security perspective; DH is not acceptable – How the GKE/MKE used with AALS is FFS Integrity Protocol – Use of AES-CMAC (needs to added) Encryption Protocol – Use of AES-CBC with AALS Co-existence of Security Layer protocols with both AALS & the existing HRPD Security Layer 13