draft-ietf-emu-rfc5448bis-05.txt   draft-ietf-emu-rfc5448bis-06.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft V. Lehtovirta Internet-Draft V. Lehtovirta
Obsoletes: 5448 (if approved) V. Torvinen Obsoletes: 5448 (if approved) V. Torvinen
Updates: 4187 (if approved) Ericsson Updates: 4187 (if approved) Ericsson
Intended status: Informational P. Eronen Intended status: Informational P. Eronen
Expires: January 9, 2020 Independent Expires: May 21, 2020 Independent
July 8, 2019 November 18, 2019
Improved Extensible Authentication Protocol Method for 3GPP Mobile Improved Extensible Authentication Protocol Method for 3GPP Mobile
Network Authentication and Key Agreement (EAP-AKA') Network Authentication and Key Agreement (EAP-AKA')
draft-ietf-emu-rfc5448bis-05 draft-ietf-emu-rfc5448bis-06
Abstract Abstract
The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the
primary authentication mechanism for devices wishing to access mobile primary authentication mechanism for devices wishing to access mobile
networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible
within the Extensible Authentication Protocol (EAP) framework. RFC within the Extensible Authentication Protocol (EAP) framework. RFC
5448 (EAP-AKA') was an improved version of EAP-AKA. 5448 (EAP-AKA') was an improved version of EAP-AKA.
This memo replaces the specification of EAP-AKA'. EAP-AKA' was This memo replaces the specification of EAP-AKA'. EAP-AKA' was
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 14 skipping to change at page 3, line 14
7.4. Security Properties of Binding Network Names . . . . . . 33 7.4. Security Properties of Binding Network Names . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 35 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 35
8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 35 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 35
8.3. Key Derivation Function Namespace . . . . . . . . . . . . 35 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 35
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . 37 9.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 41 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 41
Appendix B. Changes from RFC 4187 to 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 D. Importance of Explicit Negotiation . . . . . . . . . 43
Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 44 Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 44
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49
1. Introduction 1. Introduction
The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the
primary authentication mechanism for devices wishing to access mobile primary authentication mechanism for devices wishing to access mobile
skipping to change at page 15, line 19 skipping to change at page 15, line 19
3.4. Hash Functions 3.4. Hash Functions
EAP-AKA' uses SHA-256 / HMAC-SHA-256, not SHA-1 / HMAC-SHA-1 (see 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 [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 pseudo-random function (PRF) as well as the AT_MAC and AT_CHECKCODE
attributes. attributes.
3.4.1. PRF' 3.4.1. PRF'
The PRF' construction is the same one IKEv2 uses (see Section 2.13 of 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 and S is a byte string of arbitrary length. PRF' is defined as
follows: follows:
PRF'(K,S) = T1 | T2 | T3 | T4 | ... PRF'(K,S) = T1 | T2 | T3 | T4 | ...
where: where:
T1 = HMAC-SHA-256 (K, S | 0x01) T1 = HMAC-SHA-256 (K, S | 0x01)
T2 = HMAC-SHA-256 (K, T1 | S | 0x02) T2 = HMAC-SHA-256 (K, T1 | S | 0x02)
T3 = HMAC-SHA-256 (K, T2 | S | 0x03) T3 = HMAC-SHA-256 (K, T2 | S | 0x03)
T4 = HMAC-SHA-256 (K, T3 | S | 0x04) T4 = HMAC-SHA-256 (K, T3 | S | 0x04)
skipping to change at page 23, line 46 skipping to change at page 23, line 46
If no identity was communicated inside EAP, then the identity is If no identity was communicated inside EAP, then the identity is
the one communicated outside EAP in link layer messaging. the one communicated outside EAP in link layer messaging.
In this case, the used identity MUST be the identity most recently In this case, the used identity MUST be the identity most recently
communicated by the peer to the network, again regardless of what communicated by the peer to the network, again regardless of what
type of identity it may have been. type of identity it may have been.
5.3.1.1. Format of the SUPI 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 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 28.7.2, with the semantics defined in
[TS-3GPP.23.003] Section 2.2A. Also, in contrast to [RFC5448], in 5G [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 EAP-AKA' does not use the "0" or "6" prefix in front of the entire
IMSI. IMSI.
For instance, if the IMSI is 234150999999999 (MCC = 234, MNC = 15), For instance, if the IMSI is 234150999999999 (MCC = 234, MNC = 15),
the NAI format for the SUPI takes the form: the NAI format for the SUPI takes the form:
skipping to change at page 27, line 49 skipping to change at page 27, line 49
non-trivial information about any of these keys based on the other non-trivial information about any of these keys based on the other
keys. An attacker also cannot calculate the pre-shared secret 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 from IK, CK, IK', CK', K_encr, K_aut, K_re, MSK, or EMSK by any
practically feasible means. practically feasible means.
EAP-AKA' adds an additional layer of key derivation functions EAP-AKA' adds an additional layer of key derivation functions
within itself to protect against the use of compromised keys. within itself to protect against the use of compromised keys.
This is discussed further in Section 7.4. This is discussed further in Section 7.4.
EAP-AKA' uses a pseudo-random function modeled after the one used 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 Key strength
See above. See above.
Dictionary attack resistance Dictionary attack resistance
Under the SHA-256 assumption, the properties of EAP-AKA' are at 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 least as good as those of EAP-AKA in this respect. Refer to
[RFC4187], Section 12 for further details. [RFC4187], Section 12 for further details.
skipping to change at page 37, line 25 skipping to change at page 37, line 25
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
January 2006, <https://www.rfc-editor.org/info/rfc4187>. January 2006, <https://www.rfc-editor.org/info/rfc4187>.
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The [RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542,
Network Access Identifier", RFC 4282, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-
DOI 10.17487/RFC4282, December 2005, <https://www.rfc- editor.org/info/rfc7542>.
editor.org/info/rfc4282>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 38, line 43 skipping to change at page 38, line 43
Authentication Protocol Method for Global System for Authentication Protocol Method for Global System for
Mobile Communications (GSM) Subscriber Identity Modules Mobile Communications (GSM) Subscriber Identity Modules
(EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,
<https://www.rfc-editor.org/info/rfc4186>. <https://www.rfc-editor.org/info/rfc4186>.
[RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity [RFC4284] Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity
Selection Hints for the Extensible Authentication Protocol Selection Hints for the Extensible Authentication Protocol
(EAP)", RFC 4284, DOI 10.17487/RFC4284, January 2006, (EAP)", RFC 4284, DOI 10.17487/RFC4284, January 2006,
<https://www.rfc-editor.org/info/rfc4284>. <https://www.rfc-editor.org/info/rfc4284>.
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2)
Protocol", RFC 4306, DOI 10.17487/RFC4306, December 2005,
<https://www.rfc-editor.org/info/rfc4306>.
[RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari, [RFC5113] Arkko, J., Aboba, B., Korhonen, J., Ed., and F. Bari,
"Network Discovery and Selection Problem", RFC 5113, "Network Discovery and Selection Problem", RFC 5113,
DOI 10.17487/RFC5113, January 2008, <https://www.rfc- DOI 10.17487/RFC5113, January 2008, <https://www.rfc-
editor.org/info/rfc5113>. editor.org/info/rfc5113>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, <https://www.rfc-
editor.org/info/rfc5226>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework", Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008, RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>. <https://www.rfc-editor.org/info/rfc5247>.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')", Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, DOI 10.17487/RFC5448, May 2009, RFC 5448, DOI 10.17487/RFC5448, May 2009,
<https://www.rfc-editor.org/info/rfc5448>. <https://www.rfc-editor.org/info/rfc5448>.
skipping to change at page 39, line 36 skipping to change at page 39, line 26
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, <https://www.rfc- DOI 10.17487/RFC6973, July 2013, <https://www.rfc-
editor.org/info/rfc6973>. editor.org/info/rfc6973>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[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, <https://www.rfc-editor.org/info/rfc7296>.
[I-D.arkko-eap-aka-pfs] [I-D.arkko-eap-aka-pfs]
Arkko, J., Norrman, K., and V. Torvinen, "Perfect-Forward Arkko, J., Norrman, K., and V. Torvinen, "Perfect-Forward
Secrecy for the Extensible Authentication Protocol Method Secrecy for the Extensible Authentication Protocol Method
for Authentication and Key Agreement (EAP-AKA' PFS)", for Authentication and Key Agreement (EAP-AKA' PFS)",
draft-arkko-eap-aka-pfs-04 (work in progress), January draft-arkko-eap-aka-pfs-04 (work in progress), January
2019. 2019.
[Heist2015] [Heist2015]
Scahill, J. and J. Begley, "The great SIM heist", February Scahill, J. and J. Begley, "The great SIM heist", February
2015, in https://firstlook.org/theintercept/2015/02/19/ 2015, in https://firstlook.org/theintercept/2015/02/19/
skipping to change at page 41, line 31 skipping to change at page 41, line 24
definition in RFC 5448, which referenced RFC 4187. See Section 5. definition in RFC 5448, which referenced RFC 4187. See Section 5.
Thirdly, exported parameters for EAP-AKA' have been defined in Thirdly, exported parameters for EAP-AKA' have been defined in
Section 6, as required by [RFC5247], including the definition of Section 6, as required by [RFC5247], including the definition of
those parameters for both full authentication and fast re- those parameters for both full authentication and fast re-
authentication. authentication.
The security, privacy, and pervasive monitoring considerations have The security, privacy, and pervasive monitoring considerations have
been updated or added. See Section 7. been updated or added. See Section 7.
The references to [RFC2119], [RFC5226], [FIPS.180-1] and [FIPS.180-2] The references to [RFC2119], [RFC7542], [RFC7296], [RFC8126],
have been updated to their most recent versions and language in this [FIPS.180-1] and [FIPS.180-2] have been updated to their most recent
document changed accordingly. Similarly, references to all 3GPP versions and language in this document changed accordingly.
technical specifications have been updated to their 5G (Release 15) Similarly, references to all 3GPP technical specifications have been
versions or otherwise most recent version when there has not been a updated to their 5G (Release 15) versions or otherwise most recent
5G-related update. version when there has not been a 5G-related update.
Finally, a number of clarifications have been made, including a Finally, a number of clarifications have been made, including a
summary of where attributes may appear. summary of where attributes may appear.
Appendix B. Changes from RFC 4187 to RFC 5448 Appendix B. Changes from RFC 4187 to RFC 5448
The changes to RFC 4187 relate only to the bidding down prevention The changes to RFC 4187 relate only to the bidding down prevention
support defined in Section 4. In particular, this document does not 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 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 and IK, not CK' and IK'); neither is any processing of the AMF bit
skipping to change at page 43, line 42 skipping to change at page 43, line 33
o The treatment of AT_KDF attribute copy in the EAP-Response/AKA'- o The treatment of AT_KDF attribute copy in the EAP-Response/AKA'-
Synchronization-Failure message was clarified in Section 3.2. Synchronization-Failure message was clarified in Section 3.2.
o Updated and added several references o Updated and added several references
o Switched to use of hexadecimal for EAP Type Values for consistency o Switched to use of hexadecimal for EAP Type Values for consistency
with other documents. with other documents.
o Made editorial clarifications to a number places in the document. 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 Appendix D. Importance of Explicit Negotiation
Choosing between the traditional and revised AKA key derivation Choosing between the traditional and revised AKA key derivation
functions is easy when their use is unambiguously tied to a functions is easy when their use is unambiguously tied to a
particular radio access network, e.g., Long Term Evolution (LTE) as particular radio access network, e.g., Long Term Evolution (LTE) as
defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined
by 3GPP2. There is no possibility for interoperability problems if by 3GPP2. There is no possibility for interoperability problems if
this radio access network is always used in conjunction with new this radio access network is always used in conjunction with new
protocols that cannot be mixed with the old ones; clients will always protocols that cannot be mixed with the old ones; clients will always
know whether they are connecting to the old or new system. know whether they are connecting to the old or new system.
 End of changes. 13 change blocks. 
27 lines changed or deleted 25 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/