rfc9678.original   rfc9678.txt 
Network Working Group J. Arkko Internet Engineering Task Force (IETF) J. Arkko
Internet-Draft K. Norrman Request for Comments: 9678 K. Norrman
Updates: 5448, 9048 (if approved) J. Preuß Mattsson Updates: 5448, 9048 J. Preuß Mattsson
Intended status: Standards Track Ericsson Category: Standards Track Ericsson
Expires: 22 August 2024 19 February 2024 ISSN: 2070-1721 October 2024
Forward Secrecy for the Extensible Authentication Protocol Method for Forward Secrecy for the Extensible Authentication Protocol Method for
Authentication and Key Agreement (EAP-AKA' FS) Authentication and Key Agreement (EAP-AKA' FS)
draft-ietf-emu-aka-pfs-12
Abstract Abstract
This document updates RFC 9048, the improved Extensible This document updates RFC 9048, which details the improved Extensible
Authentication Protocol Method for 3GPP Mobile Network Authentication Authentication Protocol Method for 3GPP Mobile Network Authentication
and Key Agreement (EAP-AKA'), with an optional extension providing and Key Agreement (EAP-AKA'), with an optional extension providing
ephemeral key exchange. Similarly, this document also updates the ephemeral key exchange. Similarly, this document also updates the
earlier version of the EAP-AKA' specification in RFC 5448. The earlier version of the EAP-AKA' specification in RFC 5448. The
extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated,
provides forward secrecy for the session keys generated as a part of provides forward secrecy for the session keys generated as a part of
the authentication run in EAP-AKA'. This prevents an attacker who the authentication run in EAP-AKA'. This prevents an attacker who
has gained access to the long-term key from obtaining session keys has gained access to the long-term key from obtaining session keys
established in the past, assuming these have been properly deleted. established in the past, assuming these have been properly deleted.
In addition, EAP-AKA' FS mitigates passive attacks (e.g., large scale In addition, EAP-AKA' FS mitigates passive attacks (e.g., large-scale
pervasive monitoring) against future sessions. This forces attackers pervasive monitoring) against future sessions. This forces attackers
to use active attacks instead. to use active attacks instead.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 22 August 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9678.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language
3. Protocol Design and Deployment Objectives . . . . . . . . . . 4 3. Protocol Design and Deployment Objectives
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Background
4.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. AKA
4.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 6 4.2. EAP-AKA' Protocol
4.3. Attacks Against Long-Term Keys in Smart Cards . . . . . . 8 4.3. Attacks Against Long-Term Keys in Smart Cards
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Overview
6. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 11 6. Extensions to EAP-AKA'
6.1. AT_PUB_ECDHE . . . . . . . . . . . . . . . . . . . . . . 11 6.1. AT_PUB_ECDHE
6.2. AT_KDF_FS . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. AT_KDF_FS
6.3. Forward Secrecy Key Derivation Functions . . . . . . . . 14 6.3. Forward Secrecy Key Derivation Functions
6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 16 6.4. ECDHE Groups
6.5. Message Processing . . . . . . . . . . . . . . . . . . . 16 6.5. Message Processing
6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 16 6.5.1. EAP-Request/AKA'-Identity
6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 16 6.5.2. EAP-Response/AKA'-Identity
6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 17 6.5.3. EAP-Request/AKA'-Challenge
6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 17 6.5.4. EAP-Response/AKA'-Challenge
6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 18 6.5.5. EAP-Request/AKA'-Reauthentication
6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 18 6.5.6. EAP-Response/AKA'-Reauthentication
6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 18 6.5.7. EAP-Response/AKA'-Synchronization-Failure
6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 18 6.5.8. EAP-Response/AKA'-Authentication-Reject
6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 18 6.5.9. EAP-Response/AKA'-Client-Error
6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 19 6.5.10. EAP-Request/AKA'-Notification
6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 19 6.5.11. EAP-Response/AKA'-Notification
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations
7.1. Deployment Considerations . . . . . . . . . . . . . . . . 21 7.1. Deployment Considerations
7.2. Security Properties . . . . . . . . . . . . . . . . . . . 21 7.2. Security Properties
7.3. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 23 7.3. Denial of Service
7.4. Identity Privacy . . . . . . . . . . . . . . . . . . . . 24 7.4. Identity Privacy
7.5. Unprotected Data and Privacy . . . . . . . . . . . . . . 24 7.5. Unprotected Data and Privacy
7.6. Forward Secrecy within AT_ENCR . . . . . . . . . . . . . 24 7.6. Forward Secrecy within AT_ENCR
7.7. Post-Quantum Considerations . . . . . . . . . . . . . . . 25 7.7. Post-Quantum Considerations
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 9. References
9.1. Normative References . . . . . . . . . . . . . . . . . . 26 9.1. Normative References
9.2. Informative References . . . . . . . . . . . . . . . . . 28 9.2. Informative References
Acknowledgments
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Many different attacks have been reported as part of revelations Many different attacks have been reported as part of the revelations
associated with pervasive surveillance. Some of the reported attacks associated with pervasive surveillance. Some of the reported attacks
involved compromising the Universal Subscriber Identity Module (USIM) involved compromising the Universal Subscriber Identity Module (USIM)
card supply chain. Attacks revealing the AKA long-term key may occur card supply chain. Attacks revealing the AKA long-term key may
for instance, during the manufacturing process of USIM cards, during occur, for instance:
the transfer of the cards and associated information to the operator,
and when a system is running. Since the publication of reports about * during the manufacturing process of USIM cards,
such attacks [Heist2015], manufacturing and provisioning processes
have gained much scrutiny and have improved. * during the transfer of the cards and associated information to the
operator, and
* when a system is running.
Since the publication of reports about such attacks (see
[Heist2015]), manufacturing and provisioning processes have gained
much scrutiny and have improved.
However, the danger of resourceful attackers attempting to gain However, the danger of resourceful attackers attempting to gain
information about long-term keys is still a concern because these information about long-term keys is still a concern because these
keys are high-value targets. Note that the attacks are largely keys are high-value targets. Note that the attacks are largely
independent of the used authentication technology; the issue is not independent of the used authentication technology; the issue is not
vulnerabilities in algorithms or protocols, but rather the vulnerabilities in algorithms or protocols, but rather the
possibility of someone gaining unauthorized access to key material. possibility of someone gaining unauthorized access to key material.
Furthermore, an explicit goal of the IETF is to ensure that we Furthermore, an explicit goal of the IETF is to ensure that we
understand the surveillance concerns related to IETF protocols and understand the surveillance concerns related to IETF protocols and
take appropriate countermeasures [RFC7258]. take appropriate countermeasures [RFC7258].
While strong protection of manufacturing and other processes is While strong protection of manufacturing and other processes is
essential in mitigating surveillance and other risks associated with essential in mitigating surveillance and other risks associated with
AKA long-term keys, there are also protocol mechanisms that can help. AKA long-term keys, there are also protocol mechanisms that can help.
This document updates [RFC9048], the Improved 3GPP Mobile Network This document updates [RFC9048], "Improved Extensible Authentication
Authentication and Key Agreement (EAP-AKA') method, with an optional Protocol Method for 3GPP Mobile Network Authentication and Key
extension providing ephemeral key exchange minimizing the impact of Agreement (EAP-AKA')", with an optional extension providing ephemeral
long-term key compromise and strengthens the identity privacy key exchange, which minimizes the impact of long-term key compromise
requirements. This is important, given the large number of users of and strengthens the identity privacy requirements. This is
AKA in mobile networks. important, given the large number of users of AKA in mobile networks.
The extension, when negotiated, provides Forward Secrecy (FS) The extension, when negotiated, provides Forward Secrecy (FS)
[DOW1992] for the session key generated as a part of the [DOW1992] for the session key generated as a part of the
authentication run in EAP-AKA'. This prevents an attacker who has authentication run in EAP-AKA'. This prevents an attacker who has
gained access to the long-term key in a USIM card from getting access gained access to the long-term key in a USIM card from getting access
to past session keys. In addition to FS, the included Diffie-Hellman to past session keys. In addition to FS, the included Diffie-Hellman
exchange, forces attackers to be active if they want access to future exchange forces attackers to be active if they want access to future
session keys even if they have access to the long-term key. This is session keys, even if they have access to the long-term key. This is
beneficial, because active attacks demand much more resources to beneficial because active attacks demand many more resources to
launch, and are easier to detect. As with other protocols, an active launch and are easier to detect. As with other protocols, an active
attacker with access to the long-term key material will of course be attacker with access to the long-term key material will, of course,
able to attack all future communications, but risks detection, be able to attack all future communications, but risks detection,
particularly if done at scale. particularly if done at scale.
It should also be noted that 5G network architecture [TS.33.501] It should also be noted that 5G network architecture [TS.33.501]
includes the use of the EAP framework for authentication. While any includes the use of the EAP framework for authentication. While any
methods can be run, the default authentication method within that methods can be run, the default authentication method within that
context will be EAP-AKA'. As a result, improvements in EAP-AKA' context will be EAP-AKA'. As a result, improvements in EAP-AKA'
security have a potential to improve security for many users. security have the potential to improve security for many users.
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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Protocol Design and Deployment Objectives 3. Protocol Design and Deployment Objectives
The extension specified here re-uses large portions of the current The extension specified here reuses large portions of the current
structure of 3GPP interfaces and functions, with the rationale that structure of 3GPP interfaces and functions, with the rationale that
this will make the construction more easily adopted. In particular, this will make the construction more easily adopted. In particular,
the construction keeps the interface between the USIM and the mobile the construction keeps the interface between the USIM and the mobile
terminal intact. As a consequence, there is no need to roll out new terminal intact. As a consequence, there is no need to roll out new
credentials to existing subscribers. The work is based on an earlier credentials to existing subscribers. The work is based on an earlier
paper [TrustCom2015], and uses much of the same material, but applied paper (see [TrustCom2015]) and uses much of the same material but is
to EAP rather than the underlying AKA method. applied to EAP rather than the underlying AKA method.
It has been a goal to implement this change as an extension of the It has been a goal to implement this change as an extension of the
widely supported EAP-AKA' method, rather than a completely new widely supported EAP-AKA' method, rather than implement a completely
authentication method. The extension is implemented as a set of new, new authentication method. The extension is implemented as a set of
optional attributes, that are provided alongside the base attributes new, optional attributes that are provided alongside the base
in EAP-AKA'. Old implementations can ignore these attributes, but attributes in EAP-AKA'. Old implementations can ignore these
their presence will nevertheless be verified as part of base EAP-AKA' attributes, but their presence will nevertheless be verified as part
integrity verification process, helping protect against bidding down of the base EAP-AKA' integrity verification process, helping protect
attacks. This extension does not increase the number of rounds against bidding down attacks. This extension does not increase the
necessary to complete the protocol. number of rounds necessary to complete the protocol.
The use of this extension is at the discretion of the authenticating The use of this extension is at the discretion of the authenticating
parties. It should be noted that FS and defenses against passive parties. It should be noted that FS and defenses against passive
attacks do not solve all problems, but they can provide a partial attacks do not solve all problems, but they can provide a partial
defense that increases the cost and risk associated with pervasive defense that increases the cost and risk associated with pervasive
surveillance. surveillance.
While adding forward secrecy to the existing mobile network While adding FS to the existing mobile network infrastructure can be
infrastructure can be done in multiple different ways, this document done in multiple different ways, this document specifies a solution
specifies a solution that is relatively easily deployable. In that is relatively easy to deploy. In particular:
particular:
* As noted above, no new credentials are needed; there is no change * As noted above, no new credentials are needed; there is no change
to USIM cards. to USIM cards.
* FS property can be incorporated into any current or future system * FS property can be incorporated into any current or future system
that supports EAP, without changing any network functions beyond that supports EAP, without changing any network functions beyond
the EAP endpoints. the EAP endpoints.
* Key generation happens at the endpoints, enabling highest grade * Key generation happens at the endpoints, enabling the highest
key material to be used both by the endpoints and the intermediate grade key material to be used both by the endpoints and the
systems (such as access points that are given access to specific intermediate systems (such as access points that are given access
keys). to specific keys).
* While EAP-AKA' is just one EAP method, for practical purposes * While EAP-AKA' is just one EAP method, for practical purposes, FS
forward secrecy being available for both EAP-TLS [RFC5216] being available for both EAP-TLS [RFC5216] [RFC9190] and EAP-AKA'
[RFC9190] and EAP-AKA' ensures that for many practical systems ensures that, for many practical systems, FS can be enabled for
forward secrecy can be enabled for either all or significant either all or a significant fraction of users.
fraction of users.
4. Background 4. Background
The reader is assumed to have basic understanding of the EAP The reader is assumed to have a basic understanding of the EAP
framework [RFC3748]. framework [RFC3748].
4.1. AKA 4.1. AKA
We use the term Authentication and Key Agreement (AKA) for the main We use the term "Authentication and Key Agreement" (or "AKA") for the
authentication and key agreement protocol used by 3GPP mobile main authentication and key agreement protocol used by 3GPP mobile
networks from the third generation (3G) and onward. Later networks from the third generation (3G) and onward. Later
generations adds new features to AKA, but the core remains the same. generations add new features to AKA, but the core remains the same.
It is based on challenge-response mechanisms and symmetric It is based on challenge-response mechanisms and symmetric
cryptography. In contrast to its earlier GSM counterparts, AKA cryptography. In contrast to its earlier GSM counterparts, AKA
provides long key lengths and mutual authentication. The phone provides long key lengths and mutual authentication. The phone
typically executes AKA in a USIM. USIM is technically just an typically executes AKA in a USIM. A USIM is technically just an
application that can reside on a removable UICC (Universal Integrated application that can reside on a removable Universal Integrated
Circuit Card), an embedded UICC, or integrated in a Trusted Execution Circuit Card (UICC), an embedded UICC, or integrated in a Trusted
Environment (TEE). In this document we use the term "USIM card" to Execution Environment (TEE). In this document, we use the term "USIM
refer to any Subscriber Identity Module capable of running AKA. card" to refer to any Subscriber Identity Module (SIM) capable of
running AKA.
The goal of AKA is to mutually authenticate the USIM and the so- The goal of AKA is to mutually authenticate the USIM and the so-
called home environment, which is the authentication server in the called home environment, which is the authentication server in the
subscribers home operator's network. subscribers home operator's network.
AKA works in the following manner: AKA works in the following manner:
* The USIM and the home environment have agreed on a long-term * The USIM and the home environment have agreed on a long-term
symmetric key beforehand. symmetric key beforehand.
skipping to change at page 6, line 43 skipping to change at line 272
* The serving network verifies that the result from the USIM matches * The serving network verifies that the result from the USIM matches
the expected value in the authentication vector. If it does, the the expected value in the authentication vector. If it does, the
USIM is considered authenticated, and IK and CK can be used to USIM is considered authenticated, and IK and CK can be used to
protect further communications between the USIM and the home protect further communications between the USIM and the home
environment. environment.
4.2. EAP-AKA' Protocol 4.2. EAP-AKA' Protocol
When AKA is embedded into EAP, the authentication processing on the When AKA is embedded into EAP, the authentication processing on the
network side is moved to the home environment. The 3GPP network side is moved to the home environment. The 3GPP
authentication database (AD) generates authentication vectors. The Authentication Database (AD) generates authentication vectors. The
3GPP authentication server takes the role of EAP server. The USIM 3GPP authentication server takes the role of EAP server. The USIM
combined with the mobile phone takes the role of the client. The combined with the mobile phone takes the role of client. The
difference between EAP-AKA [RFC4187] and EAP-AKA' [RFC9048] is that difference between EAP-AKA [RFC4187] and EAP-AKA' [RFC9048] is that
EAP-AKA' binds the derived keys to the name of access network. EAP-AKA' binds the derived keys to the name of the access network.
Figure 1 describes the basic flow in the EAP-AKA' authentication Figure 1 describes the basic flow in the EAP-AKA' authentication
process. The definition of the full protocol behavior, along with process. The definition of the full protocol behavior, along with
the definition of attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES can the definition of the attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES
be found in [RFC9048] and [RFC4187]. Note the use of EAP-terminology can be found in [RFC9048] and [RFC4187]. Note the use of EAP
from hereon. That is, the 3GPP serving network takes on the role of terminology from hereon. That is, the 3GPP serving network takes on
an EAP access network. the role of an EAP access network.
Peer Server Peer Server
| | | |
| EAP-Request/Identity | | EAP-Request/Identity |
|<-----------------------------------------------------------+ |<-----------------------------------------------------------+
| | | |
| EAP-Response/Identity | | EAP-Response/Identity |
| (Includes user's Network Access Identifier, NAI) | | (Includes user's Network Access Identifier (NAI)) |
+----------------------------------------------------------->| +----------------------------------------------------------->|
| +-----------------------------------------------------+--+ | +-----------------------------------------------------+--+
| | Server determines the network name and ensures that | | | Server determines the network name and ensures that |
| | the given access network is authorized to use the | | | the given access network is authorized to use the |
| | claimed name. The server then runs the AKA' algorithms | | | claimed name. The server then runs the AKA' algorithms |
| | generating RAND and AUTN, derives session keys from | | | generating RAND and AUTN, derives session keys from |
| | CK' and IK'. RAND and AUTN are sent as AT_RAND and | | | CK' and IK'. RAND and AUTN are sent as AT_RAND and |
| | AT_AUTN attributes, whereas the network name is | | | AT_AUTN attributes, whereas the network name is |
| | transported in the AT_KDF_INPUT attribute. AT_KDF | | | transported in the AT_KDF_INPUT attribute. AT_KDF |
| | signals the used key derivation function. The session | | | signals the used key derivation function. The session |
skipping to change at page 8, line 19 skipping to change at line 345
Figure 1: EAP-AKA' Authentication Process Figure 1: EAP-AKA' Authentication Process
4.3. Attacks Against Long-Term Keys in Smart Cards 4.3. Attacks Against Long-Term Keys in Smart Cards
The general security properties and potential vulnerabilities of AKA The general security properties and potential vulnerabilities of AKA
and EAP-AKA' are discussed in [RFC9048]. and EAP-AKA' are discussed in [RFC9048].
An important question in that discussion relates to the potential An important question in that discussion relates to the potential
compromise of long-term keys, as discussed earlier. Attacks on long- compromise of long-term keys, as discussed earlier. Attacks on long-
term keys are not specific to AKA or EAP-AKA', and all security term keys are not specific to AKA or EAP-AKA', and all security
systems fail at least to some extent if key material is stolen. systems fail, at least to some extent, if key material is stolen.
However, it would be preferable to retain some security even in the However, it would be preferable to retain some security even in the
face of such attacks. This document specifies a mechanism that face of such attacks. This document specifies a mechanism that
reduces risks to compromise of key material belonging to previous reduces risks to compromise of key material belonging to previous
sessions, before the long-term keys were compromised. It also forces sessions, before the long-term keys were compromised. It also forces
attackers to be active even after the compromise. attackers to be active even after the compromise.
5. Protocol Overview 5. Protocol Overview
Forward secrecy for EAP-AKA' is achieved by using an Elliptic Curve Forward Secrecy (FS) for EAP-AKA' is achieved by using an Elliptic
Diffie-Hellman (ECDH) exchange [RFC7748]. To provide FS, the Curve Diffie-Hellman (ECDH) exchange [RFC7748]. To provide FS, the
exchange must be run in an ephemeral manner, i.e., both sides exchange must be run in an ephemeral manner, i.e., both sides
generate temporary keys according to the negotiated ciphersuite, generate temporary keys according to the negotiated ciphersuite. For
e.g., for X25519 this is done as specified in [RFC7748]. This method example, for X25519, this is done as specified in [RFC7748]. This
is referred to as ECDHE, where the last 'E' stands for Ephemeral. method is referred to as "ECDHE", where the last "E" stands for
The two initially registered elliptic curves and their wire formats "Ephemeral". The two initially registered elliptic curves and their
are chosen to align with the elliptic curves and formats specified wire formats are chosen to align with the elliptic curves and formats
for Subscription Concealed Identifier (SUCI) encryption in specified for Subscription Concealed Identifier (SUCI) encryption in
Appendix C.3.4 of 3GPP TS 33.501 [TS.33.501]. Appendix C.3.4 of 3GPP [TS.33.501].
The enhancements in the EAP-AKA' FS protocol are compatible with the The enhancements in the EAP-AKA' FS protocol are compatible with the
signaling flow and other basic structures of both AKA and EAP-AKA'. signaling flow and other basic structures of both AKA and EAP-AKA'.
The intent is to implement the enhancement as optional attributes The intent is to implement the enhancement as optional attributes
that legacy implementations ignore. that legacy implementations ignore.
The purpose of the protocol is to achieve mutual authentication The purpose of the protocol is to achieve mutual authentication
between the EAP server and peer, and to establish keying material for between the EAP server and peer and to establish keying material for
secure communication between the two. This document specifies the secure communication between the two. This document specifies the
calculation of key material, providing new properties that are not calculation of key material, providing new properties that are not
present in key material provided by EAP-AKA' in its original form. present in key material provided by EAP-AKA' in its original form.
Figure 2 below describes the overall process. Since the goal has Figure 2 describes the overall process. Since the goal has been to
been to not require new infrastructure or credentials, the flow not require new infrastructure or credentials, the flow diagrams also
diagrams also show the conceptual interaction with the USIM card and show the conceptual interaction with the USIM card and the home
the home environment. Recall that the home environment represent the environment. Recall that the home environment represents the 3GPP
3GPP Authentication Database (AD) and server. The details of those Authentication Database (AD) and server. The details of those
interactions are outside the scope of this document, however, and the interactions are outside the scope of this document, however, and the
reader is referred to the 3GPP specifications. For 5G this is reader is referred to the 3GPP specifications. For 5G, this is
specified in 3GPP TS 33.501 [TS.33.501] specified in 3GPP [TS.33.501].
USIM Peer Server AD USIM Peer Server AD
| | | | | | | |
| | EAP-Req/Identity | | | | EAP-Req/Identity | |
| |<---------------------------+ | | |<---------------------------+ |
| | | | | | | |
| | EAP-Resp/Identity | | | | EAP-Resp/Identity | |
| | (Privacy-Friendly) | | | | (Privacy-Friendly) | |
| +--------------------------->| | | +--------------------------->| |
| +-------+----------------------------+----------------+--+ | +-------+----------------------------+----------------+--+
skipping to change at page 11, line 4 skipping to change at line 471
| | and the ECDHE value. Even if there was an attacker who | | | and the ECDHE value. Even if there was an attacker who |
| | held the long-term key, only an active attacker could | | | held the long-term key, only an active attacker could |
| | have determined the generated session keys; in basic | | | have determined the generated session keys; in basic |
| | EAP-AKA' the generated keys are only based on CK and | | | EAP-AKA' the generated keys are only based on CK and |
| | IK. | | | IK. |
| +-------+----------------------------+----------------+--+ | +-------+----------------------------+----------------+--+
| | | | | | | |
| | EAP-Success | | | | EAP-Success | |
| |<---------------------------+ | | |<---------------------------+ |
| | | | | | | |
Figure 2: EAP-AKA' FS Authentication Process Figure 2: EAP-AKA' FS Authentication Process
6. Extensions to EAP-AKA' 6. Extensions to EAP-AKA'
6.1. AT_PUB_ECDHE 6.1. AT_PUB_ECDHE
The AT_PUB_ECDHE carries an ECDHE value. The AT_PUB_ECDHE attribute carries an ECDHE value.
The format of the AT_PUB_ECDHE attribute is shown below. The format of the AT_PUB_ECDHE attribute is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_PUB_ECDHE | Length | Value | | AT_PUB_ECDHE | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows: The fields are as follows:
AT_PUB_ECDHE AT_PUB_ECDHE:
This is set to TBA1 BY IANA. This is set to 152 by IANA.
Length Length:
The length of the attribute, set as other attributes in EAP-AKA This is the length of the attribute, set as other attributes in
[RFC4187]. The length is expressed in multiples of 4 bytes. The EAP-AKA [RFC4187]. The length is expressed in multiples of 4
length includes the attribute type field, the Length field itself, bytes. The length includes the attribute type field, the Length
and the Value field (along with any padding). field itself, and the Value field (along with any padding).
Value Value:
This value is the sender's ECDHE public key. The value depends on This value is the sender's ECDHE public key. The value depends on
AT_KDF_FS and is calculated as follows: the AT_KDF_FS attribute and is calculated as follows:
* For X25519, the length of this value is 32 bytes, encoded as * For X25519, the length of this value is 32 bytes, encoded as
specified in [RFC7748] Section 5. specified in Section 5 of [RFC7748].
* For P-256, the length of this value is 33 bytes, encoded using * For P-256, the length of this value is 33 bytes, encoded using
the compressed form specified in Section 2.3.3 of [SEC1]. the compressed form specified in Section 2.3.3 of [SEC1].
Because the length of the attribute must be a multiple of 4 bytes, Because the length of the attribute must be a multiple of 4 bytes,
the sender pads the Value field with zero bytes when necessary. the sender pads the Value field with zero bytes when necessary.
To retain the security of the keys, the sender SHALL generate a To retain the security of the keys, the sender SHALL generate a
fresh value for each run of the protocol. fresh value for each run of the protocol.
6.2. AT_KDF_FS 6.2. AT_KDF_FS
The AT_KDF_FS indicates the used or desired forward secrecy key The AT_KDF_FS attribute indicates the used or desired FS key
generation function, if the Forward Secrecy (FS) extension is used. generation function, if the FS extension is used. It will also
It will also indicate the used or desired ECDHE group. A new indicate the used or desired ECDHE group. A new attribute is needed
attribute is needed to carry this information, as AT_KDF carries the to carry this information, as AT_KDF carries the basic KDF value that
basic KDF value which is still used together with the forward secrecy is still used together with the FS KDF value. The basic KDF value is
KDF value. The basic KDF value is also used by those EAP peers that also used by those EAP peers that cannot or do not want to use this
cannot or do not want to use this extension. extension.
This document only specifies the behavior relating to the following This document only specifies the behavior relating to the following
combinations of basic KDF values and forward secrecy KDF values: The combinations of basic KDF values and FS KDF values:
basic KDF value in AT_KDF is 1, as specified in [RFC5448] and
[RFC9048], and the forward secrecy KDF values in AT_KDF_FS are 1 or
2, as specified below and in Section 6.3.
Any future specifications that add either new basic KDF or new * the basic KDF value in AT_KDF is 1, as specified in [RFC5448] and
forward secrecy KDF values need to specify how they are treated and [RFC9048] and
what combinations are allowed. This requirement is an update to how
[RFC5448] and [RFC9048] may be extended in the future. * the FS KDF values in AT_KDF_FS are 1 or 2, as specified below and
in Section 6.3.
Any future specifications that add either new basic KDFs or new FS
KDF values need to specify how they are treated and what combinations
are allowed. This requirement is an update to how [RFC5448] and
[RFC9048] may be extended in the future.
The format of the AT_KDF_FS attribute is shown below. The format of the AT_KDF_FS attribute is shown below.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF_FS | Length | FS Key Derivation Function | | AT_KDF_FS | Length | FS Key Derivation Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows: The fields are as follows:
AT_KDF_FS AT_KDF_FS:
This is set to TBA2 BY IANA. This is set to 153 by IANA.
Length Length:
The length of the attribute, MUST be set to 1. This is the length of the attribute; it MUST be set to 1.
FS Key Derivation Function FS Key Derivation Function:
An enumerated value representing the forward secrecy key This is an enumerated value representing the FS KDF that the
derivation function that the server (or peer) wishes to use. See server (or peer) wishes to use. See Section 6.3 for the functions
Section 6.3 for the functions specified in this document. Note: specified in this document. Note: this field has a different name
This field has a different name space than the similar field in space than the similar field in the AT_KDF attribute KDF defined
the AT_KDF attribute Key Derivation Function defined in [RFC9048]. in [RFC9048].
Servers MUST send one or more AT_KDF_FS attributes in the EAP- Servers MUST send one or more AT_KDF_FS attributes in the EAP-
Request/AKA'-Challenge message. These attributes represent the Request/AKA'-Challenge message. These attributes represent the
desired functions ordered by preference, the most preferred function desired functions ordered by preference, with the most preferred
being the first attribute. The most preferred function is the only function being the first attribute. The most preferred function is
one that the server includes a public key value for, however. So for the only one that the server includes a public key value for,
a set of AT_KDF_FS attributes, there is always only one AT_PUB_ECDHE however. So, for a set of AT_KDF_FS attributes, there is always only
attribute. one AT_PUB_ECDHE attribute.
Upon receiving a set of these attributes: Upon receiving a set of these attributes:
* If the peer supports and is willing to use the FS Key Derivation * If the peer supports and is willing to use the FS KDF indicated by
Function indicated by the first AT_KDF_FS attribute, and is the first AT_KDF_FS attribute, and is willing and able to use the
willing and able to use the extension defined in this document, extension defined in this document, the function is taken into use
the function is taken into use without any further negotiation. without any further negotiation.
* If the peer does not support this function or is unwilling to use * If the peer does not support this function or is unwilling to use
it, it responds to the server with an indication that a different it, it responds to the server with an indication that a different
function is needed. Similarly with the negotiation process function is needed. Similarly, with the negotiation process
defined in [RFC9048] for AT_KDF, the peer sends EAP-Response/AKA'- defined in [RFC9048] for AT_KDF, the peer sends an EAP-Response/
Challenge message that contains only one attribute, AT_KDF_FS with AKA'-Challenge message that contains only one attribute,
the value set to the desired alternative function from among the AT_KDF_FS, with the value set to the desired alternative function
ones suggested by the server earlier. If there is no suitable from among the ones suggested by the server earlier. If there is
alternative, the peer has a choice of either falling back to EAP- no suitable alternative, the peer has a choice of either falling
AKA' or behaving as if AUTN had been incorrect and failing back to EAP-AKA' or behaving as if AUTN had been incorrect and
authentication (see Figure 3 of [RFC4187]). The peer MUST fail failing authentication (see Figure 3 of [RFC4187]). The peer MUST
the authentication if there are any duplicate values within the fail the authentication if there are any duplicate values within
list of AT_KDF_FS attributes (except where the duplication is due the list of AT_KDF_FS attributes (except where the duplication is
to a request to change the key derivation function; see below for due to a request to change the key derivation function; see below
further information). for further information).
* If the peer does not recognize the extension defined in this * If the peer does not recognize the extension defined in this
document or is unwilling to use it, it ignores the AT_KDF_FS document or is unwilling to use it, it ignores the AT_KDF_FS
attribute. attribute.
Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF_FS from the Upon receiving an EAP-Response/AKA'-Challenge message with an
peer, the server checks that the suggested AT_KDF_FS value was one of AT_KDF_FS attribute from the peer, the server checks that the
the alternatives in its offer. The first AT_KDF_FS value in the suggested AT_KDF_FS value was one of the alternatives in its offer.
message from the server is not a valid alternative. If the peer has The first AT_KDF_FS value in the message from the server is not a
replied with the first AT_KDF_FS value, the server behaves as if valid alternative. If the peer has replied with the first AT_KDF_FS
AT_MAC of the response had been incorrect and fails the value, the server behaves as if the AT_MAC of the response had been
authentication. For an overview of the failed authentication process incorrect and fails the authentication. For an overview of the
in the server side, see Section 3 and Figure 2 in [RFC4187]. failed authentication process in the server side, see Section 3 and
Otherwise, the server re-sends the EAP-Response/AKA'-Challenge Figure 2 in [RFC4187]. Otherwise, the server re-sends the EAP-
message, but adds the selected alternative to the beginning of the Response/AKA'-Challenge message, but adds the selected alternative to
list of AT_KDF_FS attributes, and retains the entire list following the beginning of the list of AT_KDF_FS attributes and retains the
it. Note that this means that the selected alternative appears twice entire list following it. Note that this means that the selected
in the set of AT_KDF values. Responding to the peer's request to alternative appears twice in the set of AT_KDF values. Responding to
change the FS Key Derivation Function is the only valid situation the peer's request to change the FS KDF is the only valid situation
where such duplication may occur. where such duplication may occur.
When the peer receives the new EAP-Request/AKA'-Challenge message, it When the peer receives the new EAP-Request/AKA'-Challenge message, it
MUST check that the requested change, and only the requested change MUST check that the requested change, and only the requested change,
occurred in the list of AT_KDF_FS attributes. If yes, it continues. occurred in the list of AT_KDF_FS attributes. If so, it continues.
If not, it behaves as if AT_MAC had been incorrect and fails the If not, it behaves as if AT_MAC were incorrect and fails the
authentication. If the peer receives multiple EAP-Request/AKA'- authentication. If the peer receives multiple EAP-Request/AKA'-
Challenge messages with differing AT_KDF_FS attributes without having Challenge messages with differing AT_KDF_FS attributes without having
requested negotiation, the peer MUST behave as if AT_MAC had been requested negotiation, the peer MUST behave as if AT_MAC were
incorrect and fail the authentication. incorrect and fail the authentication.
6.3. Forward Secrecy Key Derivation Functions 6.3. Forward Secrecy Key Derivation Functions
Two new FS Key Derivation Function types are defined for "EAP-AKA' Two new FS KDF types are defined for "EAP-AKA' with ECDHE and
with ECDHE and X25519", represented by value 1, and "EAP-AKA' with X25519", represented by value 1, and "EAP-AKA' with ECDHE and P-256",
ECDHE and P-256", represented by value 2. These represent a represented by value 2. These values represent a particular choice
particular choice of key derivation function and at the same time of KDF and, at the same time, select an ECDHE group to be used.
selects an ECDHE group to be used.
The FS Key Derivation Function type value is only used in the The FS KDF type value is only used in the AT_KDF_FS attribute. When
AT_KDF_FS attribute. When the forward secrecy extension is used, the the FS extension is used, the AT_KDF_FS attribute determines how to
AT_KDF_FS attribute determines how to derive the keys MK_ECDHE, K_re, derive the MK_ECDHE key, K_re key, Master Session Key (MSK), and
MSK, and EMSK. The AT_KDF_FS attribute should not be confused with Extended Master Session Key (EMSK). The AT_KDF_FS attribute should
the different range of key derivation functions that can be not be confused with the different range of KDFs that can be
represented in the AT_KDF attribute as defined in [RFC9048]. When represented in the AT_KDF attribute as defined in [RFC9048]. When
the forward secrecy extension is used, the AT_KDF attribute only the FS extension is used, the AT_KDF attribute only specifies how to
specifies how to derive the keys MK, K_encr, and K_aut. derive the Master Key (MK), the K_encr key, and the K_aut key.
Key derivation in this extension produces exactly the same keys for Key derivation in this extension produces exactly the same keys for
internal use within one authentication run as EAP-AKA' [RFC9048] internal use within one authentication run as EAP-AKA' [RFC9048]
does. For instance, K_aut that is used in AT_MAC is still exactly as does. For instance, the K_aut that is used in AT_MAC is still
it was in EAP-AKA'. The only change to key derivation is in re- exactly as it was in EAP-AKA'. The only change to key derivation is
authentication keys and keys exported out of the EAP method, MSK and in the re-authentication keys and keys exported out of the EAP
EMSK. As a result, EAP-AKA' attributes such as AT_MAC continue to be method, MSK and EMSK. As a result, EAP-AKA' attributes such as
usable even when this extension is in use. AT_MAC continue to be usable even when this extension is in use.
When the FS Key Derivation Function field in the AT_KDF_FS attribute When the FS KDF field in the AT_KDF_FS attribute is set to 1 or 2 and
is set to 1 or 2 and the Key Derivation Function field in the AT_KDF the Key Derivation Function field in the AT_KDF attribute is set to
attribute is set to 1, the Master Key (MK) and accompanying keys are 1, the MK and accompanying keys are derived as follows:
derived as follows.
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity) MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)
K_encr = MK[0..127] K_encr = MK[0..127]
K_aut = MK[128..383] K_aut = MK[128..383]
K_re = MK_ECDHE[0..255] K_re = MK_ECDHE[0..255]
MSK = MK_ECDHE[256..767] MSK = MK_ECDHE[256..767]
EMSK = MK_ECDHE[768..1279] EMSK = MK_ECDHE[768..1279]
Requirements for how to securely generate, validate, and process the Requirements for how to securely generate, validate, and process the
ephemeral public keys depend on the elliptic curve. ephemeral public keys depend on the elliptic curve.
For P-256 the SHARED_SECRET is the shared secret computed as For P-256, the SHARED_SECRET is the shared secret computed as
specified in Section 5.7.1.2 of [SP-800-56A]. Public key validation specified in Section 5.7.1.2 of [SP-800-56A]. Public key validation
requirements are defined in Section 5 of [SP-800-56A]. At least requirements are defined in Section 5 of [SP-800-56A]. At least
partial public-key validation MUST be done for the ephemeral public partial public key validation MUST be done for the ephemeral public
keys. The uncompressed y-coordinate can be computed as described in keys. The uncompressed y-coordinate can be computed as described in
Section 2.3.4 of [SEC1]. Section 2.3.4 of [SEC1].
For X25519 the SHARED_SECRET is the shared secret computed as For X25519, the SHARED_SECRET is the shared secret computed as
specified in Section 6.1 of [RFC7748]. Both the peer and the server specified in Section 6.1 of [RFC7748]. Both the peer and the server
MAY check for zero-value shared secret as specified in Section 6.1 of MAY check for the zero-value shared secret as specified in
[RFC7748]. Section 6.1 of [RFC7748].
Note: The way that shared secret is tested for zero can, if | Note: If performed inappropriately, the way that the shared
performed inappropriately, provide an ability for attackers to | secret is tested for zero can provide an ability for attackers
listen to CPU power usage side channels. Refer to [RFC7748] for a | to listen to CPU power usage side channels. Refer to [RFC7748]
description of how to perform this check in a way that it does not | for a description of how to perform this check in a way that it
become a problem. | does not become a problem.
If validation of the other party's ephemeral public key or the shared If validation of the other party's ephemeral public key or the shared
secret fails, a party MUST behave as if the current EAP-AKA' secret fails, a party MUST behave as if the current EAP-AKA'
authentication process starts again from the beginning. authentication process starts again from the beginning.
The rest of computation proceeds as defined in Section 3.3 of The rest of the computation proceeds as defined in Section 3.3 of
[RFC9048]. [RFC9048].
For readability, an explanation of the notation used above is copied For readability, an explanation of the notation used above is copied
here: [n..m] denotes the substring from bit n to m. PRF' is a new here: [n..m] denotes the substring from bit n to m. PRF' is a new
pseudo-random function specified in [RFC9048]. K_encr is the pseudorandom function specified in [RFC9048]. K_encr is the
encryption key, 128 bits, K_aut is the authentication key, 256 bits, encryption key, 128 bits, K_aut is the authentication key, 256 bits,
K_re is the re-authentication key, 256 bits, MSK is the Master K_re is the re-authentication key, 256 bits, MSK is the Master
Session Key, 512 bits, and EMSK is the Extended Master Session Key, Session Key, 512 bits, and EMSK is the Extended Master Session Key,
512 bits. MSK and EMSK are outputs from a successful EAP method run 512 bits. MSK and EMSK are outputs from a successful EAP method run
[RFC3748]. [RFC3748].
CK and IK are produced by the AKA algorithm. IK' and CK' are derived CK and IK are produced by the AKA algorithm. IK' and CK' are derived
as specified in [RFC9048] from IK and CK. as specified in [RFC9048] from IK and CK.
The value "EAP-AKA'" is an eight-characters-long ASCII string. It is The value "EAP-AKA'" is an ASCII string that is 8 characters long.
used as is, without any trailing NUL characters. Similarly, "EAP- It is used as is, without any trailing NUL characters. Similarly,
AKA' FS" is an eleven-characters-long ASCII string, also used as is. "EAP-AKA' FS" is an ASCII string that is 11 characters long, also
used as is.
Identity is the peer identity as specified in Section 7 of [RFC4187]. Identity is the peer identity as specified in Section 7 of [RFC4187].
A privacy-friendly identifier [RFC9048] SHALL be used. A privacy-friendly identifier [RFC9048] SHALL be used.
6.4. ECDHE Groups 6.4. ECDHE Groups
The selection of suitable groups for the elliptic curve computation The selection of suitable groups for the elliptic curve computation
is necessary. The choice of a group is made at the same time as is necessary. The choice of a group is made at the same time as the
deciding to use of particular key derivation function in AT_KDF_FS. decision to use a particular KDF in the AT_KDF_FS attribute.
For "EAP-AKA' with ECDHE and X25519" the group is the Curve25519 For "EAP-AKA' with ECDHE and X25519", the group is the Curve25519
group specified in [RFC7748]. The support for this group is group specified in [RFC7748]. The support for this group is
REQUIRED. REQUIRED.
For "EAP-AKA' with ECDHE and P-256" the group is the NIST P-256 group For "EAP-AKA' with ECDHE and P-256", the group is the NIST P-256
(SEC group secp256r1), specified in Section 3.2.1.3 of [SP-800-186] group (SEC group secp256r1), specified in Section 3.2.1.3 of
or alternatively Section 2.4.2 of [SEC2]. The support for this group [SP-800-186] or alternatively, Section 2.4.2 of [SEC2]. The support
is REQUIRED. for this group is REQUIRED.
The term "support" here means that the group MUST be implemented. The term "support" here means that the group MUST be implemented.
6.5. Message Processing 6.5. Message Processing
This section specifies the changes related to message processing when This section specifies the changes related to message processing when
this extension is used in EAP-AKA'. It specifies when a message may this extension is used in EAP-AKA'. It specifies when a message may
be transmitted or accepted, which attributes are allowed in a be transmitted or accepted, which attributes are allowed in a
message, which attributes are required in a message, and other message, which attributes are required in a message, and other
message-specific details, where those details are different for this message-specific details, where those details are different for this
skipping to change at page 17, line 13 skipping to change at line 755
using a non-NULL SUCI [TS.33.501]. using a non-NULL SUCI [TS.33.501].
6.5.3. EAP-Request/AKA'-Challenge 6.5.3. EAP-Request/AKA'-Challenge
The server sends the EAP-Request/AKA'-Challenge on full The server sends the EAP-Request/AKA'-Challenge on full
authentication as specified by [RFC4187] and [RFC9048]. The authentication as specified by [RFC4187] and [RFC9048]. The
attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked
on reception as specified in [RFC4187]. They are also necessary for on reception as specified in [RFC4187]. They are also necessary for
backwards compatibility. backwards compatibility.
In EAP-Request/AKA'-Challenge, there is no message-specific data In the EAP-Request/AKA'-Challenge, there is no message-specific data
covered by the MAC for the AT_MAC attribute. The AT_KDF_FS and covered by the MAC for the AT_MAC attribute. The AT_KDF_FS and
AT_PUB_ECDHE attributes MUST be included. The AT_PUB_ECDHE attribute AT_PUB_ECDHE attributes MUST be included. The AT_PUB_ECDHE attribute
carries the server's public Diffie-Hellman key. If either AT_KDF_FS carries the server's public Diffie-Hellman key. If either AT_KDF_FS
or AT_PUB_ECDHE is missing on reception, the peer MUST treat it as if or AT_PUB_ECDHE is missing on reception, the peer MUST treat it as if
neither one was sent, and the assume that the extension defined in neither one was sent and assume that the extension defined in this
this document is not in use. document is not in use.
The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING, The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING,
AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID and other attributes may be AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID, and other attributes may be
included as specified in Section 9.3 of [RFC4187]. included as specified in Section 9.3 of [RFC4187].
When processing this message, the peer MUST process AT_RAND, AT_AUTN, When processing this message, the peer MUST process AT_RAND, AT_AUTN,
AT_KDF_FS, AT_PUB_ECDHE before processing other attributes. Only if AT_KDF_FS, and AT_PUB_ECDHE before processing other attributes. The
these attributes are verified to be valid, the peer derives keys and peer derives keys and verifies AT_MAC only if these attributes are
verifies AT_MAC. If the peer is unable or unwilling to perform the verified to be valid. If the peer is unable or unwilling to perform
extension specified in this document, it proceeds as defined in the extension specified in this document, it proceeds as defined in
[RFC9048]. Finally, if there is an error error, see Section 6.3.1. [RFC9048]. Finally, if there is an error, see Section 6.3.1 of
of [RFC4187]. [RFC4187].
6.5.4. EAP-Response/AKA'-Challenge 6.5.4. EAP-Response/AKA'-Challenge
The peer sends EAP-Response/AKA'-Challenge in response to a valid The peer sends an EAP-Response/AKA'-Challenge in response to a valid
EAP-Request/AKA'-Challenge message, as specified by [RFC4187] and EAP-Request/AKA'-Challenge message, as specified by [RFC4187] and
[RFC9048]. If the peer supports and is willing to perform the [RFC9048]. If the peer supports and is willing to perform the
extension specified in this protocol, and the server had made a valid extension specified in this protocol, and the server had made a valid
request involving the attributes specified in Section 6.5.3, the peer request involving the attributes specified in Section 6.5.3, the peer
responds per the rules specified below. Otherwise, the peer responds responds per the rules specified below. Otherwise, the peer responds
as specified in [RFC4187] and [RFC9048] and ignores the attributes as specified in [RFC4187] and [RFC9048] and ignores the attributes
related to this extension. If the peer has not received attributes related to this extension. If the peer has not received attributes
related to this extension from the Server, and has a policy that related to this extension from the Server, and has a policy that
requires it to always use this extension, it behaves as if AUTN had requires it to always use this extension, it behaves as if AUTN were
been incorrect and fails the authentication. incorrect and fails the authentication.
The AT_MAC attribute MUST be included and checked as specified in The AT_MAC attribute MUST be included and checked as specified in
[RFC9048]. In EAP-Response/AKA'-Challenge, there is no message- [RFC9048]. In the EAP-Response/AKA'-Challenge, there is no message-
specific data covered by the MAC. The AT_PUB_ECDHE attribute MUST be specific data covered by the MAC. The AT_PUB_ECDHE attribute MUST be
included, and carries the peer's public Diffie-Hellman key. included and carries the peer's public Diffie-Hellman key.
The AT_RES attribute MUST be included and checked as specified in The AT_RES attribute MUST be included and checked as specified in
[RFC4187]. When processing this message, the Server MUST process [RFC4187]. When processing this message, the Server MUST process
AT_RES before processing other attributes. The Server derives keys AT_RES before processing other attributes. The Server derives keys
and verifies AT_MAC only when this attribute is verified to be valid. and verifies AT_MAC only when this attribute is verified to be valid.
If the Server has proposed the use of the extension specified in this If the Server has proposed the use of the extension specified in this
protocol, but the peer ignores and continues the basic EAP-AKA' protocol, but the peer ignores and continues the basic EAP-AKA'
authentication, the Server makes policy decision of whether this is authentication, the Server makes a policy decision of whether this is
allowed. If this is allowed, it continues the EAP-AKA' allowed. If this is allowed, it continues the EAP-AKA'
authentication to completion. If it is not allowed, the Server MUST authentication to completion. If it is not allowed, the Server MUST
behave as if authentication failed. behave as if authentication failed.
The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA and other The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA, and other
attributes may be included as specified in Section 9.4 of [RFC4187]. attributes may be included as specified in Section 9.4 of [RFC4187].
6.5.5. EAP-Request/AKA'-Reauthentication 6.5.5. EAP-Request/AKA'-Reauthentication
No changes, but note that the re-authentication process uses the keys No changes, but note that the re-authentication process uses the keys
generated in the original EAP-AKA' authentication, which, if the generated in the original EAP-AKA' authentication, which employs key
extension specified in this document is in use, employs key material material from the Diffie-Hellman procedure if the extension specified
from the Diffie-Hellman procedure. in this document is in use.
6.5.6. EAP-Response/AKA'-Reauthentication 6.5.6. EAP-Response/AKA'-Reauthentication
No changes, but as discussed in Section 6.5.5, re-authentication is No changes, but as discussed in Section 6.5.5, re-authentication is
based on the key material generated by EAP-AKA' and the extension based on the key material generated by EAP-AKA' and the extension
defined in this document. defined in this document.
6.5.7. EAP-Response/AKA'-Synchronization-Failure 6.5.7. EAP-Response/AKA'-Synchronization-Failure
No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST
skipping to change at page 19, line 19 skipping to change at line 854
6.5.11. EAP-Response/AKA'-Notification 6.5.11. EAP-Response/AKA'-Notification
No changes. No changes.
7. Security Considerations 7. Security Considerations
This section deals only with the changes to security considerations This section deals only with the changes to security considerations
as they differ from EAP-AKA', or as new information has been gathered as they differ from EAP-AKA', or as new information has been gathered
since the publication of [RFC9048]. since the publication of [RFC9048].
As discussed in Section 1, forward secrecy is an important As discussed in Section 1, FS is an important countermeasure against
countermeasure against adversaries who gain access to the long-term adversaries who gain access to long-term keys. The long-term keys
keys. The long-term keys can be best protected with good processes, can be best protected with good processes, e.g., restricting access
e.g., restricting access to the key material within a factory or to the key material within a factory or among personnel, etc. Even
among personnel, etc. Even so, not all attacks can be entirely ruled so, not all attacks can be entirely ruled out. For instance, well-
out. For instance, well-resourced adversaries may be able to coerce resourced adversaries may be able to coerce insiders to collaborate,
insiders to collaborate, despite any technical protection measures. despite any technical protection measures. The zero trust principles
The zero trust principles suggest that we assume that breaches are suggest that we assume that breaches are inevitable or have
inevitable or have potentially already occurred, and that we need to potentially already occurred and that we need to minimize the impact
minimize the impact of these breaches [NSA-ZT] [NIST-ZT]. One type of these breaches (see [NSA-ZT] and [NIST-ZT]). One type of breach
of breach is key compromise or key exfiltration. is key compromise or key exfiltration.
If a mechanism without ephemeral key exchange such as (5G-AKA, EAP- If a mechanism without ephemeral key exchange (such as 5G-AKA or EAP-
AKA') is used the effects of key compromise are devastating. There AKA') is used, the effects of key compromise are devastating. There
are serious consequences of not properly providing forward secrecy are serious consequences to not properly providing FS for the key
for the key establishment. For both control and user plane, and both establishment, for the control plane and the user plane, and for both
directions: directions:
1. An attacker can decrypt 5G communication that they previously 1. An attacker can decrypt 5G communication that they previously
recorded. recorded.
2. A passive attacker can eavesdrop (decrypt) all future 5G 2. A passive attacker can eavesdrop (decrypt) all future 5G
communication. communication.
3. An active attacker can impersonate the UE or the Network and 3. An active attacker can impersonate the User Equipment (UE) or the
inject messages in an ongoing 5G connection between the real UE Network and inject messages in an ongoing 5G connection between
and the real network. the real UE and the real network.
Best practice security today is to mandate forward secrecy (as is At the time of writing, best practice security is to mandate FS (as
done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, IKEv2, SSH, QUIC, WireGuard, is done in Wi-Fi Protected Access 3 (WPA3), EAP-TLS 1.3, EAP-TTLS
Signal, etc.). It is recommended that in deployments, EAP-AKA 1.3, Internet Key Exchange Protocol Version 2 (IKEv2), Secure Shell
methods without forward secrecy be phased out in the long term. (SSH), QUIC, WireGuard, Signal, etc.). In deployments, it is
recommended that EAP-AKA methods without FS be phased out in the long
term.
This extension provide assistance against passive attacks from The FS extension provides assistance against passive attacks from
attackers that have compromised the key material on USIM cards. attackers that have compromised the key material on USIM cards.
Passive attacks are attractive for attackers performing large scale Passive attacks are attractive for attackers performing large-scale
pervasive monitoring as they require much less resources and are much pervasive monitoring as they require far fewer resources and are much
harder to detect. The extension also provides protection against harder to detect. The extension also provides protection against
active attacks as the attacker is forced to be on path during the AKA active attacks as the attacker is forced to be on-path during the AKA
run and subsequent communication between the parties. Without run and subsequent communication between the parties. Without FS, an
forward secrecy an active attacker that has compromised the long-term active attacker that has compromised the long-term key can inject
key can inject messages in an connection between the real Peer and messages in a connection between the real Peer and the real server
the real server without being on path. This extension is most useful without being on-path. This extension is most useful when
when used in a context where the MSK/EMSK are used in protocols not implemented in a context where the MSK/EMSK are used in protocols not
providing forward secrecy. For instance, if used with IKEv2 providing FS. For instance, if used with IKEv2 [RFC7296], the
[RFC7296], the session keys produced by IKEv2 have this property, so session keys produced by IKEv2 have this property, so better
better characteristics of the MSK and EMSK is not that useful. characteristics of the MSK and EMSK is not that useful. However,
However, typical link layer usage of EAP does not involve running typical link-layer usage of EAP does not involve running another,
another, forward secure, key exchange. Therefore, using EAP to forward secure, key exchange. Therefore, using EAP to authenticate
authenticate access to a network is one situation where the extension access to a network is one situation where the extension defined in
defined in this document can be helpful. this document can be helpful.
This extension generates keying material using the ECDHE exchange in The FS extension generates keying material using the ECDHE exchange
order to gain the FS property. This means that once an EAP-AKA' in order to gain the FS property. This means that once an EAP-AKA'
authentication run ends, the session that it was used to protect is authentication run ends, the session that it was used to protect is
closed, and the corresponding keys are destroyed, even someone who closed, and the corresponding keys are destroyed. Even someone who
has recorded all of the data from the authentication run and session has recorded all of the data from the authentication run and session
and gets access to all of the AKA long-term keys cannot reconstruct and gets access to all of the AKA long-term keys cannot reconstruct
the keys used to protect the session or any previous session, without the keys used to protect the session or any previous session, without
doing a brute force search of the session key space. doing a brute-force search of the session key space.
Even if a compromise of the long-term keys has occurred, FS is still Even if a compromise of the long-term keys has occurred, FS is still
provided for all future sessions, as long as the attacker does not provided for all future sessions, as long as the attacker does not
become an active attacker. become an active attacker.
The extension does not provide protection against active attackers The extension does not provide protection against active attackers
with access to the long-term key that mount an on-path attack on with access to the long-term key that mount an on-path attack on
future EAP-AKA' runs will be able to eavesdrop on the traffic future EAP-AKA' runs will be able to eavesdrop on the traffic
protected by the resulting session key(s). Still, past sessions protected by the resulting session key(s). Still, past sessions
where FS was in use remain protected. where FS was in use remain protected.
Using EAP-AKA' FS once provides forward secrecy. Forward secrecy Using EAP-AKA' FS once provides FS. FS limits the effect of key
limits the effect of key leakage in one direction (compromise of a leakage in one direction (compromise of a key at time T2 does not
key at time T2 does not compromise some key at time T1 where T1 < compromise some key at time T1 where T1 < T2). Protection in the
T2). Protection in the other direction (compromise at time T1 does other direction (compromise at time T1 does not compromise keys at
not compromise keys at time T2) can be achieved by rerunning ECDHE time T2) can be achieved by rerunning ECDHE frequently. If a long-
frequently. If a long-term authentication key has been compromised, term authentication key has been compromised, rerunning EAP-AKA' FS
rerunning EAP-AKA' FS gives protection against passive attackers. gives protection against passive attackers. Using the terms in
Using the terms in [RFC7624], forward secrecy without rerunning ECDHE [RFC7624], FS without rerunning ECDHE does not stop an attacker from
does not stop an attacker from doing static key exfiltration. doing static key exfiltration. Frequently rerunning EC(DHE) forces
Frequently rerunning EC(DHE) forces an attacker to do dynamic key an attacker to do dynamic key exfiltration (or content exfiltration).
exfiltration (or content exfiltration).
7.1. Deployment Considerations 7.1. Deployment Considerations
Achieving FS requires that when a connection is closed, each endpoint Achieving FS requires that, when a connection is closed, each
MUST destroy not only the ephemeral keys used by the connection but endpoint MUST destroy not only the ephemeral keys used by the
also any information that could be used to recompute those keys. connection but also any information that could be used to recompute
those keys.
Similarly, other parts of the system matter. For instance, when the Similarly, other parts of the system matter. For instance, when the
keys generated by EAP are transported to a pass-through keys generated by EAP are transported to a pass-through
authenticator, such transport must also provide forward secure authenticator, such transport must also provide forward secure
encryption with respect to the long-term keys used to establish its encryption with respect to the long-term keys used to establish its
security. Otherwise, an adversary may attack the transport security. Otherwise, an adversary may attack the transport
connection used to carry keys from EAP, and use this method to gain connection used to carry keys from EAP, and use this method to gain
access to current and past keys from EAP, which in turn would lead to access to current and past keys from EAP, which, in turn, would lead
the compromise of anything protected by those EAP keys. to the compromise of anything protected by those EAP keys.
Of course, these considerations apply to any EAP method, not only Of course, these considerations apply to any EAP method, not only
this one. this one.
7.2. Security Properties 7.2. Security Properties
The following security properties of EAP-AKA' are impacted through The following security properties of EAP-AKA' are impacted through
this extension: this extension:
Protected ciphersuite negotiation Protected ciphersuite negotiation:
EAP-AKA' has a negotiation mechanism for selecting the key EAP-AKA' has a negotiation mechanism for selecting the KDFs, and
derivation functions, and this mechanism has been extended by the this mechanism has been extended by the extension specified in
extension specified in this document. The resulting mechanism this document. The resulting mechanism continues to be secure
continues to be secure against bidding down attacks. against bidding-down attacks.
There are two specific needs in the negotiation mechanism: There are two specific needs in the negotiation mechanism:
Negotiating key derivation function within the extension Negotiating KDFs within the extension:
The negotiation mechanism allows changing the offered key The negotiation mechanism allows changing the offered KDF, but
derivation function, but the change is visible in the final the change is visible in the final EAP-Request/AKA'-Challenge
EAP- Request/AKA'-Challenge message that the server sends to message that the server sends to the peer. This message is
the peer. This message is authenticated via the AT_MAC authenticated via the AT_MAC attribute, and carries both the
attribute, and carries both the chosen alternative and the chosen alternative and the initially offered list. The peer
initially offered list. The peer refuses to accept a change it refuses to accept a change it did not initiate. As a result,
did not initiate. As a result, both parties are aware that a both parties are aware that a change is being made and what the
change is being made and what the original offer was. original offer was.
Negotiating the use of this extension Negotiating the use of this extension:
This extension is offered by the server through presenting the This extension is offered by the server through presenting the
AT_KDF_FS and AT_PUB_ECDHE attributes in the EAP-Request/AKA'- AT_KDF_FS and AT_PUB_ECDHE attributes in the EAP-Request/AKA'-
Challenge message. These attributes are protected by AT_MAC, Challenge message. These attributes are protected by AT_MAC,
so attempts to change or omit them by an adversary will be so attempts to change or omit them by an adversary will be
detected. detected.
Except of course, if the adversary holds the long-term key and Except of course, if the adversary holds the long-term key and
is willing to engage in an active attack. Such an attack can, is willing to engage in an active attack. For instance, such
for instance, forge the negotiation process so that no FS will an attack can forge the negotiation process so that no FS will
be provided. However, as noted above, an attacker with these be provided. However, as noted above, an attacker with these
capabilities will in any case be able to impersonate any party capabilities will, in any case, be able to impersonate any
in the protocol and perform on-path attacks. That is not a party in the protocol and perform on-path attacks. That is not
situation that can be improved by a technical solution. a situation that can be improved by a technical solution.
However, as discussed in the introduction, even an attacker However, as discussed in the Introduction, even an attacker
with access to the long-term keys is required to be on path on with access to the long-term keys is required to be on-path on
each AKA run and subsequent communication, which makes mass each AKA run and subsequent communication, which makes mass
surveillance more laborious. surveillance more laborious.
The security properties of the extension also depend on a The security properties of the extension also depend on a
policy choice. As discussed in Section 6.5.4, both the peer policy choice. As discussed in Section 6.5.4, both the peer
and the server make a policy decision of what to do when it was and the server make a policy decision of what to do when it was
willing to perform the extension specified in this protocol, willing to perform the extension specified in this protocol,
but the other side does not wish to use the extension. but the other side does not wish to use the extension.
Allowing this has the benefit of allowing backwards Allowing this has the benefit of allowing backwards
compatibility to equipment that did not yet support the compatibility to equipment that did not yet support the
extension. When the extension is not supported or negotiated extension. When the extension is not supported or negotiated
by the parties, no FS can obviously be provided. by the parties, no FS can obviously be provided.
If turning off the extension specified in this protocol is not If turning off the extension specified in this protocol is not
allowed by policy, the use of legacy equipment that does not allowed by policy, the use of legacy equipment that does not
support this protocol is no longer possible. This may be support this protocol is no longer possible. This may be
appropriate when, for instance, support for the extension is appropriate when, for instance, support for the extension is
sufficiently widespread, or required in a particular version of sufficiently widespread or required in a particular version of
a mobile network. a mobile network.
Key derivation Key derivation:
This extension provides forward secrecy. As described in several This extension provides FS. As described in several places in
places in this specification, this can be roughly summarized as this specification, this can be roughly summarized as follows: an
that an attacker with access to long-term keys is unable to obtain attacker with access to long-term keys is unable to obtain session
session keys of ended past sessions, assuming these sessions keys of ended past sessions, assuming these sessions deleted all
deleted all relevant session key material. This extension does relevant session key material. This extension does not change the
not change the properties related to re-authentication. No new properties related to re-authentication. No new Diffie-Hellman
Diffie-Hellman run is performed during the re-authentication run is performed during the re-authentication allowed by EAP-AKA'.
allowed by EAP-AKA'. However, if this extension was in use when However, if this extension was in use when the original EAP-AKA'
the original EAP-AKA' authentication was performed, the keys used authentication was performed, the keys used for re-authentication
for re-authentication (K_re) are based on the Diffie-Hellman keys, (K_re) are based on the Diffie-Hellman keys; hence, they continue
and hence continue to be equally safe against expose of the long- to be equally safe against exposure of the long-term key as the
term key as the original authentication. original authentication.
7.3. Denial-of-Service 7.3. Denial of Service
In addition, it is worthwhile to discuss Denial-of-Service attacks In addition, it is worthwhile to discuss Denial-of-Service (DoS)
and their impact on this protocol. The calculations involved in attacks and their impact on this protocol. The calculations involved
public key cryptography require computing power, which could be used in public key cryptography require computing power, which could be
in an attack to overpower either the peer or the server. While some used in an attack to overpower either the peer or the server. While
forms of Denial-of-Service attacks are always possible, the following some forms of DoS attacks are always possible, the following factors
factors help mitigate the concerns relating to public key help mitigate the concerns relating to public key cryptography and
cryptography and EAP-AKA' FS. EAP-AKA' FS.
* In 5G context, other parts of the connection setup involve public * In a 5G context, other parts of the connection setup involve
key cryptography, so while performing additional operations in public key cryptography, so while performing additional operations
EAP-AKA' is an additional concern, it does not change the overall in EAP-AKA' is an additional concern, it does not change the
situation. As a result, the relevant system components need to be overall situation. As a result, the relevant system components
dimensioned appropriately, and detection and management mechanisms need to be dimensioned appropriately, and detection and management
to reduce the effect of attacks need to be in place. mechanisms to reduce the effect of attacks need to be in place.
* This specification is constructed so that a separation between the * This specification is constructed so that a separation between the
USIM and Peer on client side and the Server and AD on network side USIM and Peer on the client side and the Server and AD on the
is possible. This ensures that the most sensitive (or legacy) network side is possible. This ensures that the most sensitive
system components cannot be the target of the attack. For (or legacy) system components cannot be the target of the attack.
instance, EAP-AKA' and public key cryptography takes place in the For instance, EAP-AKA' and public key cryptography takes place in
phone and not the low-power USIM card. the phone and not the low-power USIM card.
* EAP-AKA' has been designed so that the first actual message in the * EAP-AKA' has been designed so that the first actual message in the
authentication process comes from the Server, and that this authentication process comes from the Server, and that this
message will not be sent unless the user has been identified as an message will not be sent unless the user has been identified as an
active subscriber of the operator in question. While the initial active subscriber of the operator in question. While the initial
identity can be spoofed before authentication has succeeded, this identity can be spoofed before authentication has succeeded, this
reduces the efficiency of an attack. reduces the efficiency of an attack.
* Finally, this memo specifies an order in which computations and * Finally, this memo specifies an order in which computations and
checks must occur. When processing the EAP-Request/AKA'-Challenge checks must occur. For instance, when processing the EAP-Request/
message, for instance, the AKA authentication must be checked and AKA'-Challenge message, the AKA authentication must be checked and
succeed before the peer proceeds to calculating or processing the succeed before the peer proceeds to calculating or processing the
FS related parameters (see Section 6.5.4). The same is true of FS-related parameters (see Section 6.5.4). The same is true of an
EAP-Response/AKA'-Challenge (see Section 6.5.4). This ensures EAP-Response/AKA'-Challenge (see Section 6.5.4). This ensures
that the parties need to show possession of the long-term key in that the parties need to show possession of the long-term key in
some way, and only then will the FS calculations become active. some way, and only then will the FS calculations become active.
This limits the Denial-of-Service to specific, identified This limits the DoS to specific, identified subscribers. While
subscribers. While botnets and other forms of malicious parties botnets and other forms of malicious parties could take advantage
could take advantage of actual subscribers and their key material, of actual subscribers and their key material, at least such
at least such attacks are (a) limited in terms of subscribers they attacks are:
control, and (b) identifiable for the purposes of blocking the
affected subscribers. a. limited in terms of subscribers they control, and
b. identifiable for the purposes of blocking the affected
subscribers.
7.4. Identity Privacy 7.4. Identity Privacy
As specified in Section 6.5, the peer identity sent in the Identity As specified in Section 6.5, the peer identity sent in the Identity
Response message needs to follow the privacy-friendly requirements in Response message needs to follow the privacy-friendly requirements in
[RFC9190]. [RFC9190].
7.5. Unprotected Data and Privacy 7.5. Unprotected Data and Privacy
Unprotected data and metadata can reveal sensitive information and Unprotected data and metadata can reveal sensitive information and
need to be selected with care. In particular, this applies to need to be selected with care. In particular, this applies to
AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF,
AT_KDF_FS, and AT_PUB_ECDHE reveal the used cryptographic algorithms, AT_KDF_FS, and AT_PUB_ECDHE reveal the used cryptographic algorithms;
if these depend on the peer identity they leak information about the if these depend on the peer identity, they leak information about the
peer. AT_KDF_INPUT reveals the network name, although that is done peer. AT_KDF_INPUT reveals the network name, although that is done
on purpose to bind the authentication to a particular context. on purpose to bind the authentication to a particular context.
An attacker observing network traffic may use the above types of An attacker observing network traffic may use the above types of
information for traffic flow analysis or to track an endpoint. information for traffic flow analysis or to track an endpoint.
7.6. Forward Secrecy within AT_ENCR 7.6. Forward Secrecy within AT_ENCR
They keys K_encr and K_aut are calculated and used before the shared The keys K_encr and K_aut are calculated and used before the shared
secret from the ephemeral key exchange is available. secret from the ephemeral key exchange is available.
K_encr and K_aut are used to encrypt and MAC data in the EAP-Req/ K_encr and K_aut are used to encrypt and MAC data in the EAP-Req/
AKA'-Challenge message, especially the DH g^x ephemeral pub key. At AKA'-Challenge message, especially the DH g^x ephemeral pub key. At
that point the server does not yet have the corresponding g^y from that point, the server does not yet have the corresponding g^y from
the peer and cannot compute the shared secret. K_aut is then used as the peer and cannot compute the shared secret. K_aut is then used as
the authentication key for the shared secret. the authentication key for the shared secret.
For K_encr though, none of the encrypted data sent in the EAP-Req/ However, for K_encr, none of the encrypted data sent in the EAP-Req/
AKA'-Challenge message in the AT_ENCR attribute will be forward AKA'-Challenge message in the AT_ENCR attribute will be a forward
secret. That data may include re-authentication pseudonyms, so an secret. That data may include re-authentication pseudonyms, so an
adversary compromising the long-term key would be able to link re- adversary compromising the long-term key would be able to link re-
authentication protocol-runs when pseudonyms are used, within a authentication protocol runs when pseudonyms are used, within a
sequence of runs followed after a full EAP-AKA' authentication. No sequence of runs followed after a full EAP-AKA' authentication. No
such linking would be possible across different full authentaction such linking would be possible across different full authentication
runs. If the pseudonum linkage risk is not acceptable, one way to runs. If the pseudonym linkage risk is not acceptable, one way to
avoid the linkage is to always require full EAP-AKA' authentication. avoid the linkage is to always require full EAP-AKA' authentication.
7.7. Post-Quantum Considerations 7.7. Post-Quantum Considerations
As of the publication of this document, it is unclear when or even if As of the publication of this document, it is unclear when or even if
a quantum computer of sufficient size and power to exploit elliptic a quantum computer of sufficient size and power to exploit ECC will
curve cryptography will exist. Deployments that need to consider exist. Deployments that need to consider risks decades into the
risks decades into the future should transition to Post- Quantum future should transition to Post-Quantum Cryptography (PQC) in the
Cryptography (PQC) in the not-too-distant future. Other systems may not-too-distant future. Other systems may employ PQC when the
employ PQC when the quantum threat is more imminent. Current PQC quantum threat is more imminent. Current PQC algorithms have
algorithms have limitations compared to Elliptic Curve Cryptography limitations compared to ECC, and the data sizes could be problematic
(ECC) and the data sizes could be problematic for some constrained for some constrained systems. If a Cryptographically Relevant
systems. If a Cryptographically Relevant Quantum Computer (CRQC) is Quantum Computer (CRQC) is built, it could recover the SHARED_SECRET
built it could recover the SHARED_SECRET from the ECDHE public keys. from the ECDHE public keys.
This would not affect the ability of EAP-AKA' - with or without this However, this would not affect the ability of EAP-AKA', with or
extension - to authenticate properly, however. As symmetric key without this extension, to authenticate properly. As symmetric key
cryptography is safe even if CRQCs are built, an adversary still will cryptography is safe even if CRQCs are built, an adversary still will
not be able to disrupt authentication as it requires computing a not be able to disrupt authentication as it requires computing a
correct AT_MAC value. This computation requires the K_aut key which correct AT_MAC value. This computation requires the K_aut key, which
is based on MK and, ultimately, CK' and IK', but not SHARED_SECRET. is based on MK, CK', and IK', but not SHARED_SECRET.
Other output keys do include SHARED_SECRET via MK_ECDHE, but still Other output keys do include SHARED_SECRET via MK_ECDHE, but they
include also CK' and IK' which are entirely based on symmetric still include CK' and IK', which are entirely based on symmetric
cryptography. As a result, an adversary with a quantum computer cryptography. As a result, an adversary with a quantum computer
still cannot compute the other output keys either. still cannot compute the other output keys either.
However, if the adversary has also obtained knowledge of the long- However, if the adversary has also obtained knowledge of the long-
term key, they could then compute CK', IK', and SHARED_SECRET, and term key, they could then compute CK', IK', SHARED_SECRET, and any
any derived output keys. This means that the introduction of a derived output keys. This means that the introduction of a powerful
powerful enough quantum computer would disable this protocol enough quantum computer would disable this protocol extension's
extension's ability to provide the forward security capability. This ability to provide the forward security capability. This would make
would make it necessary to update the current ECC algorithms in this it necessary to update the current ECC algorithms in this document to
document to PQC algorithms. This document does not add such PQC algorithms. This document does not add such algorithms, but a
algorithms, but a future update can do that. future update can do that.
Symmetric algorithms used in EAP-AKA' FS such as HMAC-SHA-256 and the Symmetric algorithms used in EAP-AKA' FS, such as HMAC-SHA-256 and
algorithms use to generate AT_AUTN and AT_RES are practically secure the algorithms used to generate AT_AUTN and AT_RES, are practically
against even large robust quantum computers. EAP-AKA' FS is secure against even large, robust quantum computers. EAP-AKA' FS is
currently only specified for use with ECDHE key exchange algorithms, currently only specified for use with ECDHE key exchange algorithms,
but use of any Key Encapsulation Method (KEM), including Post-Quantum but use of any Key Encapsulation Method (KEM), including PQC KEMs,
Cryptography (PQC) KEMs, can be specified in the future. While the can be specified in the future. While the key exchange is specified
key exchange is specified with terms of the Diffie-Hellman protocol, with terms of the Diffie-Hellman protocol, the key exchange adheres
the key exchange adheres to a KEM interface. AT_PUB_ECDHE would then to a KEM interface. AT_PUB_ECDHE would then contain either the
contain either the ephemeral public key of the server or the ephemeral public key of the server or the SHARED_SECRET encapsulated
SHARED_SECRET encapsulated with the server's public key. Note that with the server's public key. Note that the use of a KEM might
the use of a KEM might require other changes such as including the require other changes, such as including the ephemeral public key of
ephemeral public key of the server in the key derivation to retain the server in the key derivation to retain the property that both
the property that both parties contribute randomness to the session parties contribute randomness to the session key.
key.
8. IANA Considerations 8. IANA Considerations
This extension of EAP-AKA' shares its attribute space and subtypes This extension of EAP-AKA' shares its attribute space and subtypes
with Extensible Authentication Protocol Method for Global System for with the "Extensible Authentication Protocol Method for Global System
Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) for Mobile Communications (GSM) Subscriber Identity Modules (EAP-
[RFC4186], EAP-AKA [RFC4187], and EAP-AKA' [RFC9048]. SIM)" [RFC4186], EAP-AKA [RFC4187], and EAP-AKA' [RFC9048].
Two new values (TBA1, TBA2) in the skippable range need to be IANA has assigned two new values in the "Attribute Types (Skippable
assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_FS (Section 6.2) Attributes 128-255)" registry under the "EAP-AKA and EAP-SIM
in the "Attribute Types" registry under the "EAP-AKA and EAP-SIM Parameters" group as follows:
Parameters" group.
Also, IANA is requested to create a new registry "EAP-AKA' AT_KDF_FS 152: AT_PUB_ECDHE (Section 6.1)
Key Derivation Function Values" to represent FS Key Derivation
Function types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA'
with ECDHE and P-256" types (1 and 2, see Section 6.3) need to be
assigned, along with one reserved value. The initial contents of
this registry is illustrated in Table 1; new values can be created
through the Specification Required policy [RFC8126]. Expert
reviewers should ensure that the referenced specification is clearly
identified and stable, and that the proposed addition is reasonable
for the given category of allocation.
+=========+==================+=========================+ 153: AT_KDF_FS (Section 6.2)
| Value | Description | Reference |
+=========+==================+=========================+
| 0 | Reserved | [TBD BY IANA: THIS RFC] |
+---------+------------------+-------------------------+
| 1 | EAP-AKA' with | [TBD BY IANA: THIS RFC] |
| | ECDHE and X25519 | |
+---------+------------------+-------------------------+
| 2 | EAP-AKA' with | [TBD BY IANA: THIS RFC] |
| | ECDHE and P-256 | |
+---------+------------------+-------------------------+
| 3-65535 | Unassigned | [TBD BY IANA: THIS RFC] |
+---------+------------------+-------------------------+
Table 1: Initial Content of the EAP-AKA' AT_KDF_FS IANA has also created the "EAP-AKA' AT_KDF_FS Key Derivation Function
Key Derivation Function Values Registry Values" registry to represent FS KDF types. The "EAP-AKA' with ECDHE
and X25519" and "EAP-AKA' with ECDHE and P-256" types (1 and 2, see
Section 6.3) have been assigned, along with one reserved value. The
initial contents of this registry are illustrated in Table 1; new
values can be created through the Specification Required policy
[RFC8126]. Expert reviewers should ensure that the referenced
specification is clearly identified and stable and that the proposed
addition is reasonable for the given category of allocation.
+=========+================================+===========+
| Value | Description | Reference |
+=========+================================+===========+
| 0 | Reserved | RFC 9678 |
+---------+--------------------------------+-----------+
| 1 | EAP-AKA' with ECDHE and X25519 | RFC 9678 |
+---------+--------------------------------+-----------+
| 2 | EAP-AKA' with ECDHE and P-256 | RFC 9678 |
+---------+--------------------------------+-----------+
| 3-65535 | Unassigned | RFC 9678 |
+---------+--------------------------------+-----------+
Table 1: EAP-AKA' AT_KDF_FS Key Derivation Function
Values Registry Initial Contents
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 27, line 47 skipping to change at line 1258
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9048] Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen, [RFC9048] Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
"Improved Extensible Authentication Protocol Method for "Improved Extensible Authentication Protocol Method for
3GPP Mobile Network Authentication and Key Agreement (EAP- 3GPP Mobile Network Authentication and Key Agreement (EAP-
AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021, AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021,
<https://www.rfc-editor.org/info/rfc9048>. <https://www.rfc-editor.org/info/rfc9048>.
[SP-800-186] [SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic
NIST, "Recommendations for Discrete Logarithm-based Curve Cryptography", Version 2.0, May 2009,
Cryptography: Elliptic Curve Domain Parameters", <https://www.secg.org/sec1-v2.pdf>.
NIST Special Publication 800-186, February 2023,
<https://doi.org/10.6028/NIST.SP.800-186>.
[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", [SEC2] Standards for Efficient Cryptography, "SEC 2: Recommended
Standards for Efficient Cryptography 1 (SEC 1) Version Elliptic Curve Domain Parameters", Version 2.0, January
2.0, May 2009, <https://www.secg.org/sec1-v2.pdf>. 2010, <https://www.secg.org/sec2-v2.pdf>.
[SEC2] Certicom Research, "SEC 2: Recommended Elliptic Curve [SP-800-186]
Domain Parameters", Standards for Efficient Cryptography 2 Chen, L., Moody, D., Randall, K., Regenscheid, A., and A.
(SEC 2) Version 2.0, January 2010, Robinson, "Recommendations for Discrete Logarithm-based
<https://www.secg.org/sec2-v2.pdf>. Cryptography: Elliptic Curve Domain Parameters", NIST SP
800-186, DOI 10.6028/NIST.SP.800-186, February 2023,
<https://doi.org/10.6028/NIST.SP.800-186>.
[SP-800-56A] [SP-800-56A]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Davis, "Recommendation for Pair-Wise Key-Establishment Davis, "Recommendation for Pair-Wise Key-Establishment
Schemes Using Discrete Logarithm Cryptography", Schemes Using Discrete Logarithm Cryptography", NIST SP
NIST Special Publication 800-56A Revision 3, April 2018, 800-56A, DOI 10.6028/NIST.SP.800-56Ar3, April 2018,
<https://doi.org/10.6028/NIST.SP.800-56Ar3>. <https://doi.org/10.6028/NIST.SP.800-56Ar3>.
9.2. Informative References 9.2. Informative References
[DOW1992] Diffie, W., Van Oorschot, P. C., and M. J. Wiener,
"Authentication and authenticated key exchanges", Designs,
Codes and Cryptography, vol. 2, pp. 107-125,
DOI 10.1007/BF00124891, June 1992,
<https://doi.org/10.1007/BF00124891>.
[Heist2015]
Scahill, J. and J. Begley, "The Great SIM Heist", February
2015,
<https://theintercept.com/2015/02/19/great-sim-heist/>.
[NIST-ZT] National Institute of Standards and Technology,
"Implementing a Zero Trust Architecture", NIST SP
1800-35B, December 2022,
<https://www.nccoe.nist.gov/sites/default/files/2022-12/
zta-nist-sp-1800-35b-preliminary-draft-2.pdf>.
[NSA-ZT] National Security Agency, "Embracing a Zero Trust Security
Model", February 2021, <https://media.defense.gov/2021/
Feb/25/2002588479/-1/-1/0/
CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF>.
[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,
<https://www.rfc-editor.org/info/rfc4186>. <https://www.rfc-editor.org/info/rfc4186>.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
March 2008, <https://www.rfc-editor.org/info/rfc5216>. March 2008, <https://www.rfc-editor.org/info/rfc5216>.
skipping to change at page 29, line 7 skipping to change at line 1330
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the [RFC9190] Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3", Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022, RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>. <https://www.rfc-editor.org/info/rfc9190>.
[TrustCom2015] [TrustCom2015]
Arkko, J., Norrman, K., Näslund, M., and B. Sahlin, "A Arkko, J., Norrman, K., Näslund, M., and B. Sahlin, "A
USIM compatible 5G AKA protocol with perfect forward USIM Compatible 5G AKA Protocol with Perfect Forward
secrecy", Proceedings of IEEE International Conference on Secrecy", IEEE International Conference on Trust, Security
Trust, Security and Privacy in Computing and and Privacy in Computing and Communications (TrustCom),
Communications (TrustCom) 2015, August 2015, DOI 10.1109/Trustcom.2015.506, August 2015,
<https://doi.org/10.1109/Trustcom.2015.506>. <https://doi.org/10.1109/Trustcom.2015.506>.
[Heist2015]
Scahill, J. and J. Begley, "The Great SIM Heist", February
2015,
<https://theintercept.com/2015/02/19/great-sim-heist/>.
[DOW1992] Diffie, W., Van Oorschot, P., and M. Wiener,
"Authentication and Authenticated Key Exchanges", Designs,
Codes and Cryptography 2 pp. 107-125, June 1992,
<https://doi.org/10.1007/BF00124891>.
[TS.33.501] [TS.33.501]
3GPP, "Security architecture and procedures for 5G 3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501 18.1.0, March 2023. System", Version 18.1.0, 3GPP TS 33.501, March 2023.
[NIST-ZT] National Institute of Standards and Technology,
"Implementing a Zero Trust Architecture", December 2022,
<https://www.nccoe.nist.gov/sites/default/files/2022-12/
zta-nist-sp-1800-35b-preliminary-draft-2.pdf>.
[NSA-ZT] National Security Agency, "Embracing a Zero Trust Security
Model", February 2021, <https://media.defense.gov/2021/
Feb/25/2002588479/-1/-1/0/
CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF>.
Appendix A. Change Log
RFC Editor: Please remove this appendix.
The -12 version of the WG draft has the following changes, most due
to IESG review comments in January 2023:
* Update the draft track to Standards Track.
* Clarified the calculation of the Length field in the AT_ECDHE
attribute, along with padding requirements.
* Avoided the use of keywords in operational recommendations, e.g.,
about deployment.
* Changed the definition of what "supported" means to focus on
feature being implemented, but not require that it is usable
during a protocol run, because configuration, new security
information, etc. might imply that a particular feature is
implemented but disabled for policy reasons.
* Changed the MITM terminology to be on-path attacks.
* Corrected a reference typo in the IANA considerations section.
* Shortened the abstract and introduction to the key aspects and
removed duplication.
* Several editorial changes.
The -11 version of the WG draft has the following changes:
* Addressed IETF Last Call comments from directorates, Security AD,
Meiling Cheng, and a detailed review from the author Karl. In
particular:
* Replaced the reference to the deprecated FIPS 186-4 with SP
800-186.
* Changed HSS (Home Subscriber Server) to Authentication Database
(AD) as HSS is a 4G term.
* Explained difference between EAP-AKA and EAP-AKA'
* Explained that the emphemeral key exhange provide more that
forward secrecy and how this is important to mitigate pervasive
monitoring.
* Included links for the zero trust principles.
* Explained why K_encr and K_auth not being protected by the ECDHE
addition.
* Added that a future introduction of KEM might require additional
changes.
* Explained how ephemeral key exchange is linked to pervasive
monitoring.
* Changed SIM to USIM everywhere. A USIM is required for AKA.
* Changed to long-term key instead of long-term secret or long-term
shared secret.
* Reference updates.
* Various editorial improvements.
The -10 version of the WG draft has the following changes:
* Various nits found by Peter Yee.
The -09 version of the WG draft has the following changes:
* Scalable Vector Graphics (SVG) versions for all figures has been
added and the figures has been slightly modified to render nicely
with aasvg.
* A reference has been added to the Section in SEC1 describing how
to do decompression.
* The strengthened identity protection requirements are now
mentioned in the introduction.
* Corrections and clarifications were made in the IANA
considerations. The table in the IANA section has been made into
a proper xml table.
* Reference updates.
* Various editorial improvements.
The -08 version of the WG draft has the following changes:
* Further clarification of key calculation in Section 6.3.
* Support for the NIST P-256 group has been made mandatory in
Section 6.4, in order to align the requirements with 3GPP SUCI
encryption requirements.
* The interaction between AT_KDF and AT_KDF_FS has been specified
more clearly, including specifying how future specifications need
to specify the treatment of new combinations.
* Addition of a discussion about the impacts of potential future
quantum computing attacks with specific impacts to this extension.
* Addition of a discussion about metadata/unprotected data in
Section 7.5.
* Reference updates.
* Various editorial improvements.
The -07 version of the WG draft has the following changes:
* The impact of forward secrecy explanation has been improved in the
abstract and security considerations.
* The draft now more forcefully explains why the authors believe it
is important to migrate existing systems to use forward secrecy,
and makes a recommendation for this migration.
* The draft does no longer refer to issues within the smart cards
but rather the smart card supply chain.
* The rationale for chosen algorithms is explained.
* Also, the authors have checked the language relating to the public
value encoding, and believe it is exactly according to the
references ([RFC7748] Section 6.1 and [SEC2] Section 2.7.1)
The -06 version of the WG draft is a refresh and a reference update.
However, the following should be noted:
* The draft now uses "forward secrecy" terminology and references
RFC 7624 per recommendations on mailing list discussion.
* There's been mailing list discussion about the encoding of the
public values; the current text requires confirmation from the
working group that it is sufficient.
The -05 version of the WG draft takes into account feedback from the
working group list, about the number of bytes needed to encode P-256
values.
The -04 version of the WG draft takes into account feedback from the
May 2020 WG interim meeting, correcting the reference to the NIST
P-256 specification.
The -03 version of the WG draft is first of all a refresh; there are
no issues that we think need addressing, beyond the one for which
there is a suggestion in -03: The document now suggests an alternate
group/curve as an optional one besides X25519. The specific choice
of particular groups and algorithms is still up to the working group.
The -02 version of the WG draft took into account additional reviews,
and changed the document to update RFC 5448 (or rather, its
successor, [RFC9048]), changed the wording of the recommendation with
regards to the use of this extension, clarified the references to the
definition of X25519 and Curve25519, clarified the distinction to
ECDH methods that use partially static keys, and simplified the use
of AKA and USIM card terminology. Some editorial changes were also
made.
The -00 and -01 versions of the WG draft made no major changes, only
updates to some references.
The -05 version is merely a refresh while the draft was waiting for
WG adoption.
The -04 version of this draft made only editorial changes.
The -03 version of this draft changed the naming of various protocol
components, values, and notation to match with the use of ECDH in
ephemeral mode. The AT_KDF_FS negotiation process was clarified in
that exactly one key is ever sent in AT_KDF_ECDHE. The option of
checking for zero key values IN ECDHE was added. The format of the
actual key in AT_PUB_ECDHE was specified. Denial-of-service
considerations for the FS process have been updated. Bidding down
attacks against this extension itself are discussed extensively.
This version also addressed comments from reviewers, including the
August review from Mohit Sethi, and comments made during IETF-102
discussion.
Acknowledgments Acknowledgments
The authors would like to note that the technical solution in this The authors would like to note that the technical solution in this
document came out of the TrustCom paper [TrustCom2015], whose authors document came out of the TrustCom paper [TrustCom2015], whose authors
were J. Arkko, K. Norrman, M. Näslund, and B. Sahlin. This document were J. Arkko, K. Norrman, M. Näslund, and B. Sahlin. This document
uses also a lot of material from [RFC4187] by J. Arkko and also uses a lot of material from [RFC4187] by J. Arkko and
H. Haverinen as well as [RFC5448] by J. Arkko, V. Lehtovirta, and H. Haverinen, as well as [RFC5448] by J. Arkko, V. Lehtovirta, and
P. Eronen. P. Eronen.
The authors would also like to thank Ben Campbell, Meiling Chen, The authors would also like to thank Ben Campbell, Meiling Chen,
Roman Danyliw, Linda Dunbar, Tim Evans, Zhang Fu, Russ Housley, Tero Roman Danyliw, Linda Dunbar, Tim Evans, Zhang Fu, Russ Housley, Tero
Kivinen, Murray Kucherawy, Warren Kumari, Eliot Lear, Vesa Kivinen, Murray Kucherawy, Warren Kumari, Eliot Lear, Vesa
Lehtovirta, Kathleen Moriarty, Prajwol Kumar Nakarmi, Francesca Lehtovirta, Kathleen Moriarty, Prajwol Kumar Nakarmi, Francesca
Palombini, Anand R. Prasad, Michael Richardson, Göran Rune, Bengt Palombini, Anand R. Prasad, Michael Richardson, Göran Rune, Bengt
Sahlin, Joseph Salowey, Mohit Sethi, Orie Steele, Rene Struik, Vesa Sahlin, Joseph Salowey, Mohit Sethi, Orie Steele, Rene Struik, Vesa
Torvinen, Sean Turner, Helena Vahidi Mazinani, Robert Wilton, Paul Torvinen, Sean Turner, Helena Vahidi Mazinani, Robert Wilton, Paul
Wouters, Bo Wu, Peter Yee, and many other people at the IETF, GSMA Wouters, Bo Wu, Peter Yee, and many other people at the IETF, GSMA,
and 3GPP groups for interesting discussions in this problem space. and 3GPP groups for interesting discussions in this problem space.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
FI-02420 Jorvas FI-02420 Jorvas
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Karl Norrman Karl Norrman
Ericsson Ericsson
SE-16483 Stockholm SE-16483 Stockholm
Sweden Sweden
 End of changes. 138 change blocks. 
712 lines changed or deleted 538 lines changed or added

This html diff was produced by rfcdiff 1.48.