--- 1/draft-ietf-emu-rfc5448bis-02.txt 2018-10-19 04:13:18.707240533 -0700 +++ 2/draft-ietf-emu-rfc5448bis-03.txt 2018-10-19 04:13:18.795242643 -0700 @@ -1,32 +1,32 @@ Network Working Group J. Arkko Internet-Draft V. Lehtovirta Obsoletes: 5448 (if approved) V. Torvinen Updates: 4187 (if approved) Ericsson Intended status: Informational P. Eronen -Expires: March 21, 2019 Nokia - September 17, 2018 +Expires: April 22, 2019 Nokia + October 19, 2018 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') - draft-ietf-emu-rfc5448bis-02 + draft-ietf-emu-rfc5448bis-03 Abstract - This specification defines a new EAP method, EAP-AKA', a small - revision of the EAP-AKA method. The change is a new key derivation - function that binds the keys derived within the method to the name of - the access network. The new key derivation mechanism has been - defined in the 3rd Generation Partnership Project (3GPP). This - specification allows its use in EAP in an interoperable manner. In - addition, EAP-AKA' employs SHA-256 instead of SHA-1. + This specification defines an EAP method, EAP-AKA', a small revision + of the EAP-AKA method. EAP-AKA' provides a key derivation function + that binds the keys derived within the method to the name of the + access network. The key derivation mechanism has been defined in the + 3rd Generation Partnership Project (3GPP). This specification allows + its use in EAP in an interoperable manner. In addition, EAP-AKA' + employs SHA-256 instead of SHA-1. This specification also updates RFC 4187 EAP-AKA to prevent bidding down attacks from EAP-AKA'. This version of the EAP-AKA' specification provides updates to specify the protocol behaviour for 5G deployments as well. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on March 21, 2019. + This Internet-Draft will expire on April 22, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -74,52 +74,51 @@ 4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 16 5. Peer Identities . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Username Types in EAP-AKA' Identities . . . . . . . . . . 18 5.2. Generating Pseudonyms and Fast Re-Authentication Identities . . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Identifier Usage in 5G . . . . . . . . . . . . . . . . . 19 5.3.1. Key Derivation . . . . . . . . . . . . . . . . . . . 20 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute . . . . . . . . . . . . . . . . . . . . . . 21 6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 23 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 28 - 7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 30 - 7.4. Security Properties of Binding Network Names . . . . . . 31 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 - 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 32 - 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 32 + 7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29 + 7.4. Security Properties of Binding Network Names . . . . . . 30 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 + 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 31 + 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 31 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 32 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 9.1. Normative References . . . . . . . . . . . . . . . . . . 33 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 9.2. Informative References . . . . . . . . . . . . . . . . . 34 - Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 37 - Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 38 - Appendix C. Changes from Previous Version of This Draft . . . . 38 + Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 36 + Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 37 + Appendix C. Changes from Previous Version of This Draft . . . . 37 Appendix D. Importance of Explicit Negotiation . . . . . . . . . 38 Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 39 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 43 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 1. Introduction - This specification defines a new Extensible Authentication Protocol + This specification defines an Extensible Authentication Protocol (EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA - method originally defined in [RFC4187]. What is new in EAP-AKA' is - that it has a new key derivation function, specified in - [TS-3GPP.33.402]. This function binds the keys derived within the - method to the name of the access network. This limits the effects of - compromised access network nodes and keys. This specification - defines the EAP encapsulation for AKA when the new key derivation - mechanism is in use. + method originally defined in [RFC4187]. EAP-AKA' provides a new key + derivation function, specified in [TS-3GPP.33.402]. This function + binds the keys derived within the method to the name of the access + network. This limits the effects of compromised access network nodes + and keys. This specification defines the EAP encapsulation for AKA + when the new key derivation mechanism is in use. 3GPP has defined a number of applications for the revised AKA mechanism, some based on native encapsulation of AKA over 3GPP radio access networks and others based on the use of EAP. For making the new key derivation mechanisms usable in EAP-AKA, additional protocol mechanisms are necessary. Given that RFC 4187 calls for the use of CK (the encryption key) and IK (the integrity key) from AKA, existing implementations continue to use these. Any change of the key derivation must be unambiguous to both sides in the @@ -909,36 +908,30 @@ the one communicated outside EAP in link layer messaging. In this case, the used identity MUST be the identity most recently communicated by the peer to the network, again regardless of what type of identity it may have been. 5.3.1.1. Format of the SUPI A SUPI is either an IMSI or a Network Access Identifier [RFC4282]. - The NAI string MUST be directly used in key derivation, and for IMSI, - the following string MUST be used: - - o Three ASCII digits to represent the Mobile Country Code (MCC). - - o Three ASCII digits to represent the Mobile Network Code (MNC). If - there are only 2 significant digits in the MNC, one "0" digit - shall be inserted at the left side to fill the 3 digits coding of - MNC. + When used in EAP-AKA', the format of the SUPI MUST be as specified in + [TS-3GPP.23.003] Sections 28.7.2, with the semantics defined in + [TS-3GPP.23.003] Section 2.2B. Also, in contrast to [RFC5448], in 5G + EAP-AKA' does not use the "0" or "6" prefix in front of the entire + IMSI. - o ASCII digits to represent the rest of the IMSI. + For instance, if the IMSI is 234150999999999 (MCC = 234, MNC = 15), + the NAI format for the SUPI takes the form: - The component values are specified in more detail in - [TS-3GPP.23.003]. Note that no prefix ("0" or "6") in front of the - entire IMSI is used in the IMSI when used in the key derivation - function in 5G. + 234150999999999@nai.5gc.mnc015.mcc234.3gppnetwork.org 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute The EAP authentication option is only available in 5G when the new 5G core network is also in use. However, in other networks an EAP-AKA' peer may be connecting to other types of networks and existing equipment. When the EAP peer is connecting to a 5G access network and uses the 5G Non-Access Stratum (NAS) protocol [TS-3GPP.24.501], the EAP server @@ -983,50 +975,41 @@ Similarly, if the peer is communicating over a non-3GPP network but carrying EAP inside 5G NAS protocol, it MUST assume that the EAP server is in a 5G network, and again employ the SUCI within EAP. Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is configured to use. 5.3.2.1. Format of the SUCI - The SUCI format extends the format specified in [RFC4187] - Section 4.1.1.6 for IMSIs. - - A SUCI SHOULD be represented by an ASCII string containing the - following components in sequence: - - o A leading "6" - - o Three ASCII digits to represent the Mobile Country Code (MCC). - - o Three ASCII digits to represent the Mobile Network Code (MNC). If - there are only 2 significant digits in the MNC, one "0" digit - shall be inserted at the left side to fill the 3 digits coding of - MNC. + When used in EAP-AKA', the format of the SUCI MUST be as specified in + [TS-3GPP.23.003] Section 28.7.3, with the semantics defined in + [TS-3GPP.23.003] Section 2.2B. Also, in contrast to [RFC5448], in 5G + EAP-AKA' does not use the "0" or "6" prefix in front of the + identifier. - o Four ASCII digits to represent a routing indicator. + For instance, assuming the IMSI 234150999999999, where MCC=234, + MNC=15 and MSISN=0999999999, the Routing Indicator 678, and a Home + Network Public Key Identifier of 27, the NAI format for the SUCI + takes the form: - o One hex character ("0" through "9" and "a" through "f") to - represent the protection profile. + For the null-scheme: - o Hex characters representing Home Network Public Key Identifier - (HNPKI). The number of hex characters needed for this depends on - the protection profile. + type0.rid678.schid0.userid0999999999@nai.5gc.mnc015. + mcc234.3gppnetwork.org - o Hex characters representing the encrypted identity. The number of - hex characters depends on the protection profile and identity - being encrypted. + For the Profile protection scheme: - The component values are specified in more detail in - [TS-3GPP.23.003]. + type0.rid678.schid1.hnkey27.ecckey. + cip.mac@nai.5gc. + mnc015.mcc234.3gppnetwork.org 6. Exported Parameters The EAP-AKA' Session-Id is the concatenation of the EAP Type Code (50, one octet) with the contents of the RAND field from the AT_RAND attribute, followed by the contents of the AUTN field in the AT_AUTN attribute: Session-Id = 50 || RAND || AUTN @@ -1254,23 +1237,23 @@ external security mechanism with EAP-AKA are beyond the scope of this document. Finally, as with other EAP methods, even when privacy-friendly identifiers or EAP tunneling is used, typically the domain part of an identifier (e.g., the home operator) is visible to external parties. 7.2. Discovered Vulnerabilities There have been no published attacks that violate the primary secrecy - or authentication properties defined for the anticipated - Authentication and Key Agreement (AKA) under the originally assumed - trust model. The same is true of EAP-AKA'. + or authentication properties defined for Authentication and Key + Agreement (AKA) under the originally assumed trust model. The same + is true of EAP-AKA'. However, there have been attacks when a different trust model is in use, with characteristics not originally provided by the design, or when participants in the protocol leak information to outsiders on purpose, and there has been some privacy-related attacks. For instance, the original AKA protocol does not prevent supplying keys by an insider to a third party as done in, e.g., by Mjolsnes and Tsay in [MT2012] where a serving network lets an authentication run succeed, but then misuses the session keys to send traffic on the @@ -1281,29 +1264,30 @@ Another class of attacks is the use of tunneling of traffic from one place to another, e.g., as done by Zhang and Fang in [ZF2005] to leverage security policy differences between different operator networks, for instance. To gain something in such an attack, the attacker needs to trick the user into believing it is in another location where, for instance, it is not required to encrypt all payload traffic after encryption. As an authentication mechanism, EAP-AKA' is not directly affected by most such attacks. EAP-AKA' network name binding can also help alleviate some of the attacks. In - any case, it is RECOMMENDED that EAP-AKA' configuration not be + any case, it is recommended that EAP-AKA' configuration not be dependent on the location of where a request comes from. Zhang and Fang also looked at Denial-of-Service attacks [ZF2005]. A serving network may request large numbers of authentication runs for a particular subscriber from a home network. While resynchronization process can help recover from this, eventually it is possible to exhaust the sequence number space and render the subscriber's card unusable. This attack is possible for both native AKA and EAP-AKA'. + However, it requires the collaboration of a serving network in an attack. It is recommended that EAP-AKA' implementations provide means to track, detect, and limit excessive authentication attempts to combat this problem. There has also been attacks related to the use of AKA without the generated session keys (e.g., [BT2013]). Some of those attacks relate to the use of originally man-in-the-middle vulnerable HTTP Digest AKAv1 [RFC3310]. This has since then been corrected in [RFC4169]. The EAP-AKA' protocol uses session keys and provides @@ -1359,21 +1343,21 @@ Beyond these operational considerations, there are also technical means to improve resistance to these attacks. One approach is to provide Perfect Forwards Secrecy (PFS). This would prevent any passive attacks merely based on the long-term secrets and observation of traffic. Such a mechanism can be defined as an backwards- compatible extension of EAP-AKA', and is pursued separately from this specification [I-D.arkko-eap-aka-pfs]. Alternatively, EAP-AKA' authentication can be run inside a PFS-capable tunneled authentication method. In any case, the use of some PFS-capable - mechanism is RECOMMENDED. + mechanism is recommended. 7.4. Security Properties of Binding Network Names The ability of EAP-AKA' to bind the network name into the used keys provides some additional protection against key leakage to inappropriate parties. The keys used in the protocol are specific to a particular network name. If key leakage occurs due to an accident, access node compromise, or another attack, the leaked keys are only useful when providing access with that name. For instance, a malicious access point cannot claim to be network Y if it has stolen @@ -1462,60 +1446,60 @@ 2-65535 Unassigned 9. References 9.1. Normative References [TS-3GPP.23.003] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 15)", 3GPP Draft - Technical Specification 23.003, June 2018. + Technical Specification 23.003, September 2018. [TS-3GPP.23.501] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture and procedures for 5G System; (Release 15)", 3GPP Technical Specification - 23.501, December 2017. + 23.501, September 2018. [TS-3GPP.24.302] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3; (Release 15)", 3GPP Draft Technical - Specification 24.302, June 2018. + Specification 24.302, September 2018. [TS-3GPP.24.501] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Access to the 3GPP Evolved Packet Core (EPC) via non-3GPP access networks; Stage 3; (Release 15)", 3GPP Draft Technical - Specification 24.501, June 2018. + Specification 24.501, September 2018. [TS-3GPP.33.102] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture (Release 15)", 3GPP Draft Technical Specification 33.102, June 2018. [TS-3GPP.33.402] 3GPP, "3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP accesses (Release 15)", 3GPP Draft Technical Specification 33.402, June 2018. [TS-3GPP.33.501] 3GPP, "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; 3G Security; Security architecture and procedures for 5G System (Release 15)", 3GPP Draft Technical Specification - 33.501, June 2018. + 33.501, September 2018. [FIPS.180-4] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-4, August 2015, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997,