draft-ietf-emu-rfc5448bis-08.txt   draft-ietf-emu-rfc5448bis-09.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 Updates: 5448,4187 (if approved) V. Torvinen
Updates: 4187 (if approved) Ericsson Intended status: Informational Ericsson
Intended status: Informational P. Eronen Expires: July 15, 2021 P. Eronen
Expires: May 3, 2021 Independent Independent
October 30, 2020 January 11, 2021
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-08 draft-ietf-emu-rfc5448bis-09
Abstract Abstract
The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the The 3GPP Mobile Network Authentication and Key Agreement (AKA) is an
primary authentication mechanism for devices wishing to access mobile 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 is the most recent specification of EAP-AKA', including,
defined in RFC 5448 and updated EAP-AKA RFC 4187. As such this for instance, details and references about related to operating EAP-
document obsoletes RFC 5448 and updates RFC 4187. AKA' in 5G networks.
EAP-AKA' differs from EAP-AKA by providing a key derivation function EAP-AKA' differs from EAP-AKA by providing a key derivation function
that binds the keys derived within the method to the name of the that binds the keys derived within the method to the name of the
access network. The key derivation function has been defined in the access network. The key derivation function has been defined in the
3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use
in EAP in an interoperable manner. EAP-AKA' also updates the in EAP in an interoperable manner. EAP-AKA' also updates the
algorithm used in hash functions, as it employs SHA-256 / HMAC- algorithm used in hash functions, as it employs SHA-256 / HMAC-
SHA-256 instead of SHA-1 / HMAC-SHA-1 as in EAP-AKA. SHA-256 instead of SHA-1 / HMAC-SHA-1 as in EAP-AKA.
This version of EAP-AKA' specification specifies the protocol This version of EAP-AKA' specification specifies the protocol
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 May 3, 2021. This Internet-Draft will expire on July 15, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. AT_KDF_INPUT . . . . . . . . . . . . . . . . . . . . . . 8 3.1. AT_KDF_INPUT . . . . . . . . . . . . . . . . . . . . . . 8
3.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 13 3.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 13
3.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 15 3.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 15
3.4.1. PRF' . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.1. PRF' . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2. AT_MAC . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.2. AT_MAC . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.3. AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . 15 3.4.3. AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . 15
3.5. Summary of Attributes for EAP-AKA' . . . . . . . . . . . 16 3.5. Summary of Attributes for EAP-AKA' . . . . . . . . . . . 16
4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 18 4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 18
4.1. Summary of Attributes for EAP-AKA . . . . . . . . . . . . 20 4.1. Summary of Attributes for EAP-AKA . . . . . . . . . . . . 20
5. Peer Identities . . . . . . . . . . . . . . . . . . . . . . . 20 5. Peer Identities . . . . . . . . . . . . . . . . . . . . . . . 20
5.1. Username Types in EAP-AKA' Identities . . . . . . . . . . 20 5.1. Username Types in EAP-AKA' Identities . . . . . . . . . . 20
5.2. Generating Pseudonyms and Fast Re-Authentication 5.2. Generating Pseudonyms and Fast Re-Authentication
Identities . . . . . . . . . . . . . . . . . . . . . . . 21 Identities . . . . . . . . . . . . . . . . . . . . . . . 21
5.3. Identifier Usage in 5G . . . . . . . . . . . . . . . . . 22 5.3. Identifier Usage in 5G . . . . . . . . . . . . . . . . . 22
5.3.1. Key Derivation . . . . . . . . . . . . . . . . . . . 23 5.3.1. Key Derivation . . . . . . . . . . . . . . . . . . . 23
5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY
Attribute . . . . . . . . . . . . . . . . . . . . . . 24 Attribute . . . . . . . . . . . . . . . . . . . . . . 24
6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 24 6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 29 7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 30
7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 32 7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 32
7.4. Security Properties of Binding Network Names . . . . . . 32 7.4. Security Properties of Binding Network Names . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 34
8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 34 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 34
8.3. Key Derivation Function Namespace . . . . . . . . . . . . 34 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 34
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.1. Normative References . . . . . . . . . . . . . . . . . . 35 9.1. Normative References . . . . . . . . . . . . . . . . . . 35
9.2. Informative References . . . . . . . . . . . . . . . . . 36 9.2. Informative References . . . . . . . . . . . . . . . . . 37
Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 40 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 40
Appendix B. Changes to RFC 4187 . . . . . . . . . . . . . . . . 40 Appendix B. Changes to RFC 4187 . . . . . . . . . . . . . . . . 41
Appendix C. Changes from Previous Version of This Draft . . . . 41 Appendix C. Changes from Previous Version of This Draft . . . . 41
Appendix D. Importance of Explicit Negotiation . . . . . . . . . 44 Appendix D. Importance of Explicit Negotiation . . . . . . . . . 44
Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 44 Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 45
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
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 an
primary authentication mechanism for devices wishing to access mobile authentication mechanism for devices wishing to access mobile
networks. [RFC4187] (EAP-AKA) made the use of this mechanism networks. [RFC4187] (EAP-AKA) made the use of this mechanism
possible within the Extensible Authentication Protocol (EAP) possible within the Extensible Authentication Protocol (EAP)
framework [RFC3748]. framework [RFC3748].
[RFC5448] (EAP-AKA') was an improved version of EAP-AKA. This memo [RFC5448] (EAP-AKA') was an improved version of EAP-AKA. EAP-AKA'
replaces the specification of EAP-AKA'. EAP-AKA' was defined in RFC was defined in RFC 5448 and updated EAP-AKA RFC 4187.
5448 and updated EAP-AKA RFC 4187. As such this document obsoletes
RFC 5448 and updates RFC 4187. This memo is the most recent specification of EAP-AKA', including,
for instance, details and references about related to operating EAP-
AKA' in 5G networks. RFC 5448 is not obsole, but the most recent and
fully backwards compatible specification is in this memo.
EAP-AKA' is commonly implemented in mobile phones and network EAP-AKA' is commonly implemented in mobile phones and network
equipment. It can be used for authentication to gain network access equipment. It can be used for authentication to gain network access
via Wireless LAN networks and, with 5G, also directly to mobile via Wireless LAN networks and, with 5G, also directly to mobile
networks. networks.
EAP-AKA' differs from EAP-AKA by providing a different key derivation EAP-AKA' differs from EAP-AKA by providing a different key derivation
function. This function binds the keys derived within the method to function. This function binds the keys derived within the method to
the name of the access network. This limits the effects of the name of the access network. This limits the effects of
compromised access network nodes and keys. EAP-AKA' also updates the compromised access network nodes and keys. EAP-AKA' also updates the
skipping to change at page 5, line 32 skipping to change at page 5, line 37
requirements regarding the use of peer identities, including how EAP- requirements regarding the use of peer identities, including how EAP-
AKA' identifiers are used in 5G context. Section 6 specifies what AKA' identifiers are used in 5G context. Section 6 specifies what
parameters EAP-AKA' exports out of the method. Section 7 explains parameters EAP-AKA' exports out of the method. Section 7 explains
the security differences between EAP-AKA and EAP-AKA'. Section 8 the security differences between EAP-AKA and EAP-AKA'. Section 8
describes the IANA considerations and Appendix A and Appendix B describes the IANA considerations and Appendix A and Appendix B
explains what updates to RFC 5448 EAP-AKA' and RFC 4187 EAP-AKA have explains what updates to RFC 5448 EAP-AKA' and RFC 4187 EAP-AKA have
been made in this specification. Appendix D explains some of the been made in this specification. Appendix D explains some of the
design rationale for creating EAP-AKA'. Finally, Appendix E provides design rationale for creating EAP-AKA'. Finally, Appendix E provides
test vectors. test vectors.
Editor's Note: The publication of this RFC depends on its
normative references to 3GPP Technical Specifications reaching a
stable status for Release 15, as indicated by 3GPP. The RFC
Editor should check with the 3GPP liaisons that a stable version
from Release 15 is available and refer to that version. RFC
Editor: Please delete this note upon publication of this
specification as an RFC.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. EAP-AKA' 3. EAP-AKA'
skipping to change at page 8, line 9 skipping to change at page 8, line 9
| +--------------------------------------------------+ | +--------------------------------------------------+
| EAP-Success | | EAP-Success |
|<-------------------------------------------------------| |<-------------------------------------------------------|
Figure 1: EAP-AKA' Authentication Process Figure 1: EAP-AKA' Authentication Process
EAP-AKA' can operate on the same credentials as EAP-AKA and employ EAP-AKA' can operate on the same credentials as EAP-AKA and employ
the same identities. However, EAP-AKA' employs different leading the same identities. However, EAP-AKA' employs different leading
characters than EAP-AKA for the conventions given in Section 4.1.1 of characters than EAP-AKA for the conventions given in Section 4.1.1 of
[RFC4187] for International Mobile Subscriber Identifier (IMSI) based [RFC4187] for International Mobile Subscriber Identifier (IMSI) based
usernames. EAP-AKA' MUST use the leading character "6" (ASCII 36 usernames. For 4G networks, EAP-AKA' MUST use the leading character
hexadecimal) instead of "0" for IMSI-based permanent usernames, or "6" (ASCII 36 hexadecimal) instead of "0" for IMSI-based permanent
5G-specific identifiers in 5G networks. Identifier usage in 5G is usernames. For 5G networks, leading character "6" is not used for
specified in Section 5.3. All other usage and processing of the IMSI-based permanent user names. Identifier usage in 5G is specified
leading characters, usernames, and identities is as defined by EAP- in Section 5.3. All other usage and processing of the leading
AKA [RFC4187]. For instance, the pseudonym and fast re- characters, usernames, and identities is as defined by EAP-AKA
authentication usernames need to be constructed so that the server [RFC4187]. For instance, the pseudonym and fast re-authentication
can recognize them. As an example, a pseudonym could begin with a usernames need to be constructed so that the server can recognize
leading "7" character (ASCII 37 hexadecimal) and a fast re- them. As an example, a pseudonym could begin with a leading "7"
authentication username could begin with "8" (ASCII 38 hexadecimal). character (ASCII 37 hexadecimal) and a fast re-authentication
Note that a server that implements only EAP-AKA may not recognize username could begin with "8" (ASCII 38 hexadecimal). Note that a
these leading characters. According to Section 4.1.4 of [RFC4187], server that implements only EAP-AKA may not recognize these leading
such a server will re-request the identity via the EAP- Request/AKA- characters. According to Section 4.1.4 of [RFC4187], such a server
Identity message, making obvious to the peer that EAP-AKA and will re-request the identity via the EAP- Request/AKA-Identity
associated identity are expected. message, making obvious to the peer that EAP-AKA and associated
identity are expected.
3.1. AT_KDF_INPUT 3.1. AT_KDF_INPUT
The format of the AT_KDF_INPUT attribute is shown below. The format of the AT_KDF_INPUT attribute is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF_INPUT | Length | Actual Network Name Length | | AT_KDF_INPUT | Length | Actual Network Name Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 20 skipping to change at page 9, line 23
This field contains the network name of the access network for This field contains the network name of the access network for
which the authentication is being performed. The name does not which the authentication is being performed. The name does not
include any terminating null characters. Because the length of include any terminating null characters. Because the length of
the entire attribute must be a multiple of 4 bytes, the sender the entire attribute must be a multiple of 4 bytes, the sender
pads the name with 1, 2, or 3 bytes of all zero bits when pads the name with 1, 2, or 3 bytes of all zero bits when
necessary. necessary.
Only the server sends the AT_KDF_INPUT attribute. The value is sent Only the server sends the AT_KDF_INPUT attribute. The value is sent
as specified in [TS-3GPP.24.302] for both non-3GPP access networks as specified in [TS-3GPP.24.302] for both non-3GPP access networks
for 5G access networks. Per [TS-3GPP.33.402], the server always and for 5G access networks. Per [TS-3GPP.33.402], the server always
verifies the authorization of a given access network to use a verifies the authorization of a given access network to use a
particular name before sending it to the peer over EAP-AKA'. The particular name before sending it to the peer over EAP-AKA'. The
value of the AT_KDF_INPUT attribute from the server MUST be non- value of the AT_KDF_INPUT attribute from the server MUST be non-
empty, with a greater than zero length in the Actual Network Name empty, with a greater than zero length in the Actual Network Name
Length field. If AT_KDF_INPUT attribute is empty, the peer behaves Length field. If AT_KDF_INPUT attribute is empty, the peer behaves
as if AUTN had been incorrect and authentication fails. See as if AUTN had been incorrect and authentication fails. See
Section 3 and Figure 3 of [RFC4187] for an overview of how Section 3 and Figure 3 of [RFC4187] for an overview of how
authentication failures are handled. authentication failures are handled.
In addition, the peer MAY check the received value against its own In addition, the peer MAY check the received value against its own
skipping to change at page 13, line 41 skipping to change at page 13, line 41
IK' and CK' are derived as specified in [TS-3GPP.33.402]. The IK' and CK' are derived as specified in [TS-3GPP.33.402]. The
functions that derive IK' and CK' take the following parameters: functions that derive IK' and CK' take the following parameters:
CK and IK produced by the AKA algorithm, and value of the Network CK and IK produced by the AKA algorithm, and value of the Network
Name field comes from the AT_KDF_INPUT attribute (without length Name field comes from the AT_KDF_INPUT attribute (without length
or padding). or padding).
The value "EAP-AKA'" is an eight-characters-long ASCII string. It The value "EAP-AKA'" is an eight-characters-long ASCII string. It
is used as is, without any trailing NUL characters. is used as is, without any trailing NUL characters.
Identity is the peer identity as specified in Section 7 of Identity is the peer identity as specified in Section 7 of
[RFC4187]. [RFC4187], and Section 5.3.2 in this memo for the 5G cases.
When the server creates an AKA challenge and corresponding AUTN, When the server creates an AKA challenge and corresponding AUTN,
CK, CK', IK, and IK' values, it MUST set the Authentication CK, CK', IK, and IK' values, it MUST set the Authentication
Management Field (AMF) separation bit to 1 in the AKA algorithm Management Field (AMF) separation bit to 1 in the AKA algorithm
[TS-3GPP.33.102]. Similarly, the peer MUST check that the AMF [TS-3GPP.33.102]. Similarly, the peer MUST check that the AMF
separation bit is set to 1. If the bit is not set to 1, the peer separation bit is set to 1. If the bit is not set to 1, the peer
behaves as if the AUTN had been incorrect and fails the behaves as if the AUTN had been incorrect and fails the
authentication. authentication.
On fast re-authentication, the following keys are calculated: On fast re-authentication, the following keys are calculated:
skipping to change at page 15, line 15 skipping to change at page 15, line 15
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
[RFC7296]). The function takes two arguments. K is a 256-bit value [RFC7296]; this is the same function as was defined [RFC4306] that
and S is a byte string of arbitrary length. PRF' is defined as RFC 5448 referred to). The function takes two arguments. K is a
follows: 256-bit value and S is a byte string of arbitrary length. PRF' is
defined as 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 20, line 41 skipping to change at page 20, line 41
Temporary Mobile Subscriber Identities (TMSI) that are used on Temporary Mobile Subscriber Identities (TMSI) that are used on
cellular networks. cellular networks.
5.1. Username Types in EAP-AKA' Identities 5.1. Username Types in EAP-AKA' Identities
Section 4.1.1.3 of [RFC4187] specified that there are three types of Section 4.1.1.3 of [RFC4187] specified that there are three types of
usernames: permanent, pseudonym, and fast re-authentication usernames: permanent, pseudonym, and fast re-authentication
usernames. This specification extends this definition as follows. usernames. This specification extends this definition as follows.
There are four types of usernames: There are four types of usernames:
(1) Regular usernames. These are external names given to EAP- (1) Regular usernames. These are external names given to EAP-AKA'
AKA'. The regular usernames are further subdivided into to peers. The regular usernames are further subdivided into to
categories: categories:
(a) Permanent usernames, for instance IMSI-based usernames. (a) Permanent usernames, for instance IMSI-based usernames.
(b) Privacy-friendly temporary usernames, for instance 5G (b) Privacy-friendly temporary usernames, for instance 5G GUTI
privacy identifiers (see Section 5.3.2). or 5G privacy identifiers (see Section 5.3.2).
(2) EAP-AKA' pseudonym usernames. For example, (2) EAP-AKA' pseudonym usernames. For example,
2s7ah6n9q@example.com might be a valid pseudonym identity. In 2s7ah6n9q@example.com might be a valid pseudonym identity. In
this example, 2s7ah6n9q is the pseudonym username. this example, 2s7ah6n9q is the pseudonym username.
(3) EAP-AKA' fast re-authentication usernames. For example, (3) EAP-AKA' fast re-authentication usernames. For example,
43953754@example.com might be a valid fast re-authentication 43953754@example.com might be a valid fast re-authentication
identity and 43953754 the fast re-authentication username. identity and 43953754 the fast re-authentication username.
The permanent, privacy-friendly temporary, and pseudonym usernames The permanent, privacy-friendly temporary, and pseudonym usernames
are only used on full authentication, and fast re-authentication are only used on full authentication, and fast re-authentication
usernames only on fast re-authentication. Unlike permanent usernames usernames only on fast re-authentication. Unlike permanent usernames
and pseudonym usernames, privacy friendly temporary usernames and and pseudonym usernames, privacy friendly temporary usernames and
fast re-authentication usernames are one-time identifiers, which are fast re-authentication usernames are one-time identifiers, which are
not re-used across EAP exchanges. not re-used across EAP exchanges.
5.2. Generating Pseudonyms and Fast Re-Authentication Identities 5.2. Generating Pseudonyms and Fast Re-Authentication Identities
This section provides some additional guidance for implementations
for producing secure pseudonyms and fast re-authentication
identities. It does not impact backwards compatibility, because each
server consumes only the identities it itself generates. However,
adherence to the guidance will provide better security.
As specified by [RFC4187] Section 4.1.1.7, pseudonym usernames and As specified by [RFC4187] Section 4.1.1.7, pseudonym usernames and
fast re-authentication identities are generated by the EAP server, in fast re-authentication identities are generated by the EAP server, in
an implementation-dependent manner. RFC 4187 provides some general an implementation-dependent manner. RFC 4187 provides some general
requirements on how these identities are transported, how they map to requirements on how these identities are transported, how they map to
the NAI syntax, how they are distinguished from each other, and so the NAI syntax, how they are distinguished from each other, and so
on. on.
However, to enhance privacy some additional requirements need to be However, to enhance privacy some additional requirements need to be
applied. applied.
skipping to change at page 22, line 18 skipping to change at page 22, line 25
In EAP-AKA', the peer identity may be communicated to the server in In EAP-AKA', the peer identity may be communicated to the server in
one of three ways: one of three ways:
o As a part of link layer establishment procedures, externally to o As a part of link layer establishment procedures, externally to
EAP. EAP.
o With the EAP-Response/Identity message in the beginning of the EAP o With the EAP-Response/Identity message in the beginning of the EAP
exchange, but before the selection of EAP-AKA'. exchange, but before the selection of EAP-AKA'.
o Transmitted from the peer to the server using EAP-AKA messages o Transmitted from the peer to the server using EAP-AKA' messages
instead of EAP-Response/Identity. In this case, the server instead of EAP-Response/Identity. In this case, the server
includes an identity requesting attribute (AT_ANY_ID_REQ, includes an identity requesting attribute (AT_ANY_ID_REQ,
AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the EAP-Request/AKA- AT_FULLAUTH_ID_REQ or AT_PERMANENT_ID_REQ) in the EAP-Request/AKA-
Identity message; and the peer includes the AT_IDENTITY attribute, Identity message; and the peer includes the AT_IDENTITY attribute,
which contains the peer's identity, in the EAP-Response/AKA- which contains the peer's identity, in the EAP-Response/AKA-
Identity message. Identity message.
The identity carried above may be a permanent identity, privacy The identity carried above may be a permanent identity, privacy
friendly identity, pseudonym identity, or fast re-authentication friendly identity, pseudonym identity, or fast re-authentication
identity as defined in this RFC. identity as defined in this RFC.
skipping to change at page 23, line 20 skipping to change at page 23, line 28
to communicate identities within EAP. to communicate identities within EAP.
The following sections clarify which identifiers are used and how. The following sections clarify which identifiers are used and how.
5.3.1. Key Derivation 5.3.1. Key Derivation
In EAP-AKA', the peer identity is used in the Section 3.3 key In EAP-AKA', the peer identity is used in the Section 3.3 key
derivation formula. derivation formula.
The identity needs to be represented in exact correct format for the The identity needs to be represented in exact correct format for the
key derivation formulala to produce correct results. key derivation formula to produce correct results.
If the AT_KDF_INPUT parameter contains the prefix "5G:", the AT_KDF If the AT_KDF_INPUT parameter contains the prefix "5G:", the AT_KDF
parameter has the value 1, and this authentication is not a fast re- parameter has the value 1, and this authentication is not a fast re-
authentication, then the peer identity used in the key derivation authentication, then the peer identity used in the key derivation
MUST be as specified in Annex F.3 of [TS-3GPP.33.501] and Clause 2.2 MUST be as specified in Annex F.3 of [TS-3GPP.33.501] and Clause 2.2
of [TS-3GPP.23.003]. This is in contrast to [RFC5448], which used of [TS-3GPP.23.003]. This is in contrast to [RFC5448], which used
the identity as communicated in EAP and represented as a NAI. Also, the identity as communicated in EAP and represented as a NAI. Also,
in contrast to [RFC5448], in 5G EAP-AKA' does not use the "0" or "6" in contrast to [RFC5448], in 5G EAP-AKA' does not use the "0" or "6"
prefix in front of the identifier. prefix in front of the identifier.
skipping to change at page 24, line 12 skipping to change at page 24, line 16
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.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute 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 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' core network is also in use. However, in other networks an EAP-AKA'
peer may be connecting to other types of networks and existing peer may be connecting to other types of networks and existing
equipment. equipment.
When the EAP peer is connecting to a 5G access network and uses the When the EAP server is in a 5G network, the 5G procedures for EAP-
5G Non-Access Stratum (NAS) protocol [TS-3GPP.24.501], the EAP server AKA' apply. When EAP server is defined to be in a 5G network is
is in a 5G network. The EAP identity exchanges are generally not specified in [TS-3GPP.33.501].
used in this case, as the identity is already made available on
Note: Currently, the following conditions are specified: when the
EAP peer uses the 5G Non-Access Stratum (NAS) protocol
[TS-3GPP.24.501] or when the EAP peer attaches to a network that
advertises 5G connectivity without NAS [TS-3GPP.23.501]. Possible
future conditions may also be specified by 3GPP.
When the 5G procedures for EAP-AKA' apply, EAP identity exchanges are
generally not used as the identity is already made available on
previous link layer exchanges. previous link layer exchanges.
In this situation, the EAP Identity Response and EAP-AKA' AT_IDENTITY In this situation, the EAP Identity Response and EAP-AKA' AT_IDENTITY
attribute are handled as specified in Annex F.2 of [TS-3GPP.33.501]. attribute are handled as specified in Annex F.2 of [TS-3GPP.33.501].
When used in EAP-AKA', the format of the SUCI MUST be as specified in 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 28.7.3, with the semantics defined in
[TS-3GPP.23.003] Section 2.2B. Also, in contrast to [RFC5448], in 5G [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 EAP-AKA' does not use the "0" or "6" prefix in front of the
identifier. identifier.
skipping to change at page 30, line 26 skipping to change at page 30, line 37
authenticated user's behalf. This particular attack is not different authenticated user's behalf. This particular attack is not different
from any on-path entity (such as a router) pretending to send from any on-path entity (such as a router) pretending to send
traffic, but the general issue of insider attacks can be a problem, traffic, but the general issue of insider attacks can be a problem,
particularly in a large group of collaborating operators. particularly in a large group of collaborating operators.
Another class of attacks is the use of tunneling of traffic from one 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 place to another, e.g., as done by Zhang and Fang in [ZF2005] to
leverage security policy differences between different operator leverage security policy differences between different operator
networks, for instance. To gain something in such an attack, the networks, for instance. To gain something in such an attack, the
attacker needs to trick the user into believing it is in another attacker needs to trick the user into believing it is in another
location where, for instance, it is not required to encrypt all location. If policies between different locations differ, for
payload traffic after encryption. As an authentication mechanism, instance, in some location it is not required to encrypt all payload
EAP-AKA' is not directly affected by most such attacks. EAP-AKA' traffic, the attacker may trick the user into opening a
network name binding can also help alleviate some of the attacks. In vulnerability. As an authentication mechanism, EAP-AKA' is not
any case, it is recommended that EAP-AKA' configuration not be directly affected by most such attacks. EAP-AKA' network name
dependent on the location of where a request comes from, unless the binding can also help alleviate some of the attacks. In any case, it
location information can be cryptographically confirmed, e.g., with is recommended that EAP-AKA' configuration not be dependent on the
the network name binding. location of where a request comes from, unless the location
information can be cryptographically confirmed, e.g., with the
network name binding.
Zhang and Fang also looked at Denial-of-Service attacks [ZF2005]. A Zhang and Fang also looked at Denial-of-Service attacks [ZF2005]. A
serving network may request large numbers of authentication runs for serving network may request large numbers of authentication runs for
a particular subscriber from a home network. While resynchronization a particular subscriber from a home network. While resynchronization
process can help recover from this, eventually it is possible to process can help recover from this, eventually it is possible to
exhaust the sequence number space and render the subscriber's card exhaust the sequence number space and render the subscriber's card
unusable. This attack is possible for both native AKA and EAP-AKA'. unusable. This attack is possible for both native AKA and EAP-AKA'.
However, it requires the collaboration of a serving network in an However, it requires the collaboration of a serving network in an
attack. It is recommended that EAP-AKA' implementations provide attack. It is recommended that EAP-AKA' implementations provide
means to track, detect, and limit excessive authentication attempts means to track, detect, and limit excessive authentication attempts
skipping to change at page 35, line 4 skipping to change at page 35, line 12
namespace are given below; new values can be created through the namespace are given below; new values can be created through the
Specification Required policy [RFC8126]. Specification Required policy [RFC8126].
Value Description Reference Value Description Reference
--------- ---------------------- ------------------------------- --------- ---------------------- -------------------------------
0 Reserved [RFC Editor: Refer to this RFC] 0 Reserved [RFC Editor: Refer to this RFC]
1 EAP-AKA' with CK'/IK' [RFC Editor: Refer to this RFC] 1 EAP-AKA' with CK'/IK' [RFC Editor: Refer to this RFC]
2-65535 Unassigned 2-65535 Unassigned
9. References 9. References
9.1. Normative References 9.1. Normative References
[TS-3GPP.23.003] [TS-3GPP.23.003]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; Numbering, Specification Group Core Network and Terminals; Numbering,
addressing and identification (Release 15)", addressing and identification (Release 16)",
3GPP Technical Specification 23.003 version 15.8.0, 3GPP Technical Specification 23.003 version 16.5.0,
September 2019. December 2020.
[TS-3GPP.23.501] [TS-3GPP.23.501]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G Specification Group Services and System Aspects; 3G
Security; Security architecture and procedures for 5G Security; Security architecture and procedures for 5G
System; (Release 15)", 3GPP Technical Specification 23.501 System; (Release 16)", 3GPP Technical Specification 23.501
version 15.8.0, December 2019. version 16.7.0, December 2020.
[TS-3GPP.24.302] [TS-3GPP.24.302]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; Access to Specification Group Core Network and Terminals; Access to
the 3GPP Evolved Packet Core (EPC) via non-3GPP access the 3GPP Evolved Packet Core (EPC) via non-3GPP access
networks; Stage 3; (Release 15)", 3GPP Technical networks; Stage 3; (Release 16)", 3GPP Technical
Specification 24.302 version 15.7.0, June 2019. Specification 24.302 version 16.4.0, July 2020.
[TS-3GPP.24.501] [TS-3GPP.24.501]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; Access to Specification Group Core Network and Terminals; Access to
the 3GPP Evolved Packet Core (EPC) via non-3GPP access the 3GPP Evolved Packet Core (EPC) via non-3GPP access
networks; Stage 3; (Release 15)", 3GPP Draft Technical networks; Stage 3; (Release 16)", 3GPP Draft Technical
Specification 24.501 version 15.6.0, December 2019. Specification 24.501 version 16.7.0, December 2020.
[TS-3GPP.33.102] [TS-3GPP.33.102]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G Specification Group Services and System Aspects; 3G
Security; Security architecture (Release 15)", Security; Security architecture (Release 16)",
3GPP Technical Specification 33.102 version 15.1.0, 3GPP Technical Specification 33.102 version 16.0.0, July
December 2018. 2020.
[TS-3GPP.33.402] [TS-3GPP.33.402]
3GPP, "3GPP System Architecture Evolution (SAE); Security 3GPP, "3GPP System Architecture Evolution (SAE); Security
aspects of non-3GPP accesses (Release 15)", 3GPP Technical aspects of non-3GPP accesses (Release 16)", 3GPP Technical
Specification 33.402 version 15.1.0, June 2018. Specification 33.402 version 16.0.0, July 2020.
[TS-3GPP.33.501] [TS-3GPP.33.501]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G Specification Group Services and System Aspects; 3G
Security; Security architecture and procedures for 5G Security; Security architecture and procedures for 5G
System (Release 15)", 3GPP Technical Specification 33.501 System (Release 16)", 3GPP Technical Specification 33.501
version 15.7.0, December 2019. version 16.5.0, December 2020.
[FIPS.180-4] [FIPS.180-4]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-4, August 2015, Hash Standard", FIPS PUB 180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>. NIST.FIPS.180-4.pdf>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, <https://www.rfc- DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
skipping to change at page 38, line 5 skipping to change at page 38, line 10
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>.
[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>.
skipping to change at page 38, line 45 skipping to change at page 39, line 9
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[I-D.ietf-emu-aka-pfs] [I-D.ietf-emu-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-ietf-emu-aka-pfs-04 (work in progress), May 2020. draft-ietf-emu-aka-pfs-05 (work in progress), October
2020.
[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/
great-sim-heist/ . great-sim-heist/ .
[MT2012] Mjolsnes, S. and J-K. Tsay, "A vulnerability in the UMTS [MT2012] Mjolsnes, S. and J-K. Tsay, "A vulnerability in the UMTS
and LTE authentication and key agreement protocols", and LTE authentication and key agreement protocols",
October 2012, in Proceedings of the 6th international October 2012, in Proceedings of the 6th international
conference on Mathematical Methods, Models and conference on Mathematical Methods, Models and
skipping to change at page 40, line 33 skipping to change at page 40, line 45
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], [RFC7542], [RFC7296], [RFC8126], The references to [RFC2119], [RFC7542], [RFC7296], [RFC8126],
[FIPS.180-1] and [FIPS.180-2] have been updated to their most recent [FIPS.180-1] and [FIPS.180-2] have been updated to their most recent
versions and language in this document changed accordingly. versions and language in this document changed accordingly. However,
this is merely an update to a newer RFC but the actual protocol
functions are the same as defined in the earlier RFCs.
Similarly, references to all 3GPP technical specifications have been Similarly, references to all 3GPP technical specifications have been
updated to their 5G (Release 15) versions or otherwise most recent updated to their 5G (Release 16) versions or otherwise most recent
version when there has not been a 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 to RFC 4187 Appendix B. Changes to RFC 4187
In addition to specifying EAP-AKA', this document mandates also a In addition to specifying EAP-AKA', this document mandates also a
change to another EAP method, EAP-AKA that was defined in RFC 4187. change to another EAP method, EAP-AKA that was defined in RFC 4187.
This change was mandated already in RFC 5448 but repeated here to This change was mandated already in RFC 5448 but repeated here to
skipping to change at page 44, line 5 skipping to change at page 44, line 18
individual part of the specification is stated in only one place. individual part of the specification is stated in only one place.
This has lead to this draft referring to bigger parts of the 3GPP This has lead to this draft referring to bigger parts of the 3GPP
specification, instead of spelling out the details within this specification, instead of spelling out the details within this
document. Note that this alignment change is a proposal at this document. Note that this alignment change is a proposal at this
stage, and will be discussed in the upcoming 3GPP meeting. stage, and will be discussed in the upcoming 3GPP meeting.
o Relaxed the language on using only SUCI in 5G. While that is the o Relaxed the language on using only SUCI in 5G. While that is the
mode of operation expected to be used, [TS-3GPP.33.501] does not mode of operation expected to be used, [TS-3GPP.33.501] does not
prohibit other types of identifiers. prohibit other types of identifiers.
The version -09 includes the following changes:
o Updated the language relating to obsoleting/updating RFC 5448;
there was an interest to ensure that RFC 5448 stays a valid
specification also in the future, owing to existing
implementations.
o Clarified that the leading digit "6" is not used in 5G networks.
o Updated the language relating to when 5G-specific procedures are
in effect, to support new use cases 3GPP has defined.
o Updated the reference in Section 3.3, as the identities are
different in the 5G case.
o Clarified that the use of the newer reference to IKEv2 RFC did not
change the actual PRF' function from RFC 5448.
o Clarified that the Section 5.2 text does not impact backwards
compatibility.
o Corrected the characterization of the attack from [ZF2005].
o Mentioned 5G GUTIs as one possible 5G-identifier in Section 5.1.
o Updated the references to Release 16. These specifications are
stable in 3GPP.
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. 41 change blocks. 
95 lines changed or deleted 145 lines changed or added

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