draft-ietf-emu-rfc5448bis-02.txt   draft-ietf-emu-rfc5448bis-03.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: March 21, 2019 Nokia Expires: April 22, 2019 Nokia
September 17, 2018 October 19, 2018
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-02 draft-ietf-emu-rfc5448bis-03
Abstract Abstract
This specification defines a new EAP method, EAP-AKA', a small This specification defines an EAP method, EAP-AKA', a small revision
revision of the EAP-AKA method. The change is a new key derivation of the EAP-AKA method. EAP-AKA' provides a key derivation function
function that binds the keys derived within the method to the name of that binds the keys derived within the method to the name of the
the access network. The new key derivation mechanism has been access network. The key derivation mechanism has been defined in the
defined in the 3rd Generation Partnership Project (3GPP). This 3rd Generation Partnership Project (3GPP). This specification allows
specification allows its use in EAP in an interoperable manner. In its use in EAP in an interoperable manner. In addition, EAP-AKA'
addition, EAP-AKA' employs SHA-256 instead of SHA-1. employs SHA-256 instead of SHA-1.
This specification also updates RFC 4187 EAP-AKA to prevent bidding This specification also updates RFC 4187 EAP-AKA to prevent bidding
down attacks from EAP-AKA'. down attacks from EAP-AKA'.
This version of the EAP-AKA' specification provides updates to This version of the EAP-AKA' specification provides updates to
specify the protocol behaviour for 5G deployments as well. specify 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
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 March 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) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 42 skipping to change at page 2, line 42
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 . . . . . . . . . . . . . . . . . . . 24 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 28 7.2. Discovered Vulnerabilities . . . . . . . . . . . . . . . 28
7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 30 7.3. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 29
7.4. Security Properties of Binding Network Names . . . . . . 31 7.4. Security Properties of Binding Network Names . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Type Value . . . . . . . . . . . . . . . . . . . . . . . 31
8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 32 8.2. Attribute Type Values . . . . . . . . . . . . . . . . . . 31
8.3. Key Derivation Function Namespace . . . . . . . . . . . . 32 8.3. Key Derivation Function Namespace . . . . . . . . . . . . 32
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1. Normative References . . . . . . . . . . . . . . . . . . 33 9.1. Normative References . . . . . . . . . . . . . . . . . . 32
9.2. Informative References . . . . . . . . . . . . . . . . . 34 9.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 37 Appendix A. Changes from RFC 5448 . . . . . . . . . . . . . . . 36
Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 38 Appendix B. Changes from RFC 4187 to RFC 5448 . . . . . . . . . 37
Appendix C. Changes from Previous Version of This Draft . . . . 38 Appendix C. Changes from Previous Version of This Draft . . . . 37
Appendix D. Importance of Explicit Negotiation . . . . . . . . . 38 Appendix D. Importance of Explicit Negotiation . . . . . . . . . 38
Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 39 Appendix E. Test Vectors . . . . . . . . . . . . . . . . . . . . 39
Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 43 Appendix F. Contributors . . . . . . . . . . . . . . . . . . . . 43
Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . 44 Appendix G. Acknowledgments . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
1. Introduction 1. Introduction
This specification defines a new Extensible Authentication Protocol This specification defines an Extensible Authentication Protocol
(EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA (EAP)[RFC3748] method, EAP-AKA', a small revision of the EAP-AKA
method originally defined in [RFC4187]. What is new in EAP-AKA' is method originally defined in [RFC4187]. EAP-AKA' provides a new key
that it has a new key derivation function, specified in derivation function, specified in [TS-3GPP.33.402]. This function
[TS-3GPP.33.402]. This function binds the keys derived within the binds the keys derived within the method to the name of the access
method to the name of the access network. This limits the effects of network. This limits the effects of compromised access network nodes
compromised access network nodes and keys. This specification and keys. This specification defines the EAP encapsulation for AKA
defines the EAP encapsulation for AKA when the new key derivation when the new key derivation mechanism is in use.
mechanism is in use.
3GPP has defined a number of applications for the revised AKA 3GPP has defined a number of applications for the revised AKA
mechanism, some based on native encapsulation of AKA over 3GPP radio mechanism, some based on native encapsulation of AKA over 3GPP radio
access networks and others based on the use of EAP. access networks and others based on the use of EAP.
For making the new key derivation mechanisms usable in EAP-AKA, For making the new key derivation mechanisms usable in EAP-AKA,
additional protocol mechanisms are necessary. Given that RFC 4187 additional protocol mechanisms are necessary. Given that RFC 4187
calls for the use of CK (the encryption key) and IK (the integrity calls for the use of CK (the encryption key) and IK (the integrity
key) from AKA, existing implementations continue to use these. Any key) from AKA, existing implementations continue to use these. Any
change of the key derivation must be unambiguous to both sides in the change of the key derivation must be unambiguous to both sides in the
skipping to change at page 21, line 23 skipping to change at page 21, line 23
the one communicated outside EAP in link layer messaging. the one communicated outside EAP in link layer messaging.
In this case, the used identity MUST be the identity most recently In this case, the used identity MUST be the identity most recently
communicated by the peer to the network, again regardless of what communicated by the peer to the network, again regardless of what
type of identity it may have been. type of identity it may have been.
5.3.1.1. Format of the SUPI 5.3.1.1. Format of the SUPI
A SUPI is either an IMSI or a Network Access Identifier [RFC4282]. A SUPI is either an IMSI or a Network Access Identifier [RFC4282].
The NAI string MUST be directly used in key derivation, and for IMSI, When used in EAP-AKA', the format of the SUPI MUST be as specified in
the following string MUST be used: [TS-3GPP.23.003] Sections 28.7.2, with the semantics defined in
[TS-3GPP.23.003] Section 2.2B. Also, in contrast to [RFC5448], in 5G
o Three ASCII digits to represent the Mobile Country Code (MCC). EAP-AKA' does not use the "0" or "6" prefix in front of the entire
IMSI.
o Three ASCII digits to represent the Mobile Network Code (MNC). If
there are only 2 significant digits in the MNC, one "0" digit
shall be inserted at the left side to fill the 3 digits coding of
MNC.
o ASCII digits to represent the rest of the IMSI. For instance, if the IMSI is 234150999999999 (MCC = 234, MNC = 15),
the NAI format for the SUPI takes the form:
The component values are specified in more detail in 234150999999999@nai.5gc.mnc015.mcc234.3gppnetwork.org
[TS-3GPP.23.003]. Note that no prefix ("0" or "6") in front of the
entire IMSI is used in the IMSI when used in the key derivation
function in 5G.
5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute 5.3.2. EAP Identity Response and EAP-AKA' AT_IDENTITY Attribute
The EAP authentication option is only available in 5G when the new 5G The EAP authentication option is only available in 5G when the new 5G
core network is also in use. However, in other networks an EAP-AKA' core network is also in use. However, in other networks an EAP-AKA'
peer may be connecting to other types of networks and existing peer may be connecting to other types of networks and existing
equipment. equipment.
When the EAP peer is connecting to a 5G access network and uses the When the EAP peer is connecting to a 5G access network and uses the
5G Non-Access Stratum (NAS) protocol [TS-3GPP.24.501], the EAP server 5G Non-Access Stratum (NAS) protocol [TS-3GPP.24.501], the EAP server
skipping to change at page 22, line 49 skipping to change at page 22, line 41
Similarly, if the peer is communicating over a non-3GPP network but Similarly, if the peer is communicating over a non-3GPP network but
carrying EAP inside 5G NAS protocol, it MUST assume that the EAP carrying EAP inside 5G NAS protocol, it MUST assume that the EAP
server is in a 5G network, and again employ the SUCI within EAP. server is in a 5G network, and again employ the SUCI within EAP.
Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is Otherwise, the peer SHOULD employ IMSI, SUPI, or a NAI as it is
configured to use. configured to use.
5.3.2.1. Format of the SUCI 5.3.2.1. Format of the SUCI
The SUCI format extends the format specified in [RFC4187] When used in EAP-AKA', the format of the SUCI MUST be as specified in
Section 4.1.1.6 for IMSIs. [TS-3GPP.23.003] Section 28.7.3, with the semantics defined in
[TS-3GPP.23.003] Section 2.2B. Also, in contrast to [RFC5448], in 5G
A SUCI SHOULD be represented by an ASCII string containing the EAP-AKA' does not use the "0" or "6" prefix in front of the
following components in sequence: identifier.
o A leading "6"
o Three ASCII digits to represent the Mobile Country Code (MCC).
o Three ASCII digits to represent the Mobile Network Code (MNC). If
there are only 2 significant digits in the MNC, one "0" digit
shall be inserted at the left side to fill the 3 digits coding of
MNC.
o Four ASCII digits to represent a routing indicator. For instance, assuming the IMSI 234150999999999, where MCC=234,
MNC=15 and MSISN=0999999999, the Routing Indicator 678, and a Home
Network Public Key Identifier of 27, the NAI format for the SUCI
takes the form:
o One hex character ("0" through "9" and "a" through "f") to For the null-scheme:
represent the protection profile.
o Hex characters representing Home Network Public Key Identifier type0.rid678.schid0.userid0999999999@nai.5gc.mnc015.
(HNPKI). The number of hex characters needed for this depends on mcc234.3gppnetwork.org
the protection profile.
o Hex characters representing the encrypted identity. The number of For the Profile <A> protection scheme:
hex characters depends on the protection profile and identity
being encrypted.
The component values are specified in more detail in type0.rid678.schid1.hnkey27.ecckey<ECC ephemeral public key>.
[TS-3GPP.23.003]. cip<encryption of 0999999999>.mac<MAC tag value>@nai.5gc.
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 octet) 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
skipping to change at page 28, line 37 skipping to change at page 28, line 16
external security mechanism with EAP-AKA are beyond the scope of this external security mechanism with EAP-AKA are beyond the scope of this
document. document.
Finally, as with other EAP methods, even when privacy-friendly Finally, as with other EAP methods, even when privacy-friendly
identifiers or EAP tunneling is used, typically the domain part of an identifiers or EAP tunneling is used, typically the domain part of an
identifier (e.g., the home operator) is visible to external parties. identifier (e.g., the home operator) is visible to external parties.
7.2. Discovered Vulnerabilities 7.2. Discovered Vulnerabilities
There have been no published attacks that violate the primary secrecy There have been no published attacks that violate the primary secrecy
or authentication properties defined for the anticipated or authentication properties defined for Authentication and Key
Authentication and Key Agreement (AKA) under the originally assumed Agreement (AKA) under the originally assumed trust model. The same
trust model. The same is true of EAP-AKA'. is true of EAP-AKA'.
However, there have been attacks when a different trust model is in However, there have been attacks when a different trust model is in
use, with characteristics not originally provided by the design, or use, with characteristics not originally provided by the design, or
when participants in the protocol leak information to outsiders on when participants in the protocol leak information to outsiders on
purpose, and there has been some privacy-related attacks. purpose, and there has been some privacy-related attacks.
For instance, the original AKA protocol does not prevent supplying For instance, the original AKA protocol does not prevent supplying
keys by an insider to a third party as done in, e.g., by Mjolsnes and keys by an insider to a third party as done in, e.g., by Mjolsnes and
Tsay in [MT2012] where a serving network lets an authentication run Tsay in [MT2012] where a serving network lets an authentication run
succeed, but then misuses the session keys to send traffic on the succeed, but then misuses the session keys to send traffic on the
skipping to change at page 29, line 16 skipping to change at page 28, line 43
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.
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 30, line 46 skipping to change at page 30, line 25
Beyond these operational considerations, there are also technical Beyond these operational considerations, there are also technical
means to improve resistance to these attacks. One approach is to means to improve resistance to these attacks. One approach is to
provide Perfect Forwards Secrecy (PFS). This would prevent any provide Perfect Forwards Secrecy (PFS). This would prevent any
passive attacks merely based on the long-term secrets and observation passive attacks merely based on the long-term secrets and observation
of traffic. Such a mechanism can be defined as an backwards- of traffic. Such a mechanism can be defined as an backwards-
compatible extension of EAP-AKA', and is pursued separately from this compatible extension of EAP-AKA', and is pursued separately from this
specification [I-D.arkko-eap-aka-pfs]. Alternatively, EAP-AKA' specification [I-D.arkko-eap-aka-pfs]. Alternatively, EAP-AKA'
authentication can be run inside a PFS-capable tunneled authentication can be run inside a PFS-capable tunneled
authentication method. In any case, the use of some PFS-capable authentication method. In any case, the use of some PFS-capable
mechanism is RECOMMENDED. mechanism is recommended.
7.4. Security Properties of Binding Network Names 7.4. Security Properties of Binding Network Names
The ability of EAP-AKA' to bind the network name into the used keys The ability of EAP-AKA' to bind the network name into the used keys
provides some additional protection against key leakage to provides some additional protection against key leakage to
inappropriate parties. The keys used in the protocol are specific to inappropriate parties. The keys used in the protocol are specific to
a particular network name. If key leakage occurs due to an accident, a particular network name. If key leakage occurs due to an accident,
access node compromise, or another attack, the leaked keys are only access node compromise, or another attack, the leaked keys are only
useful when providing access with that name. For instance, a useful when providing access with that name. For instance, a
malicious access point cannot claim to be network Y if it has stolen malicious access point cannot claim to be network Y if it has stolen
skipping to change at page 33, line 13 skipping to change at page 32, line 33
2-65535 Unassigned 2-65535 Unassigned
9. References 9. References
9.1. Normative References 9.1. Normative References
[TS-3GPP.23.003] [TS-3GPP.23.003]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; Numbering, Specification Group Core Network and Terminals; Numbering,
addressing and identification (Release 15)", 3GPP Draft addressing and identification (Release 15)", 3GPP Draft
Technical Specification 23.003, June 2018. Technical Specification 23.003, September 2018.
[TS-3GPP.23.501] [TS-3GPP.23.501]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G Specification Group Services and System Aspects; 3G
Security; Security architecture and procedures for 5G Security; Security architecture and procedures for 5G
System; (Release 15)", 3GPP Technical Specification System; (Release 15)", 3GPP Technical Specification
23.501, December 2017. 23.501, September 2018.
[TS-3GPP.24.302] [TS-3GPP.24.302]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; Access to Specification Group Core Network and Terminals; Access to
the 3GPP Evolved Packet Core (EPC) via non-3GPP access the 3GPP Evolved Packet Core (EPC) via non-3GPP access
networks; Stage 3; (Release 15)", 3GPP Draft Technical networks; Stage 3; (Release 15)", 3GPP Draft Technical
Specification 24.302, June 2018. Specification 24.302, September 2018.
[TS-3GPP.24.501] [TS-3GPP.24.501]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Core Network and Terminals; Access to Specification Group Core Network and Terminals; Access to
the 3GPP Evolved Packet Core (EPC) via non-3GPP access the 3GPP Evolved Packet Core (EPC) via non-3GPP access
networks; Stage 3; (Release 15)", 3GPP Draft Technical networks; Stage 3; (Release 15)", 3GPP Draft Technical
Specification 24.501, June 2018. Specification 24.501, September 2018.
[TS-3GPP.33.102] [TS-3GPP.33.102]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G Specification Group Services and System Aspects; 3G
Security; Security architecture (Release 15)", 3GPP Draft Security; Security architecture (Release 15)", 3GPP Draft
Technical Specification 33.102, June 2018. Technical Specification 33.102, June 2018.
[TS-3GPP.33.402] [TS-3GPP.33.402]
3GPP, "3GPP System Architecture Evolution (SAE); Security 3GPP, "3GPP System Architecture Evolution (SAE); Security
aspects of non-3GPP accesses (Release 15)", 3GPP Draft aspects of non-3GPP accesses (Release 15)", 3GPP Draft
Technical Specification 33.402, June 2018. Technical Specification 33.402, June 2018.
[TS-3GPP.33.501] [TS-3GPP.33.501]
3GPP, "3rd Generation Partnership Project; Technical 3GPP, "3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects; 3G Specification Group Services and System Aspects; 3G
Security; Security architecture and procedures for 5G Security; Security architecture and procedures for 5G
System (Release 15)", 3GPP Draft Technical Specification System (Release 15)", 3GPP Draft Technical Specification
33.501, June 2018. 33.501, September 2018.
[FIPS.180-4] [FIPS.180-4]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-4, August 2015, Hash Standard", FIPS PUB 180-4, August 2015,
<https://nvlpubs.nist.gov/nistpubs/FIPS/ <https://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>. NIST.FIPS.180-4.pdf>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, <https://www.rfc- DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
skipping to change at page 38, line 41 skipping to change at page 38, line 12
of pseudonym and fast re-authentication identifiers, specified the of pseudonym and fast re-authentication identifiers, specified the
format of 5G-identifiers when they are used within EAP-AKA', defined format of 5G-identifiers when they are used within EAP-AKA', defined
privacy and pervasive surveillance considerations, clarified when 5G- privacy and pervasive surveillance considerations, clarified when 5G-
related procedures apply, specified what Peer-Id value is exported related procedures apply, specified what Peer-Id value is exported
when no AT_IDENTITY is exchanged within EAP-AKA', and made a number when no AT_IDENTITY is exchanged within EAP-AKA', and made a number
of other clarifications and editorial improvements. The security of other clarifications and editorial improvements. The security
considerations section also includes a summary of vulnerabilities considerations section also includes a summary of vulnerabilities
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,
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).
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 44, line 14 skipping to change at page 44, line 14
Jouni Malinen provided suggested text for Section 6. John Mattsson Jouni Malinen provided suggested text for Section 6. John Mattsson
provided much of the text for Section 7.1. Karl Norrman was the provided much of the text for Section 7.1. Karl Norrman was the
source of much of the information in Section 7.2. source of much of the information in Section 7.2.
Appendix G. Acknowledgments Appendix G. Acknowledgments
The authors would like to thank Guenther Horn, Joe Salowey, Mats The authors would like to thank Guenther Horn, Joe Salowey, Mats
Naslund, Adrian Escott, Brian Rosenberg, Laksminath Dondeti, Ahmad Naslund, Adrian Escott, Brian Rosenberg, Laksminath Dondeti, Ahmad
Muhanna, Stefan Rommer, Miguel Garcia, Jan Kall, Ankur Agarwal, Jouni Muhanna, Stefan Rommer, Miguel Garcia, Jan Kall, Ankur Agarwal, Jouni
Malinen, John Mattsson, Brian Weis, Russ Housley, Alfred Hoenes, Malinen, John Mattsson, Jesus De Gregorio, Brian Weis, Russ Housley,
Anand Palanigounder, and Mohit Sethi for their in-depth reviews and Alfred Hoenes, Anand Palanigounder, and Mohit Sethi for their in-
interesting discussions in this problem space. depth reviews and interesting discussions in this problem space.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
 End of changes. 30 change blocks. 
82 lines changed or deleted 74 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/