--- 1/draft-ietf-emu-rfc5448bis-03.txt 2019-01-17 14:14:05.211956151 -0800 +++ 2/draft-ietf-emu-rfc5448bis-04.txt 2019-01-17 14:14:05.299958295 -0800 @@ -1,165 +1,172 @@ Network Working Group J. Arkko Internet-Draft V. Lehtovirta Obsoletes: 5448 (if approved) V. Torvinen Updates: 4187 (if approved) Ericsson Intended status: Informational P. Eronen -Expires: April 22, 2019 Nokia - October 19, 2018 +Expires: July 21, 2019 Independent + January 17, 2019 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') - draft-ietf-emu-rfc5448bis-03 + draft-ietf-emu-rfc5448bis-04 Abstract - This specification defines an EAP method, EAP-AKA', a small revision - of the EAP-AKA method. EAP-AKA' provides a key derivation function - that binds the keys derived within the method to the name of the - access network. The key derivation mechanism has been defined in the - 3rd Generation Partnership Project (3GPP). This specification allows - its use in EAP in an interoperable manner. In addition, EAP-AKA' - employs SHA-256 instead of SHA-1. + The 3rd Generation Authentication and Key Agreement (AKA) is the + primary authentication mechanism for devices wishing to access mobile + networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible + within the Extensible Authentication Protocol (EAP) framework. RFC + 5448 (EAP-AKA') was an improved version of EAP-AKA. - This specification also updates RFC 4187 EAP-AKA to prevent bidding - down attacks from EAP-AKA'. + This memo is an update of the specification for EAP-AKA'. This + version obsoletes RFC 5448. - This version of the EAP-AKA' specification provides updates to - specify the protocol behaviour for 5G deployments as well. + 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 + 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 This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - - This Internet-Draft will expire on April 22, 2019. + This Internet-Draft will expire on July 21, 2019. 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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. EAP-AKA' . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. AT_KDF_INPUT . . . . . . . . . . . . . . . . . . . . . . 8 3.2. AT_KDF . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 3.3. Key Generation . . . . . . . . . . . . . . . . . . . . . 13 + 3.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . 13 3.4. Hash Functions . . . . . . . . . . . . . . . . . . . . . 15 3.4.1. PRF' . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.2. AT_MAC . . . . . . . . . . . . . . . . . . . . . . . 15 3.4.3. AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . 15 4. Bidding Down Prevention for EAP-AKA . . . . . . . . . . . . . 16 5. Peer Identities . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Username Types in EAP-AKA' Identities . . . . . . . . . . 18 5.2. Generating Pseudonyms and Fast Re-Authentication Identities . . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Identifier Usage in 5G . . . . . . . . . . . . . . . . . 19 5.3.1. Key Derivation . . . . . . . . . . . . . . . . . . . 20 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute . . . . . . . . . . . . . . . . . . . . . . 21 6. Exported Parameters . . . . . . . . . . . . . . . . . . . . . 23 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 28 - 7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29 + 7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 30 7.4. Security Properties of Binding Network Names . . . . . . 30 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 - 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 31 - 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 31 + 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 32 + 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 32 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 32 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1. Normative References . . . . . . . . . . . . . . . . . . 32 9.2. Informative References . . . . . . . . . . . . . . . . . 34 - Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 36 - Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 37 - Appendix C. Changes from Previous Version of This Draft . . . . 37 - Appendix D. Importance of Explicit Negotiation . . . . . . . . . 38 - Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 39 - Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 43 - Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . 44 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 + Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 37 + Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 38 + Appendix C. Changes from Previous Version of This Draft . . . . 38 + Appendix D. Importance of Explicit Negotiation . . . . . . . . . 39 + Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 40 + Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 44 + Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . 45 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 1. Introduction - This specification defines an Extensible Authentication Protocol - (EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA - method originally defined in [RFC4187]. EAP-AKA' provides a new key - derivation function, specified in [TS-3GPP.33.402]. This function - binds the keys derived within the method to the name of the access - network. This limits the effects of compromised access network nodes - and keys. This specification defines the EAP encapsulation for AKA - when the new key derivation mechanism is in use. + The 3rd Generation Authentication and Key Agreement (AKA) is the + primary authentication mechanism for devices wishing to access mobile + networks. [RFC4187] (EAP-AKA) made the use of this mechanism + possible within the Extensible Authentication Protocol (EAP) + framework [RFC3748]. - 3GPP has defined a number of applications for the revised AKA - mechanism, some based on native encapsulation of AKA over 3GPP radio - access networks and others based on the use of EAP. + [RFC5448] (EAP-AKA') was an improved version of EAP-AKA. This memo + is an update of the specification for EAP-AKA'. This version + obsoletes RFC 5448. - For making the new key derivation mechanisms usable in EAP-AKA, - additional protocol mechanisms are necessary. Given that RFC 4187 - calls for the use of CK (the encryption key) and IK (the integrity - key) from AKA, existing implementations continue to use these. Any - change of the key derivation must be unambiguous to both sides in the - 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. + EAP-AKA' is commonly implemented in smart phones and network + equipment. It can be used for authentication to gain network access + via Wireless LAN networks and, with 5G, also directly to mobile + networks. - This specification therefore introduces a variant of the EAP-AKA - method, called EAP-AKA'. This method can employ the derived keys CK' - and IK' from the 3GPP specification and updates the used hash - function to SHA-256 [FIPS.180-4]. But it is otherwise equivalent to - RFC 4187. Given that a different EAP method type value is used for + EAP-AKA' differs from EAP-AKA by providing a different key derivation + function. This function binds the keys derived within the method to + the name of the access network. This limits the effects of + compromised access network nodes and keys. EAP-AKA' is also an + 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 using the standard mechanisms in EAP [RFC3748]. - Note: Appendix D explains why it is important to be explicit about - the change of semantics for the keys, and why other approaches - would lead to severe interoperability problems. + Note that any 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. See Appendix D for further information. - This version of the EAP-AKA' specification obsoletes RFC 5448. The - changes are as follows: + Note also that choices in authentication protocols should be + 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 in the protocol. The update ensures that EAP-AKA' is compatible with 5G deployments. RFC 5448 referred to the Release 8 version of [TS-3GPP.24.302] and this update points to the first 5G version, Release 15. o Specify how EAP and EAP-AKA' use identifiers in 5G. Additional identifiers are introduced in 5G, and for interoperability, it is 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 trackable, permanent identifiers are passed in EAP-AKA' either. o Specify session identifiers and other exported parameters, as those were not specified in [RFC5448] despite requirements set forward in [RFC5247] to do so. Also, while [RFC5247] specified session identifiers for EAP-AKA, it only did so for the full authentication case, not for the case of fast re-authentication. o Update the requirements on generating pseudonym usernames and fast @@ -172,21 +179,21 @@ related to EAP-AKA'. Some of the updates are small. For instance, for the first update, the reference update does not change the 3GPP specification number, only the version. But this reference is crucial in correct calculation of the keys resulting from running the EAP-AKA' method, so an update of the RFC with the newest version pointer may be warranted. 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. Upon such updates there will be a need to both update the specification and the implementations. It is an explicit non-goal of this draft to include any other technical modifications, addition of new features or other changes. 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 standalone extensions or even as different authentication methods. @@ -213,21 +220,21 @@ 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 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: 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, to ensure that both the peer and server know the name of the access network. o It supports key derivation function negotiation via the AT_KDF attribute (Section 3.2) to allow for future extensions. @@ -516,25 +523,25 @@ [RFC4187]. This happens after AT_KDF negotiation has already completed. An AKA'-Synchronization-Failure message is sent as a response to the newly received EAP-Request/AKA'-Challenge (the last message of the AT_KDF negotiation). The AKA'-Synchronization-Failure 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 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 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. - AT_KDF set to 1 + AT_KDF parameter has the value 1 In this case, MK is derived and used as follows: MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) K_encr = MK[0..127] K_aut = MK[128..383] K_re = MK[384..639] MSK = MK[640..1151] EMSK = MK[1152..1663] @@ -619,21 +626,21 @@ 3.4. Hash Functions 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 the AT_MAC and AT_CHECKCODE attributes. 3.4.1. PRF' The PRF' construction is the same one IKEv2 uses (see Section 2.13 of [RFC4306]). The function takes two arguments. K is a 256-bit value - 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: PRF'(K,S) = T1 | T2 | T3 | T4 | ... where: T1 = HMAC-SHA-256 (K, S | 0x01) T2 = HMAC-SHA-256 (K, T1 | S | 0x02) T3 = HMAC-SHA-256 (K, T2 | S | 0x03) T4 = HMAC-SHA-256 (K, T3 | S | 0x04) ... @@ -740,26 +747,29 @@ EAP-AKA' peer identities are as specified in [RFC4187] Section 4.1, with the addition of some requirements specified in this section. EAP-AKA' includes optional identity privacy support that can be used to hide the cleartext permanent identity and thereby make the subscriber's EAP exchanges untraceable to eavesdroppers. EAP-AKA' can also use the privacy friendly identifiers specified for 5G networks. - The permanent identity is usually based on the IMSI, which may - further help the tracking, because the same identifier may be used in - other contexts as well. 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. + The permanent identity is usually based on the IMSI. Exposing the + IMSI is undesirable, because as a permanent identity it is easily + trackable. In addition, since IMSIs may be used in other contexts as + well, there would be additional opportunities for such tracking. + + 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 Section 4.1.1.3 of [RFC4187] specified that there are three types of usernames: permanent, pseudonym, and fast re-authentication usernames. This specification extends this definition as follows. There are four types of usernames: (1) Regular usernames. These are external names given to EAP- AKA'. The regular usernames are further subdivided into to @@ -796,39 +806,40 @@ However, to ensure privacy some additional requirements need to be applied. The pseudonym usernames and fast re-authentication identities MUST be generated in a cryptographically secure way so that that it is computationally infeasible for at attacker to differentiate two identities belonging to the same user from two identities belonging to different users. This can be achieved, for instance, by using 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 MUST NOT include substrings that can be used to relate the username to a particular entity or a particular permanent identity. For instance, the usernames can not include any subscriber-identifying 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 across multiple different pseudonyms or fast re-authentication identities for the same subscriber. When the identifier used to identify a subscriber in an EAP-AKA' authentication exchange is a privacy-friendly identifier that is used only once, the EAP-AKA' peer MUST NOT use a pseudonym provided in that authentication exchange in subsequent exchanges more than once. To ensure that this does not happen, EAP-AKA' server MAY decline to provide a pseudonym in such authentication exchanges. An important 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 In EAP-AKA', the peer identity may be communicated to the server in one of three ways: o As a part of link layer establishment procedures, externally to EAP. o With the EAP-Response/Identity message in the beginning of the EAP @@ -850,31 +861,30 @@ for interoperability that the right type of identifier is used. 5G defines the SUbscription Permanent Identifier (SUPI) and SUbscription Concealed Identifier (SUCI) [TS-3GPP.23.501] [TS-3GPP.33.501] [TS-3GPP.23.003]. SUPI is globally unique and allocated to each subscriber. However, it is only used internally in the 5G network, and is privacy sensitive. The SUCI is a privacy preserving identifier containing the concealed SUPI, using public key cryptography to encrypt the SUPI. - Given the choice between these two types of identifiers, two areas - need further specification in EAP-AKA' to ensure that different - implementations understand each other and stay interoperable: + Given the choice between these two types of identifiers, EAP-AKA' + ensures interoperability as follows: o Where identifiers are used within EAP-AKA' -- such as key 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 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 transmitted outside EAP. However, in a system involving terminals from many generations and several connectivity options via 5G and other mechanisms, implementations and the EAP-AKA' specification need to prepare for many different situations, including sometimes having to communicate identities within EAP. The following sections clarify which identifiers are used and how. @@ -909,21 +919,21 @@ In this case, the used identity MUST be the identity most recently communicated by the peer to the network, again regardless of what type of identity it may have been. 5.3.1.1. Format of the SUPI A SUPI is either an IMSI or a Network Access Identifier [RFC4282]. 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 EAP-AKA' does not use the "0" or "6" prefix in front of the entire IMSI. For instance, if the IMSI is 234150999999999 (MCC = 234, MNC = 15), the NAI format for the SUPI takes the form: 234150999999999@nai.5gc.mnc015.mcc234.3gppnetwork.org 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute @@ -938,29 +948,30 @@ is in a 5G network. The EAP identity exchanges are generally not used in this case, as the identity is already made available on previous link layer exchanges. In this situation, the EAP server SHOULD NOT request an additional identity from the peer. If the peer for some reason receives EAP- Request/Identity or EAP-Request/AKA-Identity messages, the peer should behave as follows. Receive EAP-Request/Identity + In this case, the peer SHOULD respond with a EAP-Response/Identity containing the privacy-friendly 5G identifier, the SUCI. The SUCI SHOULD be represented as specified in Section 5.3.2.1. EAP-Request/AKA-Identity with AT_PERMANENT_REQ For privacy reasons, the peer should follow a "conservative" 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 client error code 0, "unable to process packet". EAP-Request/AKA-Identity with AT_FULLAUTH_REQ In this case, the peer SHOULD respond with a EAP-Response/AKA- Identity containing the SUCI. The SUCI SHOULD be represented as specified in Section 5.3.2.1. @@ -1000,53 +1011,54 @@ For the Profile protection scheme: type0.rid678.schid1.hnkey27.ecckey. cip.mac@nai.5gc. mnc015.mcc234.3gppnetwork.org 6. Exported Parameters The EAP-AKA' Session-Id is the concatenation of the EAP Type Code - (50, one octet) with the contents of the RAND field from the AT_RAND + (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: Session-Id = 50 || RAND || AUTN When using fast re-authentication, the EAP-AKA' Session-Id is 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 of the MAC field from the AT_MAC attribute from EAP-Request/AKA- Reauthentication: Session-Id = 50 || NONCE_S || MAC 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 transmitted, regardless of whether the transmitted identity was a permanent, pseudonym, or fast EAP re-authentication identity. If no AT_IDENTITY attribute was exchanged, the exported Peer-Id is the identity provided from the EAP Identity Response packet. If no EAP Identity Response was provided either, the exported Peer-Id is null string (zero length). The Server-Id is the null string (zero length). 7. Security Considerations A summary of the security properties of EAP-AKA' follows. These - properties are very similar to those in EAP-AKA. We assume that - SHA-256 is at least as secure as SHA-1. This is called the SHA-256 - assumption in the remainder of this section. Under this assumption, - EAP-AKA' is at least as secure as EAP-AKA. + properties are very similar to those in EAP-AKA. We assume that HMAC + SHA-256 is at least as secure as HMAC SHA-1 (see also [RFC6194]. + This is called the SHA-256 assumption in the remainder of this + 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 EAP-AKA' are as follows: Protected ciphersuite negotiation EAP-AKA' has no ciphersuite negotiation mechanisms. It does have a negotiation mechanism for selecting the key derivation functions. This mechanism is secure against bidding down attacks. The negotiation mechanism allows changing the offered key @@ -1179,21 +1190,21 @@ 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 this situation is at best limited. In fact, the re-use of the same pseudonym multiple times will result in a tracking opportunity for observers that see the pseudonym pass by. To avoid this, the peer 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- 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 MUST NOT be communicated in EAP-AKA' when authenticating to a 5G network. While the use of SUCI in 5G networks generally provides identity 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 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 is important. @@ -1265,29 +1276,30 @@ Another class of attacks is the use of tunneling of traffic from one place to another, e.g., as done by Zhang and Fang in [ZF2005] to leverage security policy differences between different operator networks, for instance. To gain something in such an attack, the attacker needs to trick the user into believing it is in another location where, for instance, it is not required to encrypt all payload traffic after encryption. As an authentication mechanism, EAP-AKA' is not directly affected by most such attacks. EAP-AKA' network name binding can also help alleviate some of the attacks. In any case, it is recommended that EAP-AKA' configuration not be - 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 serving network may request large numbers of authentication runs for a particular subscriber from a home network. While resynchronization process can help recover from this, eventually it is possible to exhaust the sequence number space and render the subscriber's card unusable. This attack is possible for both native AKA and EAP-AKA'. - However, it requires the collaboration of a serving network in an attack. It is recommended that EAP-AKA' implementations provide means to track, detect, and limit excessive authentication attempts to combat this problem. There has also been attacks related to the use of AKA without the generated session keys (e.g., [BT2013]). Some of those attacks relate to the use of originally man-in-the-middle vulnerable HTTP Digest AKAv1 [RFC3310]. This has since then been corrected in [RFC4169]. The EAP-AKA' protocol uses session keys and provides @@ -1402,20 +1414,24 @@ Ideally, the names allow separating each different access technology, each different access network, and each different NAS within a domain. If this is not possible, the full benefits may not be achieved. For instance, if the names identify just an access technology, use of compromised keys in a different technology can be prevented, but it is not possible to prevent their use by other domains or devices using the same technology. 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 EAP-AKA' has the EAP Type value 50 in the Extensible Authentication Protocol (EAP) Registry under Method Types. Per Section 6.2 of [RFC3748], this allocation can be made with Designated Expert and Specification Required. 8.2. Attribute Type Values EAP-AKA' shares its attribute space and subtypes with EAP-SIM @@ -1554,20 +1570,25 @@ National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, . [RFC3310] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, DOI 10.17487/RFC3310, September 2002, . + [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC 4086, + DOI 10.17487/RFC4086, June 2005, . + [RFC4169] Torvinen, V., Arkko, J., and M. Naslund, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2", RFC 4169, DOI 10.17487/RFC4169, November 2005, . [RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, @@ -1596,35 +1617,41 @@ Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, . [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, DOI 10.17487/RFC5448, May 2009, . + [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, + . + [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . [I-D.arkko-eap-aka-pfs] Arkko, J., Norrman, K., and V. Torvinen, "Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)", - draft-arkko-eap-aka-pfs-02 (work in progress), July 2018. + draft-arkko-eap-aka-pfs-03 (work in progress), October + 2018. [Heist2015] Scahill, J. and J. Begley, "The great SIM heist", February 2015, in https://firstlook.org/theintercept/2015/02/19/ great-sim-heist/ . [MT2012] Mjolsnes, S. and J-K. Tsay, "A vulnerability in the UMTS and LTE authentication and key agreement protocols", October 2012, in Proceedings of the 6th international conference on Mathematical Methods, Models and @@ -1664,26 +1691,28 @@ definition in RFC 5448, which referenced RFC 4187. See Section 5. Thirdly, exported parameters for EAP-AKA' have been defined in Section 6, as required by [RFC5247], including the definition of those parameters for both full authentication and fast re- authentication. The security, privacy, and pervasive monitoring considerations have been updated or added. See Section 7. - Finally, the references to [RFC2119], [RFC5226], [FIPS.180-1] and - [FIPS.180-2] have been updated to their most recent versions and - language in this document changed accordingly. Similarly, references - to all 3GPP technical specifications have been updated to their 5G - (Release 15) versions or otherwise most recent version when there has - not been a 5G-related update. + The references to [RFC2119], [RFC5226], [FIPS.180-1] and [FIPS.180-2] + have been updated to their most recent versions and language in this + document changed accordingly. Similarly, references to all 3GPP + technical specifications have been updated to their 5G (Release 15) + versions or otherwise most recent version when there has not been a + 5G-related update. + + Finally, a number of editorial clarifications have been made. Appendix B. Changes from RFC 4187 to RFC 5448 The changes to RFC 4187 relate only to the bidding down prevention support defined in Section 4. In particular, this document does not change how the Master Key (MK) is calculated in RFC 4187 (it uses CK and IK, not CK' and IK'); neither is any processing of the AMF bit added to RFC 4187. Appendix C. Changes from Previous Version of This Draft @@ -1714,20 +1743,33 @@ brought up in the context of AKA or EAP-AKA', and discusses their applicability and impacts in EAP-AKA'. The -03 version of the working group draft corrected some typos, referred to the 3GPP specifications for the SUPI and SUCI formats, updated some of the references to newer versions, and reduced the strength of some of the recommendations in the security considerations section from keyword level to normal language (as they 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 Choosing between the traditional and revised AKA key derivation functions is easy when their use is unambiguously tied to a particular radio access network, e.g., Long Term Evolution (LTE) as defined by 3GPP or evolved High Rate Packet Data (eHRPD) as defined by 3GPP2. There is no possibility for interoperability problems if this radio access network is always used in conjunction with new protocols that cannot be mixed with the old ones; clients will always know whether they are connecting to the old or new system. @@ -1741,21 +1783,21 @@ information, as noted in [RFC4284] and [RFC5113]. Even if these networks or EAP were extended to carry additional information, it would not affect millions of deployed access networks and clients attaching to them. Simply changing the key derivation functions that EAP-AKA [RFC4187] uses would cause interoperability problems with all of the existing implementations. Perhaps it would be possible to employ strict separation into domain names that should be used by the new clients 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 problems whenever client configuration, routing of authentication requests, or server configuration does not match expectations. It also does not help to assume that the EAP client and server are running a particular release of 3GPP network specifications. Network vendors often provide features from future releases early or do not provide all features of the current release. And obviously, there are many EAP and even some EAP-AKA implementations that are not bundled with the 3GPP network offerings. In general, these approaches are expected to lead to hard-to-diagnose problems and @@ -1977,16 +2019,14 @@ Email: vesa.lehtovirta@ericsson.com Vesa Torvinen Ericsson Jorvas 02420 Finland Email: vesa.torvinen@ericsson.com Pasi Eronen - Nokia Research Center - P.O. Box 407 - FIN-00045 Nokia Group + Independent Finland - Email: pasi.eronen@nokia.com + Email: pe@iki.fi