1 / 9

Issues with the proposed new EAP-AKA requirements for eHRPD

S40-20080616-004 X50-20080616-0xx. 3GPP2 TSG-S WG4 / TSG-X WG5 (PDS). Issues with the proposed new EAP-AKA requirements for eHRPD. Source: Qualcomm Incorporated Contact(s) Anand Palanigounder ( apg@qualcomm.com ) / Jun Wang ( jwang@qualcomm.com ) Recommendation: Discuss and adopt.

diella
Download Presentation

Issues with the proposed new EAP-AKA requirements for eHRPD

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. S40-20080616-004 X50-20080616-0xx 3GPP2 TSG-S WG4 / TSG-X WG5 (PDS) Issues with the proposed new EAP-AKA requirements for eHRPD Source: Qualcomm IncorporatedContact(s) Anand Palanigounder (apg@qualcomm.com) / Jun Wang (jwang@qualcomm.com) Recommendation: Discuss and adopt

  2. Background • AKA authentication is required by 3GPP to connect to EPC • non-3GPP accesses (such as eHRPD) use EAP-AKA (TS 33.402) • LTE uses AKA without EAP (called EPS AKA) - i.e., AKA protocol carried over LTE L3 (NAS) signaling (TS 33.401) • Contribution S40-20080512-004 to the TSG-S WG4 meeting at Osaka proposed a new key hierarchy for eHRPD based on EAP-AKA • Subsequently, an updated contribution was provided to PDS CC (on 05/29) in X50-20080529-007 • In this contribution: • We identify issues with • the proposed transformation of CK/IK into the CK’/IK’ by binding it with a serving network identity (SNID) • Requirement on eHRPD AT to check AMF separation bit • We also propose a resolution of these issues to progress eHRPD security architecture in 3GPP2

  3. LTE AKA – Summary (for information) • LTE AKA • 3G (UMTS) AKA enhanced for LTE access authentication • Introduces two (security-related) changes to 3G AKA • Key separation between LTE and other accesses (e.g., UMTS, IMS, I-WLAN) using AMF separation bit • indicates that LTE AKA AV (RAND, Kasme, XRES, AUTN) can only be used with LTE access • Serving network identity (SNID) binding • Kasme = KDF (CK, IK, SN Id) • Note: SN Id is called “access network identity” in TS 33.401 • LTE AN broadcasts SNID (MCC, MNC format) to ME • Supposed to prevent attacks due to use of AKA AVs given to one SN from being used in another SN • e.g., while the UE is roaming, the MME obtains a bunch of AKA AVs from HSS & gives the unused AVs to a rogue SN (rogue SN may or may not have roaming relationship with the home network) • The malicious SN tricks the UE to connect through it for service • Possible for LTE (& other 3GPP accesses) because AKA AVs are given to a node in a visited (or serving) network

  4. Issues with changes to EAP-AKA • 3GPP SA3#51 (April 2008) agreed (tentatively) these LTE AKA improvements to: • non-3GPP accesses that use EAP-AKA for access authentication • This is applicable to eHRPD as it uses EAP-AKA to connect to EPC core • AMF separation bit : • claimed to prevent compromise of regular AKA AVs (e.g., from UMTS) from being used with EAP-AKA (e.g eHRPD). • In over view, this provides no perceivable security gain but adds many complexity to eHRPD • no way to ensure that the ME always verifies this bit • how does the AT know when to check this bit and when not to? • For example when eHRPD capable AT using EAP-AKA with PDIF/PDG in I-WLAN • Requires changes to EAP-AKA (implies new version of EAP-AKA) • This will require IETF developing new RFC • Conclusion: AMF separation bit should not be required for eHRPD • SNID binding is even more problematic for non-3GPP accesses (see next slide)

  5. Issues with SNID binding for EAP-AKA • Imposes requirements on non-3GPP accesses such as eHRPD: • Must support the concept of serving network identity (SNID) • authenticator (e.g. PDSN/HSGW) mustknow SNID before AT authentication • AT must know SNID at or before authentication (before MSK derivation) • These reqs seem unnecessary and contradictory to the assumptions regarding non-3GPP accessess • i.e., 3GPP should not impose requirements on non-3GPP accesses • Requires changes to EAP AAA messages from authenticator in non-3GPP access (E.g. from HSGW to AAA) • Non-3GPP accesses (e.g., eHRPD) may not transmit SNID to ATs and/or the same SNID may not be known to the HSGW • requires new signaling from HRPD AN to authenticator and/or from authenticator to UE (depending on the identity) • Introduces additional complexity to eHRPD ANs • E.g. if new identity is chosen then it needs to be configured and communicated to the AT via signaling before/during authentication (e.g. EAP or in new signaling) • Requires definition of SNID and carrying it between the authenticator (HSGW) and the AT through access-specific signaling or through EAP

  6. Any Security gain for EAP-AKA? • EAP Model Assumption: AKA vectors not given to visited network but only to Home AAA server • Home AAA server always in the home network • Only MSK given to the authenticator (e.g. HSGW) • authenticator can still lie it’s identity to the AT and the HAAA • No mechanisms defined to verify the identity claimed by the authenticator • does not mitigate any perceivable security threat in the EAP model • binding would not help prevent against compromise of MSKs • Change of authenticator (within same SN or different SN) requires any how a new MSK for the new authenticator (e.g. for target HSGW) • For example, either through new EAP-AKA auth run or by deriving a new MSK from the old MSK • Conclusion: No perceivable security gain for EAP model due to SNID binding!

  7. Analysis of available options for SNID (1/2) • X50-20080529-007 discussed 4 options for SNID (Option 1 – 4) • We also add a new option: Option 5 (i.e., no SNID binding) • we analyze all 5 options here • Option 1: Technology (RAT-TYPE) • Requires that each non-3GPP RAT define a well-known values to be used by the authenticator and the AT for RAT-TYPE • no security reason to do this when EAP is used • Option 2: Operator (MCC/MNC) • not always available to HRPD ATs • Mandating MCC/MNC implies reconfiguration (of Subnet ID) at all the deployed HRPD ANs • C.S0024-A says each AN subnet id can be either: SID/NID, or MCC/MNC or IPv4 Prefix or IPv6 Prefix • No security gain if same values are used for MCC/MNC (as indicated by X50-20080529-007)

  8. Analysis of available options for SNID (2/2) • Option 3: Authenticator ID (HSGW-ID) • Requires that authenticator ID be communicated to HSS • Format of authenticator ID in each access may vary • Needs to be communicated to AT through access-specific signaling or EAP (by changing EAP) • Option 4: AN-ID • AN-ID is not always available to AT during authentication • Available only after Location Update procedures • Location update procedure is optional in HRPD • Option 5: Do not use SNID binding • this option places no new requirement • We conclude that this option be preferred by 3GPP2

  9. Conclusion & Proposal • Conclusion: • Requiring SNID binding for EAP-AKA for eHRPD provides no perceivable security gain BUT introduces hidden complexities and new requirements • Same applies for the use of AMF separation bit in eHRPD • Proposal: • Conclude that eHRPD does not need: • SNID binding for EAP-AKA • AMF separation bit checking requirement for eHRPD ATs • Send a correspondence to 3GPP (SA3) requesting them to remove the following requirements on eHRPD • SNID binding requirement • AMF separation bit checking requirement

More Related