--- 1/draft-ietf-emu-rfc5448bis-05.txt 2019-11-17 21:13:21.831174862 -0800 +++ 2/draft-ietf-emu-rfc5448bis-06.txt 2019-11-17 21:13:21.927177320 -0800 @@ -1,22 +1,22 @@ 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: January 9, 2020 Independent - July 8, 2019 +Expires: May 21, 2020 Independent + November 18, 2019 Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') - draft-ietf-emu-rfc5448bis-05 + draft-ietf-emu-rfc5448bis-06 Abstract The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the primary authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA. This memo replaces the specification of EAP-AKA'. EAP-AKA' was @@ -42,21 +42,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 January 9, 2020. + This Internet-Draft will expire on May 21, 2020. Copyright Notice Copyright (c) 2019 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 @@ -97,21 +97,21 @@ 7.4. Security Properties of Binding Network Names . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 35 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 35 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . 35 9.2. Informative References . . . . . . . . . . . . . . . . . 37 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 41 Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 41 - Appendix C. Changes from Previous Version of This Draft . . . . 42 + Appendix C. Changes from Previous Version of This Draft . . . . 41 Appendix D. Importance of Explicit Negotiation . . . . . . . . . 43 Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 44 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 1. Introduction The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the primary authentication mechanism for devices wishing to access mobile @@ -644,21 +644,21 @@ 3.4. Hash Functions EAP-AKA' uses SHA-256 / HMAC-SHA-256, not SHA-1 / HMAC-SHA-1 (see [FIPS.180-4] [RFC2104]) as in EAP-AKA. This requires a change to the pseudo-random function (PRF) as well as the AT_MAC and AT_CHECKCODE attributes. 3.4.1. PRF' The PRF' construction is the same one IKEv2 uses (see Section 2.13 of - [RFC4306]). The function takes two arguments. K is a 256-bit value + [RFC7296]). The function takes two arguments. K is a 256-bit value and S is a byte string of arbitrary length. PRF' is defined as follows: PRF'(K,S) = T1 | T2 | T3 | T4 | ... where: T1 = HMAC-SHA-256 (K, S | 0x01) T2 = HMAC-SHA-256 (K, T1 | S | 0x02) T3 = HMAC-SHA-256 (K, T2 | S | 0x03) T4 = HMAC-SHA-256 (K, T3 | S | 0x04) @@ -1030,21 +1030,21 @@ If no identity was communicated inside EAP, then the identity is 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]. + A SUPI is either an IMSI or a Network Access Identifier [RFC7542]. When used in EAP-AKA', the format of the SUPI MUST be as specified in [TS-3GPP.23.003] Section 28.7.2, with the semantics defined in [TS-3GPP.23.003] Section 2.2A. Also, in contrast to [RFC5448], in 5G EAP-AKA' does not use the "0" or "6" prefix in front of the entire IMSI. For instance, if the IMSI is 234150999999999 (MCC = 234, MNC = 15), the NAI format for the SUPI takes the form: @@ -1222,21 +1222,21 @@ non-trivial information about any of these keys based on the other keys. An attacker also cannot calculate the pre-shared secret from IK, CK, IK', CK', K_encr, K_aut, K_re, MSK, or EMSK by any practically feasible means. EAP-AKA' adds an additional layer of key derivation functions within itself to protect against the use of compromised keys. This is discussed further in Section 7.4. EAP-AKA' uses a pseudo-random function modeled after the one used - in IKEv2 [RFC4306] together with SHA-256. + in IKEv2 [RFC7296] together with SHA-256. Key strength See above. Dictionary attack resistance Under the SHA-256 assumption, the properties of EAP-AKA' are at least as good as those of EAP-AKA in this respect. Refer to [RFC4187], Section 12 for further details. @@ -1674,24 +1674,23 @@ [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, . [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, January 2006, . - [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The - Network Access Identifier", RFC 4282, - DOI 10.17487/RFC4282, December 2005, . + [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, + DOI 10.17487/RFC7542, May 2015, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . @@ -1741,34 +1740,25 @@ Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, . [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity Selection Hints for the Extensible Authentication Protocol (EAP)", RFC 4284, DOI 10.17487/RFC4284, January 2006, . - [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) - Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005, - . - [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, "Network Discovery and Selection Problem", RFC 5113, DOI 10.17487/RFC5113, January 2008, . - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", RFC 5226, - DOI 10.17487/RFC5226, May 2008, . - [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, . [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, DOI 10.17487/RFC5448, May 2009, . @@ -1781,20 +1771,25 @@ [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . + [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. + Kivinen, "Internet Key Exchange Protocol Version 2 + (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October + 2014, . + [I-D.arkko-eap-aka-pfs] Arkko, J., Norrman, K., and V. Torvinen, "Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)", draft-arkko-eap-aka-pfs-04 (work in progress), January 2019. [Heist2015] Scahill, J. and J. Begley, "The great SIM heist", February 2015, in https://firstlook.org/theintercept/2015/02/19/ @@ -1864,26 +1859,26 @@ definition in RFC 5448, which referenced RFC 4187. See Section 5. Thirdly, exported parameters for EAP-AKA' have been defined in Section 6, as required by [RFC5247], including the definition of those parameters for both full authentication and fast re- authentication. The security, privacy, and pervasive monitoring considerations have been updated or added. See Section 7. - The references to [RFC2119], [RFC5226], [FIPS.180-1] and [FIPS.180-2] - have been updated to their most recent versions and language in this - document changed accordingly. Similarly, references to all 3GPP - technical specifications have been updated to their 5G (Release 15) - versions or otherwise most recent version when there has not been a - 5G-related update. + The references to [RFC2119], [RFC7542], [RFC7296], [RFC8126], + [FIPS.180-1] and [FIPS.180-2] have been updated to their most recent + versions and language in this document changed accordingly. + Similarly, references to all 3GPP technical specifications have been + updated to their 5G (Release 15) versions or otherwise most recent + version when there has not been a 5G-related update. Finally, a number of clarifications have been made, including a summary of where attributes may appear. Appendix B. Changes from RFC 4187 to RFC 5448 The changes to RFC 4187 relate only to the bidding down prevention support defined in Section 4. In particular, this document does not change how the Master Key (MK) is calculated in RFC 4187 (it uses CK and IK, not CK' and IK'); neither is any processing of the AMF bit @@ -1967,20 +1962,23 @@ o The treatment of AT_KDF attribute copy in the EAP-Response/AKA'- Synchronization-Failure message was clarified in Section 3.2. o Updated and added several references o Switched to use of hexadecimal for EAP Type Values for consistency with other documents. o Made editorial clarifications to a number places in the document. + The version -06 included changes to updates of references to newer + versions on IANA considerations guidelines, NAIs, and IKEv2. + Appendix D. Importance of Explicit Negotiation Choosing between the traditional and revised AKA key derivation functions is easy when their use is unambiguously tied to a particular radio access network, e.g., Long Term Evolution (LTE) as defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined by 3GPP2. There is no possibility for interoperability problems if this radio access network is always used in conjunction with new protocols that cannot be mixed with the old ones; clients will always know whether they are connecting to the old or new system.