draft-ietf-emu-rfc5448bis-03.txt   draft-ietf-emu-rfc5448bis-04.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: April 22, 2019 Nokia Expires: July 21, 2019 Independent
October 19, 2018 January 17, 2019
Improved Extensible Authentication Protocol Method for 3rd Generation Improved Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA') Authentication and Key Agreement (EAP-AKA')
draft-ietf-emu-rfc5448bis-03 draft-ietf-emu-rfc5448bis-04
Abstract Abstract
This specification defines an EAP method, EAP-AKA', a small revision The 3rd Generation Authentication and Key Agreement (AKA) is the
of the EAP-AKA method. EAP-AKA' provides a key derivation function primary authentication mechanism for devices wishing to access mobile
that binds the keys derived within the method to the name of the networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible
access network. The key derivation mechanism has been defined in the within the Extensible Authentication Protocol (EAP) framework. RFC
3rd Generation Partnership Project (3GPP). This specification allows 5448 (EAP-AKA') was an improved version of EAP-AKA.
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 This memo is an update of the specification for EAP-AKA'. This
down attacks from EAP-AKA'. version obsoletes RFC 5448.
This version of the EAP-AKA' specification provides updates to EAP-AKA' differs from EAP-AKA by providing a key derivation function
specify the protocol behaviour for 5G deployments as well. that binds the keys derived within the method to the name of the
access network. The key derivation function has been defined in the
3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use
in EAP in an interoperable manner. EAP-AKA' is also an algorithm
update, as it employs SHA-256 instead of SHA-1 as in EAP-AKA.
This version of EAP-AKA' specification specifies the protocol
behaviour for 5G deployments as well.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 July 21, 2019.
This Internet-Draft will expire on April 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
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' . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. AT_KDF_INPUT . . . . . . . . . . . . . . . . . . . . . . 8 3.1. AT_KDF_INPUT . . . . . . . . . . . . . . . . . . . . . . 8
3.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Key Generation . . . . . . . . . . . . . . . . . . . . . 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
4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 16 4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 16
5. Peer Identities . . . . . . . . . . . . . . . . . . . . . . . 17 5. Peer Identities . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Username Types in EAP-AKA' Identities . . . . . . . . . . 18 5.1. Username Types in EAP-AKA' Identities . . . . . . . . . . 18
5.2. Generating Pseudonyms and Fast Re-Authentication 5.2. Generating Pseudonyms and Fast Re-Authentication
Identities . . . . . . . . . . . . . . . . . . . . . . . 18 Identities . . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Identifier Usage in 5G . . . . . . . . . . . . . . . . . 19 5.3. Identifier Usage in 5G . . . . . . . . . . . . . . . . . 19
5.3.1. Key Derivation . . . . . . . . . . . . . . . . . . . 20 5.3.1. Key Derivation . . . . . . . . . . . . . . . . . . . 20
5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY
Attribute . . . . . . . . . . . . . . . . . . . . . . 21 Attribute . . . . . . . . . . . . . . . . . . . . . . 21
6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 23 6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 28 7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 28
7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29 7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 30
7.4. Security Properties of Binding Network Names . . . . . . 30 7.4. Security Properties of Binding Network Names . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 31 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 32
8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 31 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 32
8.3. Key Derivation Function Namespace . . . . . . . . . . . . 32 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 32 9.1. Normative References . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 36 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 37
Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 37 Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 38
Appendix C. Changes from Previous Version of This Draft . . . . 37 Appendix C. Changes from Previous Version of This Draft . . . . 38
Appendix D. Importance of Explicit Negotiation . . . . . . . . . 38 Appendix D. Importance of Explicit Negotiation . . . . . . . . . 39
Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 39 Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 40
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 43 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 44
Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . 44 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
1. Introduction 1. Introduction
This specification defines an Extensible Authentication Protocol The 3rd Generation Authentication and Key Agreement (AKA) is the
(EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA primary authentication mechanism for devices wishing to access mobile
method originally defined in [RFC4187]. EAP-AKA' provides a new key networks. [RFC4187] (EAP-AKA) made the use of this mechanism
derivation function, specified in [TS-3GPP.33.402]. This function possible within the Extensible Authentication Protocol (EAP)
binds the keys derived within the method to the name of the access framework [RFC3748].
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 [RFC5448] (EAP-AKA') was an improved version of EAP-AKA. This memo
mechanism, some based on native encapsulation of AKA over 3GPP radio is an update of the specification for EAP-AKA'. This version
access networks and others based on the use of EAP. obsoletes RFC 5448.
For making the new key derivation mechanisms usable in EAP-AKA, EAP-AKA' is commonly implemented in smart phones and network
additional protocol mechanisms are necessary. Given that RFC 4187 equipment. It can be used for authentication to gain network access
calls for the use of CK (the encryption key) and IK (the integrity via Wireless LAN networks and, with 5G, also directly to mobile
key) from AKA, existing implementations continue to use these. Any networks.
change of the key derivation must be unambiguous to both sides in the
protocol. That is, it must not be possible to accidentally connect
old equipment to new equipment and get the key derivation wrong or
attempt to use wrong keys without getting a proper error message.
The change must also be secure against bidding down attacks that
attempt to force the participants to use the least secure mechanism.
This specification therefore introduces a variant of the EAP-AKA EAP-AKA' differs from EAP-AKA by providing a different key derivation
method, called EAP-AKA'. This method can employ the derived keys CK' function. This function binds the keys derived within the method to
and IK' from the 3GPP specification and updates the used hash the name of the access network. This limits the effects of
function to SHA-256 [FIPS.180-4]. But it is otherwise equivalent to compromised access network nodes and keys. EAP-AKA' is also an
RFC 4187. Given that a different EAP method type value is used for algorithm update for the used hash functions.
The EAP-AKA' method employs the derived keys CK' and IK' from the
3GPP specification [TS-3GPP.33.402] and updates the used hash
function to SHA-256 [FIPS.180-4]. Otherwise, EAP-AKA' is equivalent
to EAP-AKA. Given that a different EAP method type value is used for
EAP-AKA and EAP-AKA', a mutually supported method may be negotiated EAP-AKA and EAP-AKA', a mutually supported method may be negotiated
using the standard mechanisms in EAP [RFC3748]. using the standard mechanisms in EAP [RFC3748].
Note: Appendix D explains why it is important to be explicit about Note that any change of the key derivation must be unambiguous to
the change of semantics for the keys, and why other approaches both sides in the protocol. That is, it must not be possible to
would lead to severe interoperability problems. accidentally connect old equipment to new equipment and get the
key derivation wrong or attempt to use wrong keys without getting
a proper error message. See Appendix D for further information.
This version of the EAP-AKA' specification obsoletes RFC 5448. The Note also that choices in authentication protocols should be
changes are as follows: secure against bidding down attacks that attempt to force the
participants to use the least secure function. See Section 4 for
further information.
The changes from RFC 5448 to this specification are as follows:
o Update the reference on how the Network Name field is constructed o Update the reference on how the Network Name field is constructed
in the protocol. The update ensures that EAP-AKA' is compatible in the protocol. The update ensures that EAP-AKA' is compatible
with 5G deployments. RFC 5448 referred to the Release 8 version with 5G deployments. RFC 5448 referred to the Release 8 version
of [TS-3GPP.24.302] and this update points to the first 5G of [TS-3GPP.24.302] and this update points to the first 5G
version, Release 15. version, Release 15.
o Specify how EAP and EAP-AKA' use identifiers in 5G. Additional o Specify how EAP and EAP-AKA' use identifiers in 5G. Additional
identifiers are introduced in 5G, and for interoperability, it is identifiers are introduced in 5G, and for interoperability, it is
necessary that the right identifiers are used as inputs in the key necessary that the right identifiers are used as inputs in the key
generation. In addition, for identity privacy it is important derivation. In addition, for identity privacy it is important
that when privacy-friendly identifiers in 5G are used, no that when privacy-friendly identifiers in 5G are used, no
trackable, permanent identifiers are passed in EAP-AKA' either. trackable, permanent identifiers are passed in EAP-AKA' either.
o Specify session identifiers and other exported parameters, as o Specify session identifiers and other exported parameters, as
those were not specified in [RFC5448] despite requirements set those were not specified in [RFC5448] despite requirements set
forward in [RFC5247] to do so. Also, while [RFC5247] specified forward in [RFC5247] to do so. Also, while [RFC5247] specified
session identifiers for EAP-AKA, it only did so for the full session identifiers for EAP-AKA, it only did so for the full
authentication case, not for the case of fast re-authentication. authentication case, not for the case of fast re-authentication.
o Update the requirements on generating pseudonym usernames and fast o Update the requirements on generating pseudonym usernames and fast
skipping to change at page 4, line 44 skipping to change at page 4, line 48
related to EAP-AKA'. related to EAP-AKA'.
Some of the updates are small. For instance, for the first update, Some of the updates are small. For instance, for the first update,
the reference update does not change the 3GPP specification number, the reference update does not change the 3GPP specification number,
only the version. But this reference is crucial in correct only the version. But this reference is crucial in correct
calculation of the keys resulting from running the EAP-AKA' method, calculation of the keys resulting from running the EAP-AKA' method,
so an update of the RFC with the newest version pointer may be so an update of the RFC with the newest version pointer may be
warranted. warranted.
Note: This specification refers only to the 5G specifications. Note: This specification refers only to the 5G specifications.
Any further update that affects, for instance, key generation is Any further update that affects, for instance, key derivation is
something that EAP-AKA' implementations should take into account. something that EAP-AKA' implementations should take into account.
Upon such updates there will be a need to both update the Upon such updates there will be a need to both update the
specification and the implementations. specification and the implementations.
It is an explicit non-goal of this draft to include any other It is an explicit non-goal of this draft to include any other
technical modifications, addition of new features or other changes. technical modifications, addition of new features or other changes.
The EAP-AKA' base protocol is stable and needs to stay that way. If The EAP-AKA' base protocol is stable and needs to stay that way. If
there are any extensions or variants, those need to be proposed as there are any extensions or variants, those need to be proposed as
standalone extensions or even as different authentication methods. standalone extensions or even as different authentication methods.
skipping to change at page 5, line 37 skipping to change at page 5, line 41
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'
EAP-AKA' is a new EAP method that follows the EAP-AKA specification EAP-AKA' is an EAP method that follows the EAP-AKA specification
[RFC4187] in all respects except the following: [RFC4187] in all respects except the following:
o It uses the Type code 50, not 23 (which is used by EAP-AKA). o It uses the Type code 50, not 23 (which is used by EAP-AKA).
o It carries the AT_KDF_INPUT attribute, as defined in Section 3.1, o It carries the AT_KDF_INPUT attribute, as defined in Section 3.1,
to ensure that both the peer and server know the name of the to ensure that both the peer and server know the name of the
access network. access network.
o It supports key derivation function negotiation via the AT_KDF o It supports key derivation function negotiation via the AT_KDF
attribute (Section 3.2) to allow for future extensions. attribute (Section 3.2) to allow for future extensions.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
[RFC4187]. This happens after AT_KDF negotiation has already [RFC4187]. This happens after AT_KDF negotiation has already
completed. An AKA'-Synchronization-Failure message is sent as a completed. An AKA'-Synchronization-Failure message is sent as a
response to the newly received EAP-Request/AKA'-Challenge (the last response to the newly received EAP-Request/AKA'-Challenge (the last
message of the AT_KDF negotiation). The AKA'-Synchronization-Failure message of the AT_KDF negotiation). The AKA'-Synchronization-Failure
message MUST contain the AUTS parameter as specified in [RFC4187] and message MUST contain the AUTS parameter as specified in [RFC4187] and
a copy the AT_KDF attributes as they appeared in the last message of a copy the AT_KDF attributes as they appeared in the last message of
the AT_KDF negotiation. If the AT_KDF attributes are found to differ the AT_KDF negotiation. If the AT_KDF attributes are found to differ
from their earlier values, the peer and server MUST behave as if from their earlier values, the peer and server MUST behave as if
AT_MAC had been incorrect and fail the authentication. AT_MAC had been incorrect and fail the authentication.
3.3. Key Generation 3.3. Key Derivation
Both the peer and server MUST derive the keys as follows. Both the peer and server MUST derive the keys as follows.
AT_KDF set to 1 AT_KDF parameter has the value 1
In this case, MK is derived and used as follows: In this case, MK is derived and used as follows:
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
K_encr = MK[0..127] K_encr = MK[0..127]
K_aut = MK[128..383] K_aut = MK[128..383]
K_re = MK[384..639] K_re = MK[384..639]
MSK = MK[640..1151] MSK = MK[640..1151]
EMSK = MK[1152..1663] EMSK = MK[1152..1663]
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, not SHA-1 (see [FIPS.180-4]) as in EAP-AKA. EAP-AKA' uses SHA-256, not SHA-1 (see [FIPS.180-4]) as in EAP-AKA.
This requires a change to the pseudo-random function (PRF) as well as This requires a change to the pseudo-random function (PRF) as well as
the AT_MAC and AT_CHECKCODE attributes. the AT_MAC and AT_CHECKCODE 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 [RFC4306]). The function takes two arguments. K is a 256-bit value
and S is an octet string of arbitrary length. PRF' is defined as and S is an 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 17, line 46 skipping to change at page 17, line 46
EAP-AKA' peer identities are as specified in [RFC4187] Section 4.1, EAP-AKA' peer identities are as specified in [RFC4187] Section 4.1,
with the addition of some requirements specified in this section. with the addition of some requirements specified in this section.
EAP-AKA' includes optional identity privacy support that can be used EAP-AKA' includes optional identity privacy support that can be used
to hide the cleartext permanent identity and thereby make the to hide the cleartext permanent identity and thereby make the
subscriber's EAP exchanges untraceable to eavesdroppers. EAP-AKA' subscriber's EAP exchanges untraceable to eavesdroppers. EAP-AKA'
can also use the privacy friendly identifiers specified for 5G can also use the privacy friendly identifiers specified for 5G
networks. networks.
The permanent identity is usually based on the IMSI, which may The permanent identity is usually based on the IMSI. Exposing the
further help the tracking, because the same identifier may be used in IMSI is undesirable, because as a permanent identity it is easily
other contexts as well. Identity privacy is based on temporary trackable. In addition, since IMSIs may be used in other contexts as
usernames, or pseudonym usernames. These are similar to but separate well, there would be additional opportunities for such tracking.
from the Temporary Mobile Subscriber Identities (TMSI) that are used
on cellular networks. In EAP-AKA', identity privacy is based on temporary usernames, or
pseudonym usernames. These are similar to but separate from the
Temporary Mobile Subscriber Identities (TMSI) that are used on
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'. The regular usernames are further subdivided into to AKA'. The regular usernames are further subdivided into to
skipping to change at page 19, line 5 skipping to change at page 19, line 11
However, to ensure privacy some additional requirements need to be However, to ensure privacy some additional requirements need to be
applied. applied.
The pseudonym usernames and fast re-authentication identities MUST be The pseudonym usernames and fast re-authentication identities MUST be
generated in a cryptographically secure way so that that it is generated in a cryptographically secure way so that that it is
computationally infeasible for at attacker to differentiate two computationally infeasible for at attacker to differentiate two
identities belonging to the same user from two identities belonging identities belonging to the same user from two identities belonging
to different users. This can be achieved, for instance, by using to different users. This can be achieved, for instance, by using
random or pseudo-random identifiers such as random byte strings or random or pseudo-random identifiers such as random byte strings or
ciphertexts. ciphertexts. See also [RFC4086] for guidance on random number
generation.
Note that the pseudonym and fast re-authentication usernames also Note that the pseudonym and fast re-authentication usernames also
MUST NOT include substrings that can be used to relate the username MUST NOT include substrings that can be used to relate the username
to a particular entity or a particular permanent identity. For to a particular entity or a particular permanent identity. For
instance, the usernames can not include any subscriber-identifying instance, the usernames can not include any subscriber-identifying
part of an IMSI or other permanent identifier. Similarly, no part of part of an IMSI or other permanent identifier. Similarly, no part of
the username can be formed by a fixed mapping that stays the same the username can be formed by a fixed mapping that stays the same
across multiple different pseudonyms or fast re-authentication across multiple different pseudonyms or fast re-authentication
identities for the same subscriber. identities for the same subscriber.
When the identifier used to identify a subscriber in an EAP-AKA' When the identifier used to identify a subscriber in an EAP-AKA'
authentication exchange is a privacy-friendly identifier that is used authentication exchange is a privacy-friendly identifier that is used
only once, the EAP-AKA' peer MUST NOT use a pseudonym provided in only once, the EAP-AKA' peer MUST NOT use a pseudonym provided in
that authentication exchange in subsequent exchanges more than once. that authentication exchange in subsequent exchanges more than once.
To ensure that this does not happen, EAP-AKA' server MAY decline to To ensure that this does not happen, EAP-AKA' server MAY decline to
provide a pseudonym in such authentication exchanges. An important provide a pseudonym in such authentication exchanges. An important
case where such privacy-friendly identifiers are used is in 5G case where such privacy-friendly identifiers are used is in 5G
networks (see Section 5.3) networks (see Section 5.3).
5.3. Identifier Usage in 5G 5.3. Identifier Usage in 5G
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
skipping to change at page 20, line 13 skipping to change at page 20, line 20
for interoperability that the right type of identifier is used. for interoperability that the right type of identifier is used.
5G defines the SUbscription Permanent Identifier (SUPI) and 5G defines the SUbscription Permanent Identifier (SUPI) and
SUbscription Concealed Identifier (SUCI) [TS-3GPP.23.501] SUbscription Concealed Identifier (SUCI) [TS-3GPP.23.501]
[TS-3GPP.33.501] [TS-3GPP.23.003]. SUPI is globally unique and [TS-3GPP.33.501] [TS-3GPP.23.003]. SUPI is globally unique and
allocated to each subscriber. However, it is only used internally in allocated to each subscriber. However, it is only used internally in
the 5G network, and is privacy sensitive. The SUCI is a privacy the 5G network, and is privacy sensitive. The SUCI is a privacy
preserving identifier containing the concealed SUPI, using public key preserving identifier containing the concealed SUPI, using public key
cryptography to encrypt the SUPI. cryptography to encrypt the SUPI.
Given the choice between these two types of identifiers, two areas Given the choice between these two types of identifiers, EAP-AKA'
need further specification in EAP-AKA' to ensure that different ensures interoperability as follows:
implementations understand each other and stay interoperable:
o Where identifiers are used within EAP-AKA' -- such as key o Where identifiers are used within EAP-AKA' -- such as key
derivation -- specify what values exactly should be used, to avoid derivation -- specify what values exactly should be used, to avoid
ambiguity. ambiguity (see Section 5.3.1).
o Where identifiers are carried within EAP-AKA' packets -- such as o Where identifiers are carried within EAP-AKA' packets -- such as
in the AT_IDENTITY attribute -- specify which identifiers should in the AT_IDENTITY attribute -- specify which identifiers should
be filled in. be filled in (see Section 5.3.2).
In 5G, the normal mode of operation is that identifiers are only In 5G, the normal mode of operation is that identifiers are only
transmitted outside EAP. However, in a system involving terminals transmitted outside EAP. However, in a system involving terminals
from many generations and several connectivity options via 5G and from many generations and several connectivity options via 5G and
other mechanisms, implementations and the EAP-AKA' specification need other mechanisms, implementations and the EAP-AKA' specification need
to prepare for many different situations, including sometimes having to prepare for many different situations, including sometimes having
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.
skipping to change at page 21, line 24 skipping to change at page 21, line 30
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 [RFC4282].
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] Sections 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.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 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:
234150999999999@nai.5gc.mnc015.mcc234.3gppnetwork.org 234150999999999@nai.5gc.mnc015.mcc234.3gppnetwork.org
5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute
skipping to change at page 22, line 4 skipping to change at page 22, line 11
is in a 5G network. The EAP identity exchanges are generally not is in a 5G network. The EAP identity exchanges are generally not
used in this case, as the identity is already made available on used in this case, as the identity is already made available on
previous link layer exchanges. previous link layer exchanges.
In this situation, the EAP server SHOULD NOT request an additional In this situation, the EAP server SHOULD NOT request an additional
identity from the peer. If the peer for some reason receives EAP- identity from the peer. If the peer for some reason receives EAP-
Request/Identity or EAP-Request/AKA-Identity messages, the peer Request/Identity or EAP-Request/AKA-Identity messages, the peer
should behave as follows. should behave as follows.
Receive EAP-Request/Identity Receive EAP-Request/Identity
In this case, the peer SHOULD respond with a EAP-Response/Identity In this case, the peer SHOULD respond with a EAP-Response/Identity
containing the privacy-friendly 5G identifier, the SUCI. The SUCI containing the privacy-friendly 5G identifier, the SUCI. The SUCI
SHOULD be represented as specified in Section 5.3.2.1. SHOULD be represented as specified in Section 5.3.2.1.
EAP-Request/AKA-Identity with AT_PERMANENT_REQ EAP-Request/AKA-Identity with AT_PERMANENT_REQ
For privacy reasons, the peer should follow a "conservative" For privacy reasons, the peer should follow a "conservative"
policy and terminate the authentication exchange rather than risk policy and terminate the authentication exchange rather than risk
revaling its permanent identity. revealing its permanent identity.
The peer SHOULD respond with EAP-Response/AKA-Client-Error with The peer SHOULD respond with EAP-Response/AKA-Client-Error with
the client error code 0, "unable to process packet". the client error code 0, "unable to process packet".
EAP-Request/AKA-Identity with AT_FULLAUTH_REQ EAP-Request/AKA-Identity with AT_FULLAUTH_REQ
In this case, the peer SHOULD respond with a EAP-Response/AKA- In this case, the peer SHOULD respond with a EAP-Response/AKA-
Identity containing the SUCI. The SUCI SHOULD be represented as Identity containing the SUCI. The SUCI SHOULD be represented as
specified in Section 5.3.2.1. specified in Section 5.3.2.1.
skipping to change at page 23, line 19 skipping to change at page 23, line 26
For the Profile <A> protection scheme: For the Profile <A> protection scheme:
type0.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key>. type0.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key>.
cip<encryption of 0999999999>.mac<MAC tag value>@nai.5gc. cip<encryption of 0999999999>.mac<MAC tag value>@nai.5gc.
mnc015.mcc234.3gppnetwork.org mnc015.mcc234.3gppnetwork.org
6. Exported Parameters 6. Exported Parameters
The EAP-AKA' Session-Id is the concatenation of the EAP Type Code 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 (50, one byte) 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, followed by the contents of the AUTN field in the AT_AUTN
attribute: attribute:
Session-Id = 50 || RAND || AUTN Session-Id = 50 || RAND || AUTN
When using fast re-authentication, the EAP-AKA' Session-Id is the When using fast re-authentication, the EAP-AKA' Session-Id is the
concatenation of the EAP Type Code (50) with the contents of the concatenation of the EAP Type Code (50) with the contents of the
NONCE_S field from the AT_NONCE_S attribute, followed by the contents NONCE_S field from the AT_NONCE_S attribute, followed by the contents
of the MAC field from the AT_MAC attribute from EAP-Request/AKA- of the MAC field from the AT_MAC attribute from EAP-Request/AKA-
Reauthentication: Reauthentication:
Session-Id = 50 || NONCE_S || MAC Session-Id = 50 || NONCE_S || MAC
The Peer-Id is the contents of the Identity field from the The Peer-Id is the contents of the Identity field from the
AT_IDENTITY attribute, using only the Actual Identity Length octets AT_IDENTITY attribute, using only the Actual Identity Length bytes
from the beginning. Note that the contents are used as they are from the beginning. Note that the contents are used as they are
transmitted, regardless of whether the transmitted identity was a transmitted, regardless of whether the transmitted identity was a
permanent, pseudonym, or fast EAP re-authentication identity. If no permanent, pseudonym, or fast EAP re-authentication identity. If no
AT_IDENTITY attribute was exchanged, the exported Peer-Id is the AT_IDENTITY attribute was exchanged, the exported Peer-Id is the
identity provided from the EAP Identity Response packet. If no EAP identity provided from the EAP Identity Response packet. If no EAP
Identity Response was provided either, the exported Peer-Id is null Identity Response was provided either, the exported Peer-Id is null
string (zero length). string (zero length).
The Server-Id is the null string (zero length). The Server-Id is the null string (zero length).
7. Security Considerations 7. Security Considerations
A summary of the security properties of EAP-AKA' follows. These A summary of the security properties of EAP-AKA' follows. These
properties are very similar to those in EAP-AKA. We assume that properties are very similar to those in EAP-AKA. We assume that HMAC
SHA-256 is at least as secure as SHA-1. This is called the SHA-256 SHA-256 is at least as secure as HMAC SHA-1 (see also [RFC6194].
assumption in the remainder of this section. Under this assumption, This is called the SHA-256 assumption in the remainder of this
EAP-AKA' is at least as secure as EAP-AKA. section. Under this assumption, EAP-AKA' is at least as secure as
EAP-AKA.
If the AT_KDF attribute has value 1, then the security properties of If the AT_KDF attribute has value 1, then the security properties of
EAP-AKA' are as follows: EAP-AKA' are as follows:
Protected ciphersuite negotiation Protected ciphersuite negotiation
EAP-AKA' has no ciphersuite negotiation mechanisms. It does have EAP-AKA' has no ciphersuite negotiation mechanisms. It does have
a negotiation mechanism for selecting the key derivation a negotiation mechanism for selecting the key derivation
functions. This mechanism is secure against bidding down attacks. functions. This mechanism is secure against bidding down attacks.
The negotiation mechanism allows changing the offered key The negotiation mechanism allows changing the offered key
skipping to change at page 27, line 7 skipping to change at page 27, line 16
As discussed in Section 5.3, when authenticating to a 5G network, As discussed in Section 5.3, when authenticating to a 5G network,
only the 5G SUCI identifier should be used. The use of pseudonyms in only the 5G SUCI identifier should be used. The use of pseudonyms in
this situation is at best limited. In fact, the re-use of the same this situation is at best limited. In fact, the re-use of the same
pseudonym multiple times will result in a tracking opportunity for pseudonym multiple times will result in a tracking opportunity for
observers that see the pseudonym pass by. To avoid this, the peer observers that see the pseudonym pass by. To avoid this, the peer
and server need to follow the guidelines given in Section 5.2. and server need to follow the guidelines given in Section 5.2.
When authenticating to a 5G network, per Section 5.3.1, both the EAP- When authenticating to a 5G network, per Section 5.3.1, both the EAP-
AKA' peer and server need employ permanent identifier, SUPI, as an AKA' peer and server need employ permanent identifier, SUPI, as an
input to key generation. However, this use of the SUPI is only input to key derivation. However, this use of the SUPI is only
internal and the SUPI need not be communicated in EAP messages. SUCI internal and the SUPI need not be communicated in EAP messages. SUCI
MUST NOT be communicated in EAP-AKA' when authenticating to a 5G MUST NOT be communicated in EAP-AKA' when authenticating to a 5G
network. network.
While the use of SUCI in 5G networks generally provides identity While the use of SUCI in 5G networks generally provides identity
privacy, this is not true if the null-scheme encryption is used to privacy, this is not true if the null-scheme encryption is used to
construct the SUCI (see [TS-3GPP.23.501] Annex C). The use of this construct the SUCI (see [TS-3GPP.23.501] Annex C). The use of this
scheme turns the use of SUCI equivalent to the use of SUPI or IMSI. scheme turns the use of SUCI equivalent to the use of SUPI or IMSI.
The use of the null scheme is NOT RECOMMENDED where identity privacy The use of the null scheme is NOT RECOMMENDED where identity privacy
is important. is important.
skipping to change at page 28, line 44 skipping to change at page 29, line 5
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 where, for instance, it is not required to encrypt all
payload traffic after encryption. As an authentication mechanism, payload traffic after encryption. As an authentication mechanism,
EAP-AKA' is not directly affected by most such attacks. EAP-AKA' EAP-AKA' is not directly affected by most such attacks. EAP-AKA'
network name binding can also help alleviate some of the attacks. In 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. dependent on the 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
to combat this problem. to combat this problem.
There has also been attacks related to the use of AKA without the There has also been attacks related to the use of AKA without the
generated session keys (e.g., [BT2013]). Some of those attacks generated session keys (e.g., [BT2013]). Some of those attacks
relate to the use of originally man-in-the-middle vulnerable HTTP relate to the use of originally man-in-the-middle vulnerable HTTP
Digest AKAv1 [RFC3310]. This has since then been corrected in Digest AKAv1 [RFC3310]. This has since then been corrected in
[RFC4169]. The EAP-AKA' protocol uses session keys and provides [RFC4169]. The EAP-AKA' protocol uses session keys and provides
skipping to change at page 31, line 36 skipping to change at page 31, line 48
Ideally, the names allow separating each different access technology, Ideally, the names allow separating each different access technology,
each different access network, and each different NAS within a each different access network, and each different NAS within a
domain. If this is not possible, the full benefits may not be domain. If this is not possible, the full benefits may not be
achieved. For instance, if the names identify just an access achieved. For instance, if the names identify just an access
technology, use of compromised keys in a different technology can be technology, use of compromised keys in a different technology can be
prevented, but it is not possible to prevent their use by other prevented, but it is not possible to prevent their use by other
domains or devices using the same technology. domains or devices using the same technology.
8. IANA Considerations 8. IANA Considerations
IANA should update the Extensible Authentication Protocol (EAP)
Registry and the EAP-AKA and EAP-SIM Parameters so that entries
pointing to RFC 5448 will point to this RFC instead.
8.1. Type Value 8.1. Type Value
EAP-AKA' has the EAP Type value 50 in the Extensible Authentication EAP-AKA' has the EAP Type value 50 in the Extensible Authentication
Protocol (EAP) Registry under Method Types. Per Section 6.2 of Protocol (EAP) Registry under Method Types. Per Section 6.2 of
[RFC3748], this allocation can be made with Designated Expert and [RFC3748], this allocation can be made with Designated Expert and
Specification Required. Specification Required.
8.2. Attribute Type Values 8.2. Attribute Type Values
EAP-AKA' shares its attribute space and subtypes with EAP-SIM EAP-AKA' shares its attribute space and subtypes with EAP-SIM
skipping to change at page 35, line 5 skipping to change at page 35, line 21
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, Hash Standard", FIPS PUB 180-2, August 2002,
<http://csrc.nist.gov/publications/fips/fips180-2/ <http://csrc.nist.gov/publications/fips/fips180-2/
fips180-2.pdf>. fips180-2.pdf>.
[RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer
Protocol (HTTP) Digest Authentication Using Authentication Protocol (HTTP) Digest Authentication Using Authentication
and Key Agreement (AKA)", RFC 3310, DOI 10.17487/RFC3310, and Key Agreement (AKA)", RFC 3310, DOI 10.17487/RFC3310,
September 2002, <https://www.rfc-editor.org/info/rfc3310>. September 2002, <https://www.rfc-editor.org/info/rfc3310>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, <https://www.rfc-
editor.org/info/rfc4086>.
[RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext [RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext
Transfer Protocol (HTTP) Digest Authentication Using Transfer Protocol (HTTP) Digest Authentication Using
Authentication and Key Agreement (AKA) Version-2", Authentication and Key Agreement (AKA) Version-2",
RFC 4169, DOI 10.17487/RFC4169, November 2005, RFC 4169, DOI 10.17487/RFC4169, November 2005,
<https://www.rfc-editor.org/info/rfc4169>. <https://www.rfc-editor.org/info/rfc4169>.
[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible [RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
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,
skipping to change at page 35, line 47 skipping to change at page 36, line 21
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>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>.
[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>.
[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-02 (work in progress), July 2018. draft-arkko-eap-aka-pfs-03 (work in progress), October
2018.
[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 37, line 18 skipping to change at page 38, line 5
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.
Finally, the references to [RFC2119], [RFC5226], [FIPS.180-1] and The references to [RFC2119], [RFC5226], [FIPS.180-1] and [FIPS.180-2]
[FIPS.180-2] have been updated to their most recent versions and have been updated to their most recent versions and language in this
language in this document changed accordingly. Similarly, references document changed accordingly. Similarly, references to all 3GPP
to all 3GPP technical specifications have been updated to their 5G technical specifications have been updated to their 5G (Release 15)
(Release 15) versions or otherwise most recent version when there has versions or otherwise most recent version when there has not been a
not been a 5G-related update. 5G-related update.
Finally, a number of editorial clarifications have been made.
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
added to RFC 4187. added to RFC 4187.
Appendix C. Changes from Previous Version of This Draft Appendix C. Changes from Previous Version of This Draft
skipping to change at page 38, line 19 skipping to change at page 39, line 8
brought up in the context of AKA or EAP-AKA', and discusses their brought up in the context of AKA or EAP-AKA', and discusses their
applicability and impacts in EAP-AKA'. applicability and impacts in EAP-AKA'.
The -03 version of the working group draft corrected some typos, The -03 version of the working group draft corrected some typos,
referred to the 3GPP specifications for the SUPI and SUCI formats, referred to the 3GPP specifications for the SUPI and SUCI formats,
updated some of the references to newer versions, and reduced the updated some of the references to newer versions, and reduced the
strength of some of the recommendations in the security strength of some of the recommendations in the security
considerations section from keyword level to normal language (as they considerations section from keyword level to normal language (as they
are just deployment recommendations). are just deployment recommendations).
The -04 version of the working group draft rewrote the abstract and
some of the introduction, corrected some typos, added sentence to the
abstract about obsoleting RFC 5448, clarified the use of the language
when referring to AT_KDF values vs. AT_KDF attribute number, provided
guidance on random number generation, clarified the dangers relating
to the use of permanent user identities such as IMSIs, aligned the
key derivation function/mechanism terminology, aligned the key
derivation/generation terminology, aligned the octet/byte
terminology, clarified the text regarding strength of SHA-256, added
some cross references between sections, instructed IANA to change
registries to point to this RFC rather than RFC 5448, and changed
Pasi's listed affiliation.
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.
skipping to change at page 38, line 46 skipping to change at page 39, line 48
information, as noted in [RFC4284] and [RFC5113]. Even if these information, as noted in [RFC4284] and [RFC5113]. Even if these
networks or EAP were extended to carry additional information, it networks or EAP were extended to carry additional information, it
would not affect millions of deployed access networks and clients would not affect millions of deployed access networks and clients
attaching to them. attaching to them.
Simply changing the key derivation functions that EAP-AKA [RFC4187] Simply changing the key derivation functions that EAP-AKA [RFC4187]
uses would cause interoperability problems with all of the existing uses would cause interoperability problems with all of the existing
implementations. Perhaps it would be possible to employ strict implementations. Perhaps it would be possible to employ strict
separation into domain names that should be used by the new clients separation into domain names that should be used by the new clients
and networks. Only these new devices would then employ the new key and networks. Only these new devices would then employ the new key
derivation mechanism. While this can be made to work for specific derivation function. While this can be made to work for specific
cases, it would be an extremely brittle mechanism, ripe to result in cases, it would be an extremely brittle mechanism, ripe to result in
problems whenever client configuration, routing of authentication problems whenever client configuration, routing of authentication
requests, or server configuration does not match expectations. It requests, or server configuration does not match expectations. It
also does not help to assume that the EAP client and server are also does not help to assume that the EAP client and server are
running a particular release of 3GPP network specifications. Network running a particular release of 3GPP network specifications. Network
vendors often provide features from future releases early or do not vendors often provide features from future releases early or do not
provide all features of the current release. And obviously, there provide all features of the current release. And obviously, there
are many EAP and even some EAP-AKA implementations that are not are many EAP and even some EAP-AKA implementations that are not
bundled with the 3GPP network offerings. In general, these bundled with the 3GPP network offerings. In general, these
approaches are expected to lead to hard-to-diagnose problems and approaches are expected to lead to hard-to-diagnose problems and
skipping to change at page 44, line 42 skipping to change at page 45, line 42
Email: vesa.lehtovirta@ericsson.com Email: vesa.lehtovirta@ericsson.com
Vesa Torvinen Vesa Torvinen
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: vesa.torvinen@ericsson.com Email: vesa.torvinen@ericsson.com
Pasi Eronen Pasi Eronen
Nokia Research Center Independent
P.O. Box 407
FIN-00045 Nokia Group
Finland Finland
Email: pasi.eronen@nokia.com Email: pe@iki.fi
 End of changes. 49 change blocks. 
102 lines changed or deleted 143 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/