draft-ietf-emu-aka-pfs-07.txt   draft-ietf-emu-aka-pfs-latest.txt 
Network Working Group J. Arkko Network Working Group J. Arkko
Internet-Draft K. Norrman Internet-Draft K. Norrman
Updates: RFC5448 (if approved) V. Torvinen Updates: 5448,9048 (if approved) V. Torvinen
Intended status: Informational J. Mattsson Intended status: Informational J. Preuss Mattsson
Expires: January 12, 2023 Ericsson Expires: April 26, 2023 Ericsson
July 11, 2022 October 23, 2022
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-07 draft-ietf-emu-aka-pfs-latest
Abstract Abstract
Many different attacks have been reported as part of revelations Many different attacks have been reported as part of revelations
associated with pervasive surveillance. Some of the reported attacks associated with pervasive surveillance. Some of the reported attacks
involved compromising the smart card supply chain, such as attacking involved compromising the smart card supply chain, such as attacking
SIM card manufacturers and operators in an effort to compromise SIM card manufacturers and operators in an effort to compromise
shared secrets stored on these cards. Since the publication of those shared secrets stored on these cards. Since the publication of those
reports, manufacturing and provisioning processes have gained much reports, manufacturing and provisioning processes have gained much
scrutiny and have improved. However, the danger of resourceful scrutiny and have improved. However, the danger of resourceful
attackers for these systems is still a concern. Always assuming attackers for these systems is still a concern. Always assuming
breach such as key compromise and minimizing the impact of breach are breach such as key compromise and minimizing the impact of breach are
essential zero-trust principles. essential zero-trust principles.
This specification is an optional extension to the EAP-AKA' This specification updates RFC 9048, the EAP-AKA' authentication
authentication method which was defined in [RFC9048]. The extension, method, with an optional extension. Similarly, this specification
when negotiated, provides Forward Secrecy for the session key also updates the earlier version of the EAP-AKA' specification in RFC
generated as a part of the authentication run in EAP-AKA'. This 5448. The extension, when negotiated, provides Forward Secrecy for
prevents an attacker who has gained access to the long-term pre- the session key generated as a part of the authentication run in EAP-
shared secret in a SIM card from being able to decrypt any past AKA'. This prevents an attacker who has gained access to the long-
communications. In addition, if the attacker stays merely a passive term pre-shared secret in a SIM card from being able to decrypt any
eavesdropper, the extension prevents attacks against future sessions. past communications. In addition, if the attacker stays merely a
This forces attackers to use active attacks instead. passive eavesdropper, the extension prevents attacks against future
sessions. This forces attackers to use active attacks instead.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 12, 2023. This Internet-Draft will expire on April 26, 2023.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 31 skipping to change at page 2, line 31
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Design and Deployment Objectives . . . . . . . . . . 4 2. Protocol Design and Deployment Objectives . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 6 3.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 6
3.3. Attacks Against Long-Term Shared Secrets in Smart Cards . 8 3.3. Attacks Against Long-Term Shared Secrets in Smart Cards . 7
4. Requirements Language . . . . . . . . . . . . . . . . . . . . 8 4. Requirements Language . . . . . . . . . . . . . . . . . . . . 8
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
6. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 11 6. Extensions to EAP-AKA' . . . . . . . . . . . . . . . . . . . 11
6.1. AT_PUB_ECDHE . . . . . . . . . . . . . . . . . . . . . . 11 6.1. AT_PUB_ECDHE . . . . . . . . . . . . . . . . . . . . . . 11
6.2. AT_KDF_FS . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. AT_KDF_FS . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. New Key Derivation Functions . . . . . . . . . . . . . . 14 6.3. Forward Secrecy Key Derivation Functions . . . . . . . . 14
6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 15 6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 15
6.5. Message Processing . . . . . . . . . . . . . . . . . . . 15 6.5. Message Processing . . . . . . . . . . . . . . . . . . . 16
6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 16 6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 16
6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 16 6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 16
6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 16 6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 16
6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 16 6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 17
6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 17 6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 17
6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 17 6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 18
6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 17 6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 18
6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 18 6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 18
6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 18 6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 18
6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 18 6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 18
6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 18 6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. Identity Privacy . . . . . . . . . . . . . . . . . . . . 23 7.1. Security Properties . . . . . . . . . . . . . . . . . . . 20
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7.2. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.3. Identity Privacy . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 7.4. Unprotected Data and Privacy . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . 24 7.5. Post-Quantum Considerations . . . . . . . . . . . . . . . 24
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
9.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
Many different attacks have been reported as part of revelations Many different attacks have been reported as part of revelations
associated with pervasive surveillance. Some of the reported attacks associated with pervasive surveillance. Some of the reported attacks
involved compromising the smart card supply chain, such as attacking involved compromising the smart card supply chain, such as attacking
SIM card manufacturers and operators in an effort to compromise SIM card manufacturers and operators in an effort to compromise
shared secrets stored on these cards. Such attacks are conceivable, shared secrets stored on these cards. Such attacks are conceivable,
for instance, during the manufacturing process of cards, or during for instance, during the manufacturing process of cards, or during
the transfer of cards and associated information to the operator. the transfer of cards and associated information to the operator.
skipping to change at page 3, line 46 skipping to change at page 4, line 5
they occur? they occur?
The authors want to provide a public specification of an extension The authors want to provide a public specification of an extension
that helps defend against one aspect of pervasive surveillance. This that helps defend against one aspect of pervasive surveillance. This
is important, given the large number of users such practices may is important, given the large number of users such practices may
affect. It is also a stated goal of the IETF to ensure that we affect. It is also a stated goal of the IETF 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]. This document does that take appropriate countermeasures [RFC7258]. This document does that
for EAP-AKA'. for EAP-AKA'.
This specification is an optional extension to the EAP-AKA' This specification updates [RFC9048], the EAP-AKA' authentication
authentication method [RFC9048]. While optional, the use of this method, with an optional extension. While optional, the use of this
extension is RECOMMENDED. extension is strongly RECOMMENDED.
The extension, when negotiated, provides Forward Secrecy for the The extension, when negotiated, provides Forward Secrecy (FS) for the
session key generated as a part of the authentication run in EAP- session key generated as a part of the authentication run in EAP-
AKA'. This prevents an attacker who has gained access to the long- AKA'. This prevents an attacker who has gained access to the long-
term pre-shared secret in a SIM card from being able to decrypt any term pre-shared secret in a SIM card from being able to decrypt any
past communications. In addition, if the attacker stays merely a past communications. In addition, if the attacker stays merely a
passive eavesdropper, the extension prevents attacks against future passive eavesdropper, the extension prevents attacks against future
sessions. This forces attackers to use active attacks instead. This sessions. This forces attackers to use active attacks instead. This
is beneficial, because active attacks demand much more resources to is beneficial, because active attacks demand much more resources to
launch, and can generally be detected much easier. As with other launch, and can generally be detected much easier. As with other
protocols, an active attacker with access to the long-term key protocols, an active attacker with access to the long-term key
material will of course be able to attack all future communications, material will of course be able to attack all future communications,
but risks detection, particularly if done at scale. The attacker is but risks detection, particularly if done at scale. The attacker is
forced to attempt to exfiltrate key material, if it can, on a forced to attempt to exfiltrate key material, if it can, on a
continuous basis, as opposed to learning it once [RFC7624]. continuous basis, as opposed to learning it once [RFC7624].
Attacks against AKA authentication via compromising the long-term Attacks against AKA authentication via compromising the long-term
secrets in the SIM cards have been an active discussion topic in many secrets in the SIM cards have been an active discussion topic in many
contexts. Forward secrecy is on the list of features for the next contexts. Forward secrecy is on the list of features for the next
release of 3GPP (5G Phase 2), and this document provides a basis for release of 3GPP (5G Phase 2), and this document provides a basis for
providing this feature in a particular fashion. providing this feature in a particular fashion.
It should also be noted that 5G network architecture includes the use It should also be noted that 5G network architecture [TS.33.501]
of the EAP framework for authentication. While any methods can be includes the use of the EAP framework for authentication. While any
run, the default authentication method within that context will be methods can be run, the default authentication method within that
EAP-AKA'. As a result, improvements in EAP-AKA' security have a context will be EAP-AKA'. As a result, improvements in EAP-AKA'
potential to improve security for large number of users. security have a potential to improve security for large number of
users.
2. Protocol Design and Deployment Objectives 2. Protocol Design and Deployment Objectives
This extension specified here re-uses large portions of the current The extension specified here re-uses 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 maintains the interface between the Universal the construction maintains the interface between the Universal
Subscriber Identification Module (USIM) and the mobile terminal Subscriber Identification Module (USIM) and the mobile terminal
intact. As a consequence, there is no need to roll out new 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 [TrustCom2015], and uses much of the same material, but applied
to EAP rather than the underlying AKA method. 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
skipping to change at page 5, line 38 skipping to change at page 5, line 43
o While EAP-AKA' is just one EAP method, for practical purposes o While EAP-AKA' is just one EAP method, for practical purposes
forward secrecy being available for both EAP-TLS [RFC5216] forward secrecy being available for both EAP-TLS [RFC5216]
[RFC9190] and EAP-AKA' ensures that for many practical systems [RFC9190] and EAP-AKA' ensures that for many practical systems
forward secrecy can be enabled for either all or significant forward secrecy can be enabled for either all or significant
fraction of users. fraction of users.
3. Background 3. Background
3.1. AKA 3.1. AKA
AKA is based on challenge-response mechanisms and symmetric Authentication and Key Agreement (AKA) is based on challenge-response
cryptography. AKA typically runs in a UMTS Subscriber Identity mechanisms and symmetric cryptography. In contrast with its earlier
Module (USIM) or a CDMA2000 (Removable) User Identity Module GSM counterparts, AKA provides long key lengths and mutual
((R)UIM). In contrast with its earlier GSM counterparts, AKA authentication. AKA typically runs in a UMTS Subscriber Identity
provides long key lengths and mutual authentication. Module (USIM). USIM is technically just an application that can
reside on a removable UICC, an embedded UICC, or integrated in a
Trusted Execution Environment (TEE). In this document we use the
term "SIM card" to refer to any Subscriber Identity Module capable of
running AKA.
AKA works in the following manner: AKA works in the following manner:
o The identity module and the home environment have agreed on a o The identity module and the home environment have agreed on a
secret key beforehand. secret key beforehand.
o The actual authentication process starts by having the home o The actual authentication process starts by having the home
environment produce an authentication vector, based on the secret environment produce an authentication vector, based on the secret
key and a sequence number. The authentication vector contains a key and a sequence number. The authentication vector contains a
random part RAND, an authenticator part AUTN used for random part RAND, an authenticator part AUTN used for
skipping to change at page 7, line 5 skipping to change at page 6, line 44
3.2. EAP-AKA' Protocol 3.2. EAP-AKA' Protocol
When AKA are embedded into EAP, the authentication on the network When AKA are embedded into EAP, the authentication on the network
side is moved to the home environment; the serving network performs side is moved to the home environment; the serving network performs
the role of a pass-through authenticator. Figure 1 describes the the role of a pass-through authenticator. Figure 1 describes the
basic flow in the EAP-AKA' authentication process. The definition of basic flow in the EAP-AKA' authentication process. The definition of
the full protocol behaviour, along with the definition of attributes the full protocol behaviour, along with the definition of attributes
AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in [RFC9048] and AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in [RFC9048] and
[RFC4187]. [RFC4187].
Peer Server Peer Server
| EAP-Request/Identity | | |
|<------------------------------------------------------| | EAP-Request/Identity |
| | |<-----------------------------------------------------------|
| EAP-Response/Identity | | |
| (Includes user's Network Access Identifier, NAI) | | EAP-Response/Identity |
|------------------------------------------------------>| | (Includes user's Network Access Identifier, NAI) |
| +-------------------------------------------------+ |----------------------------------------------------------->|
| | Server determines the network name and ensures | | +--------------------------------------------------------+
| | that the given access network is authorized to | | | Server determines the network name and ensures that |
| | use the claimed name. The server then runs the | | | the given access network is authorized to use the |
| | AKA' algorithms generating RAND and AUTN, | | | claimed name. The server then runs the AKA' algorithms |
| | derives session keys from CK' and IK'. RAND and | | | generating RAND and AUTN, derives session keys from |
| | AUTN are sent as AT_RAND and AT_AUTN attributes,| | | CK' and IK'. RAND and AUTN are sent as AT_RAND and |
| | whereas the network name is transported in the | | | AT_AUTN attributes, whereas the network name is |
| | AT_KDF_INPUT attribute. AT_KDF signals the used | | | transported in the AT_KDF_INPUT attribute. AT_KDF |
| | key derivation function. The session keys are | | | signals the used key derivation function. The session |
| | used in creating the AT_MAC attribute. | | | keys are used in creating the AT_MAC attribute. |
| +-------------------------------------------------+ | +--------------------------------------------------------+
| EAP-Request/AKA'-Challenge | | |
| (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC)| | EAP-Request/AKA'-Challenge |
|<------------------------------------------------------| | (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) |
+-----------------------------------------------------+ | |<-----------------------------------------------------------|
| The peer determines what the network name should be,| | +--------------------------------------------------------+ |
| based on, e.g., what access technology it is using.| | | The peer determines what the network name should be, | |
| The peer also retrieves the network name sent by | | | based on, e.g., what access technology it is using. | |
| the network from the AT_KDF_INPUT attribute. The | | | The peer also retrieves the network name sent by the | |
| two names are compared for discrepancies, and if | | | network from the AT_KDF_INPUT attribute. The two names | |
| necessary, the authentication is aborted. Otherwise,| | | are compared for discrepancies, and if necessary, the | |
| the network name from AT_KDF_INPUT attribute is | | | authentication is aborted. Otherwise, the network name | |
| used in running the AKA' algorithms, verifying AUTN | | | from AT_KDF_INPUT attribute is used in running the | |
| from AT_AUTN and MAC from AT_MAC attributes. The | | | AKA' algorithms, verifying AUTN from AT_AUTN and MAC | |
| peer then generates RES. The peer also derives | | | from AT_MAC attributes. The peer then generates RES. | |
| session keys from CK'/IK'. The AT_RES and AT_MAC | | | The peer also derives session keys from CK'/IK'. The | |
| attributes are constructed. | | | AT_RES and AT_MAC attributes are constructed. | |
+-----------------------------------------------------+ | +--------------------------------------------------------+ |
| EAP-Response/AKA'-Challenge | | |
| (AT_RES, AT_MAC) | | EAP-Response/AKA'-Challenge |
|------------------------------------------------------>| | (AT_RES, AT_MAC) |
| +-------------------------------------------------+ |----------------------------------------------------------->|
| | Server checks the RES and MAC values received | | +--------------------------------------------------------+
| | in AT_RES and AT_MAC, respectively. Success | | | Server checks the RES and MAC values received in |
| | requires both to be found correct. | | | AT_RES and AT_MAC, respectively. Success requires both |
| +-------------------------------------------------+ | | to be found correct. |
| EAP-Success | | +--------------------------------------------------------+
|<------------------------------------------------------| | |
| EAP-Success |
|<-----------------------------------------------------------|
Figure 1: EAP-AKA' Authentication Process Figure 1: EAP-AKA' Authentication Process
3.3. Attacks Against Long-Term Shared Secrets in Smart Cards 3.3. Attacks Against Long-Term Shared Secrets in Smart Cards
Current 3GPP systems use SIM pre-shared key based protocols and Current 3GPP systems use SIM pre-shared key based protocols and
Authentication and Key Agreement (AKA) to authenticate subscribers. Authentication and Key Agreement (AKA) to authenticate subscribers.
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 vulnerability in that discussion relates to the recent An important vulnerability in that discussion relates to the recent
reports of compromised long term pre-shared keys used in AKA reports of compromised long term pre-shared keys used in AKA
skipping to change at page 8, line 35 skipping to change at page 8, line 28
4. Requirements Language 4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
5. Protocol Overview 5. Protocol Overview
Introducing FS for EAP-AKA' can be achieved by using an Elliptic Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve
Curve Diffie-Hellman (ECDH) exchange [RFC7748]. In EAP-AKA' FS this Diffie-Hellman (ECDH) exchange [RFC7748]. To provide FS, the
exchange is run in an ephemeral manner, i.e., both sides generate exchange must be run in an ephemeral manner, i.e., both sides
temporary keys as specified in [RFC7748]. This method is referred to generate temporary keys according to the negotiated ciphersuite,
as ECDHE, where the last 'E' stands for Ephemeral. The two intially e.g., for X25519 this is done as specified in [RFC7748]. This method
registered elliptic curves and their wire format is chosen to align is referred to as ECDHE, where the last 'E' stands for Ephemeral.
with the elliptic curves and formats specified for Subscription The two initially registered elliptic curves and their wire format is
Concealed Identifier (SUCI) encryption in Appendix C.3.4 of 3GPP TS chosen to align with the elliptic curves and formats specified for
33.501 Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4
of 3GPP TS 33.501 [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 can ignore. that legacy implementations can 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 our goal has Figure 2 below describes the overall process. Since our goal has
been to not require new infrastructure or credentials, the flow been to not require new infrastructure or credentials, the flow
diagrams also show the conceptual interaction with the USIM card and diagrams also show the conceptual interaction with the USIM card and
the 3GPP authentication server (HSS). The details of those the 3GPP authentication server (HSS). 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 . reader is referred to the 3GPP specifications.
USIM Peer Server HSS USIM Peer Server HSS
| | | | | | | |
| | EAP-Req/Identity | | | | EAP-Req/Identity | |
| |<-------------------------| | | |<---------------------------| |
| | | | | | | |
| | EAP-Resp/Identity | | | | EAP-Resp/Identity | |
| |------------------------->| | | | (Privacy-Friendly) | |
| | | | | |--------------------------->| |
| +-------------------------------------------------+ | +--------------------------------------------------------+
| | Server now has an identity for the peer. | | | Server now has an identity for the peer. The server |
| | The server then asks the help of | | | then asks the help of HSS to run AKA algorithms, |
| | HSS to run AKA algorithms, generating RAND, | | | generating RAND, AUTN, XRES, CK, IK. Typically, the |
| | AUTN, XRES, CK, IK. Typically, the HSS performs | | | HSS performs the first part of key derivations so that |
| | the first part of key derivations so that the | | | the authentication server gets the CK' and IK' keys |
| | authentication server gets the CK' and IK' keys | | | already tied to a particular network name. |
| | already tied to a particular network name. | | +--------------------------------------------------------+
| +-------------------------------------------------+ | | | |
| | | | | | | ID, key deriv. |
| | | ID, | | | | function, |
| | | key deriv. | | | | network name |
| | | function, | | | |--------------->|
| | | network name| | | | |
| | |------------>| | | | RAND, AUTN, |
| | | | | | | XRES, CK', IK' |
| | | RAND, AUTN, | | | |<---------------|
| | | XRES, CK', | | +--------------------------------------------------------+
| | | IK' | | | Server now has the needed authentication vector. It |
| | |<------------| | | generates an ephemeral key pair, sends the public key |
| | | | | | of that key pair and the first EAP method message to |
| +-------------------------------------------------+ | | the peer. In the message the AT_PUB_ECDHE attribute |
| | Server now has the needed authentication vector.| | | carries the public key and the AT_KDF_FS attribute |
| | It generates an ephemeral key pair, sends the | | | carries other FS-related parameters. Both of these are |
| | public key of that key pair and the first EAP | | | skippable attributes that can be ignored if the peer |
| | method message to the peer. In the message the | | | does not support this extension. |
| | AT_PUB_ECDHE attribute carries the public key | | +--------------------------------------------------------+
| | and the AT_KDF_FS attribute carries other FS- | | | | |
| | related parameters. Both of these are skippable | | | EAP-Req/AKA'-Challenge | |
| | attributes that can be ignored if the peer does | | | AT_RAND, AT_AUTN, AT_KDF, | |
| | not support this extension. | | | AT_KDF_FS, AT_KDF_INPUT, | |
| +-------------------------------------------------+ | | AT_PUB_ECDHE, AT_MAC | |
| | | | | |<---------------------------| |
| | EAP-Req/AKA'-Challenge | | +--------------------------------------------------------+ |
| | AT_RAND, AT_AUTN, AT_KDF,| | | The peer checks if it wants to do the FS extension. If | |
| | AT_KDF_FS, AT_KDF_INPUT, | | | yes, it will eventually respond with AT_PUB_ECDHE and | |
| | AT_PUB_ECDHE, AT_MAC | | | AT_MAC. If not, it will ignore AT_PUB_ECDHE and | |
| |<-------------------------| | | AT_KDF_FS and base all calculations on basic EAP-AKA' | |
+-----------------------------------------------------+ | | attributes, continuing just as in EAP-AKA' per RFC | |
| The peer checks if it wants to do the FS extension.| | | 9048 rules. In any case, the peer needs to query the | |
| If yes, it will eventually respond with AT_PUB_ECDHE| | | auth parameters from the USIM card. | |
| and AT_MAC. If not, it will ignore AT_PUB_ECDHE and | | +--------------------------------------------------------+ |
| AT_KDF_FS and base all calculations on basic | | | | | |
| EAP-AKA' attributes, continuing just as in EAP-AKA' | | | RAND, AUTN | | |
| per RFC 5448 (draft-ietf-emu-rfc5448bis) rules. | | |<-------------| | |
| In any case, the peer needs to query the auth | | | | | |
| parameters from the USIM card. | | | CK, IK, RES | | |
+-----------------------------------------------------+ | |------------->| | |
| | | | +--------------------------------------------------------+ |
| RAND, AUTN | | | | The peer now has everything to respond. If it wants to | |
|<---------------| | | | participate in the FS extension, it will then generate | |
| | | | | its key pair, calculate a shared key based on its key | |
| CK, IK, RES | | | | pair and the server's public key. Finally, it proceeds | |
|-------------->| | | | to derive all EAP-AKA' key values and constructs a | |
| | | | | full response. | |
+-----------------------------------------------------+ | +--------------------------------------------------------+ |
| The peer now has everything to respond. If it wants | | | | | |
| to participate in the FS extension, it will then | | | | EAP-Resp/AKA'-Challenge | |
| generate its key pair, calculate a shared key based | | | | AT_RES, AT_PUB_ECDHE, | |
| on its key pair and the server's public key. | | | | AT_MAC | |
| Finally, it proceeds to derive all EAP-AKA' key | | | |--------------------------->| |
| values and and constructs a full response. | | | +--------------------------------------------------------+
+-----------------------------------------------------+ | | | The server now has all the necessary values. It |
| | | | | | generates the ECDHE shared secret and checks the RES |
| | EAP-Resp/AKA'-Challenge | | | | and MAC values received in AT_RES and AT_MAC, |
| | AT_RES, AT_PUB_ECDHE, | | | | respectively. Success requires both to be found |
| | AT_MAC | | | | correct. Note that when this specification is used, |
| |------------------------->| | | | the keys generated from EAP-AKA' are based on both |
| +-------------------------------------------------+ | | CK/IK as well as the ECDHE value. Even if there was an |
| | The server now has all the necessary values. | | | attacker who held the long-term secret keys, only an |
| | It generates the ECDHE shared secret | | | active attacker could have determined the generated |
| | and checks the RES and MAC values received | | | session keys; in basic EAP-AKA' the keys are only |
| | in AT_RES and AT_MAC, respectively. Success | | | based on CK and IK. |
| | requires both to be found correct. Note that | | +--------------------------------------------------------+
| | when this specification is used, the keys | | | | |
| | generated from EAP-AKA' are based on both | | | EAP-Success | |
| | CK/IK as well as the ECDHE value. Even if there | | |<---------------------------| |
| | was an attacker who held the long-term secret |
| | keys, only an active attacker could have |
| | determined the generated session keys; in basic |
| | EAP-AKA' the keys are only based on CK and IK. |
| +-------------------------------------------------+
| | | |
| | 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 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 TBA1 BY IANA.
Length Length
The length of the attribute, set as other attributes in EAP-AKA The length of the attribute, set as other attributes in EAP-AKA
[RFC4187]. [RFC4187].
Value Value
This value is the sender's ECDHE public value. It is calculated This value is the sender's ECDHE public key. The value depends on
as follows: AT_KDF_FS and is calculated as follows:
* For X25519/Curve25519, the length of this value is 32 bytes, * For X25519/Curve25519, the length of this value is 32 bytes,
encoded in binary as specified [RFC7748] Section 6.1. encoded as specified in [RFC7748] Section 5.
* For P-256, the length of this value is 33 bytes, encoded in * For P-256, the length of this value is 33 bytes, encoded using
binary as specified in [FIPS186-4], using the compressed form the compressed form specified in Section 2.3.3 of [SEC1].
from Section 2.7.1 of [SEC2].
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 key generation function, The AT_KDF_FS indicates the used or desired forward secrecy key
if the Forward Secrecy extension is taken into use. It will also at generation function, if the Forward Secrecy extension is taken into
the same time indicate the used or desired ECDHE group. A new use. It will also at the same time indicate the used or desired
attribute is needed to carry this information, as AT_KDF carries the ECDHE group. A new attribute is needed to carry this information, as
legacy KDF value for those EAP peers that cannot or do not want to AT_KDF carries the basic KDF value which is still used together with
use this extension. the forward secrecy KDF value. The basic KDF value is also used by
those EAP peers that cannot or do not want to use this extension.
This specification only specifies the behaviour relating to the
following combinations of basic KDF values and forward secrecy KDF
values: The 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
forward secrecy 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 | 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 TBA2 BY IANA.
Length Length
The length of the attribute, MUST be set to 1. The length of the attribute, MUST be set to 1.
Key Derivation Function FS Key Derivation Function
An enumerated value representing the key derivation function that An enumerated value representing the forward secrecy key
the server (or peer) wishes to use. See Section 6.3 for the derivation function that the server (or peer) wishes to use. See
functions specified in this document. Note: This field has a Section 6.3 for the functions specified in this document. Note:
different name space than the similar field in the AT_KDF This field has a different name space than the similar field in
attribute Key Derivation Function defined in [RFC9048]. the AT_KDF attribute Key Derivation Function defined 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, the most preferred function
being the first attribute. The most preferred function is the only being the first attribute. The most preferred function is the only
one that the server includes a public key value for, however. So for one that the server includes a public key value for, however. So for
a set of AT_KDF_FS attributes, there is always only one AT_PUB_ECDHE a set of AT_KDF_FS attributes, there is always only one AT_PUB_ECDHE
attribute. attribute.
Upon receiving a set of these attributes: Upon receiving a set of these attributes:
o If the peer supports and is willing to use the key derivation o If the peer supports and is willing to use the FS Key Derivation
function indicated by the first AT_KDF_FS attribute, and is Function indicated by the first AT_KDF_FS attribute, and is
willing and able to use the extension defined in this willing and able to use the extension defined in this
specification, the function is taken into use without any further specification, the function is taken into use without any further
negotiation. negotiation.
o If the peer does not support this function or is unwilling to use o 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 EAP-Response/AKA'-
Challenge message that contains only one attribute, AT_KDF_FS with Challenge message that contains only one attribute, AT_KDF_FS with
the value set to the desired alternative function from among the the value set to the desired alternative function from among the
skipping to change at page 13, line 43 skipping to change at page 13, line 43
message from the server is not a valid alternative. If the peer has message from the server is not a valid alternative. If the peer has
replied with the first AT_KDF_FS value, the server behaves as if replied with the first AT_KDF_FS value, the server behaves as if
AT_MAC of the response had been incorrect and fails the AT_MAC of the response had been incorrect and fails the
authentication. For an overview of the failed authentication process authentication. For an overview of the failed authentication process
in the server side, see Section 3 and Figure 2 in [RFC4187]. in the server side, see Section 3 and Figure 2 in [RFC4187].
Otherwise, the server re-sends the EAP-Response/AKA'-Challenge Otherwise, the server re-sends the EAP-Response/AKA'-Challenge
message, but adds the selected alternative to the beginning of the message, but adds the selected alternative to the beginning of the
list of AT_KDF_FS attributes, and retains the entire list following list of AT_KDF_FS attributes, and retains the entire list following
it. Note that this means that the selected alternative appears twice it. Note that this means that the selected alternative appears twice
in the set of AT_KDF values. Responding to the peer's request to in the set of AT_KDF values. Responding to the peer's request to
change the key derivation function is the only legal situation where change the FS Key Derivation Function is the only legal situation
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 yes, it continues.
If not, it behaves as if AT_MAC had been incorrect and fails the If not, it behaves as if AT_MAC had been 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 had been
incorrect and fail the authentication. incorrect and fail the authentication.
6.3. New Key Derivation Functions 6.3. Forward Secrecy Key Derivation Functions
Two new Key Derivation Function types are defined for "EAP-AKA' with Two new FS Key Derivation Function types are defined for "EAP-AKA'
ECDHE and X25519", represented by value 1, and "EAP-AKA' with ECDHE with ECDHE and X25519", represented by value 1, and "EAP-AKA' with
and P-256", represented by value 2. These represent a particular ECDHE and P-256", represented by value 2. These represent a
choice of key derivation function and at the same time selects an particular choice of key derivation function and at the same time
ECDHE group to be used. selects an ECDHE group to be used.
The Key Derivation Function type value is only used in the AT_KDF_FS The FS Key Derivation Function type value is only used in the
attribute, and should not be confused with the different range of key AT_KDF_FS attribute. When the forward secrecy extension is used, the
derivation functions that can be represented in the AT_KDF attribute AT_KDF_FS attribute determines how to derive the keys MK_ECDHE, K_re,
as defined in [RFC9048]. MSK, and EMSK. The AT_KDF_FS attribute should not be confused with
the different range of key derivation functions that can be
represented in the AT_KDF attribute as defined in [RFC9048]. When
the forward secrecy extension is used, the AT_KDF attribute only
specifies how to derive the keys MK, K_encr, and K_aut.
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 [RFC9048] EAP-AKA' internal use within one authentication run as [RFC9048] EAP-AKA'
does. For instance, K_aut that is used in AT_MAC is still exactly as does. For instance, K_aut that is used in AT_MAC is still exactly as
it was in EAP-AKA'. The only change to key derivation is in re- it was in EAP-AKA'. The only change to key derivation is in re-
authentication keys and keys exported out of the EAP method, MSK and authentication keys and keys exported out of the EAP method, MSK and
EMSK. As a result, EAP-AKA' attributes such as AT_MAC continue to be EMSK. As a result, EAP-AKA' attributes such as AT_MAC continue to be
usable even when this extension is in use. usable even when this extension is in use.
When the Key Derivation Function field in the AT_KDF_FS attribute is When the FS Key Derivation Function field in the AT_KDF_FS attribute
set to 1 and the Key Derivation Function field in the AT_KDF is set to 1 or 2 and the Key Derivation Function field in the AT_KDF
attribute is also set to 1, the Master Key (MK) is derived as follows attribute is set to 1, the Master Key (MK) is derived as follows
below. below.
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]
Where SHARED_SECRET is the shared secret computed via ECDHE, as Requirements for how to securely generate, validate, and process the
specified in Section 6.1 of [RFC7748]. ephemeral public keys depend on the elliptic curve.
Both the peer and the server MAY check for zero-value shared secret For P-256 the SHARED_SECRET is the shared secret computed as
as specified in Section 6.1 of [RFC7748]. If such checking is specified in Section 5.7.1.2 of [SP-800-56A]. Public key validation
performed and the SHARED_SECRET has a zero value, both parties MUST requirements are defined in Section 5 of [SP-800-56A]. At least
behave as if the current EAP-AKA' authentication process starts again partial public-key validation MUST be done.
from the beginning.
For X25519 the SHARED_SECRET is the shared secret computed as
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
[RFC7748].
Note: The way that shared secret is tested for zero can, if Note: The way that shared secret is tested for zero can, if
performed inappropriately, provide an ability for attackers to performed inappropriately, provide an ability for attackers to
listen to CPU power usage side channels. Refer to [RFC7748] for a listen to CPU power usage side channels. Refer to [RFC7748] for a
description of how to perform this check in a way that it does not description of how to perform this check in a way that it does not
become a problem. become a problem.
If validation of the public key or the shared secret fails, both
parties MUST behave as if the current EAP-AKA' authentication process
starts again from the beginning.
The rest of computation proceeds as defined in Section 3.3 of The rest of 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 pseudo-random 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 eight-characters-long ASCII string. It is
used as is, without any trailing NUL characters. Similarly, "EAP- used as is, without any trailing NUL characters. Similarly, "EAP-
AKA' FS" is an eleven-characters-long ASCII string, also used as is. AKA' FS" is an eleven-characters-long ASCII string, 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 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
deciding to use of particular key derivation function in AT_KDF_FS. deciding to use of particular key derivation function in AT_KDF_FS.
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 group
(SEC group secp256r1), specified in [FIPS186-4]. The support for (SEC group secp256r1), specified in Appendix D.1.2.3 of [FIPS186-4]
this group is OPTIONAL. or alternatively Section 2.4.2 of [SEC2]. The support for this group
is REQUIRED.
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
extension than the base EAP-AKA' or EAP-AKA protocol. Unless extension than the base EAP-AKA' or EAP-AKA protocol. Unless
otherwise specified here, the rules from [RFC9048] or [RFC4187] otherwise specified here, the rules from [RFC9048] or [RFC4187]
skipping to change at page 16, line 16 skipping to change at page 16, line 30
6.5.1. EAP-Request/AKA'-Identity 6.5.1. EAP-Request/AKA'-Identity
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
NOT be added to this message. The appearance of these messages in a NOT be added to this message. The appearance of these messages in a
received message MUST be ignored. received message MUST be ignored.
6.5.2. EAP-Response/AKA'-Identity 6.5.2. EAP-Response/AKA'-Identity
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
NOT be added to this message. The appearance of these messages in a NOT be added to this message and that a privacy-friendly identifier
received message MUST be ignored. MUST be used. The appearance of these messages in a received message
MUST be ignored.
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 EAP-Request/AKA'-Challenge, there is no message-specific data
skipping to change at page 17, line 37 skipping to change at page 17, line 51
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, if the
extension specified in this documents is in use, employs key material extension specified in this document is in use, employs key material
from the Diffie-Hellman procedure. from the Diffie-Hellman procedure.
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
skipping to change at page 18, line 47 skipping to change at page 19, line 11
personnel, etc. But not all attacks can be entirely ruled out for personnel, etc. But not all attacks can be entirely ruled out for
well-resourced adversaries, irrespective of what the technical well-resourced adversaries, irrespective of what the technical
algorithms and protection measures are. Always assuming breach such algorithms and protection measures are. Always assuming breach such
as key compromise and minimizing the impact of breach are essential as key compromise and minimizing the impact of breach are essential
zero-trust principles. zero-trust principles.
If a mechanism without forward secrecy such as (5G-AKA, EAP-AKA') is If a mechanism without forward secrecy such as (5G-AKA, EAP-AKA') is
used the effects of key compromise are devastating. The serious used the effects of key compromise are devastating. The serious
consequences of breach somewhere in the supply chain or after consequences of breach somewhere in the supply chain or after
delivery that are possible when 5G-AKA or EAP-AKA' is used but not delivery that are possible when 5G-AKA or EAP-AKA' is used but not
when something with forward secrecy like EAP-AKA-FS is used are: 1. when something with forward secrecy like EAP-AKA-FS is used are:
A passive attacker can eavesdrop (decrypt) all future 5G
communication (control and user plane both directions), 2. A passive 1. A passive attacker can eavesdrop (decrypt) all future 5G
attacker can decrypt 5G communication that they previously recorded communication (control and user plane both directions),
in the past (control and user plane both directions), and 3. An
active attacker can impersonate UE and Network and inject messages in 2. A passive attacker can decrypt 5G communication that they
an ongoing 5G connection between the real UE and the real network previously recorded in the past (control and user plane both
(control and user plane both directions). directions), and
3. An active attacker can impersonate UE and Network and inject
messages in an ongoing 5G connection between the real UE and the
real network (control and user plane both directions).
Best practice security today is to mandate forward secrecy (as is Best practice security today is to mandate forward secrecy (as is
done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, etc). It is RECOMMENDED to done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, IKEv2, SSH, QUIC, WireGuard,
long term completely phase out AKA without forward secrecy. Signal, etc.). It is RECOMMENDED to long term completely phase out
AKA without forward secrecy.
This extension can provide assistance in situations where there is a This extension can provide assistance in situations where there is a
danger of attacks against the key material on SIM cards by danger of attacks against the key material on SIM cards by
adversaries that cannot or who are unwilling to mount active attacks adversaries that cannot or who are unwilling to mount active attacks
against large number of sessions. The extension also provides against large number of sessions. The extension also provides
protection against active attacks as they are forced to be a Man-In- protection against active attacks as they are forced to be a Man-In-
The-Middle (MITM) during the AKA run and subsequent communication The-Middle (MITM) during the AKA run and subsequent communication
between the parties. Without forward secrecy an an active attacker between the parties. Without forward secrecy an active attacker that
that has compromised the long-term key can inject messages in an has compromised the long-term key can inject messages in an
connection betwen the real Peer and the real server without being a connection between the real Peer and the real server without being a
man-in-the-middle. This extension is most useful when used in a man-in-the-middle. This extension is most useful when used in a
context where EAP keys are used without further mixing that can context where EAP keys are used without further mixing that can
provide Forward Secrecy. For instance, when used with IKEv2 provide Forward Secrecy. For instance, when used with IKEv2
[RFC7296], the session keys produced by IKEv2 have this property, so [RFC7296], the session keys produced by IKEv2 have this property, so
better characteristics of EAP keys is not that useful. However, better characteristics of EAP keys is not that useful. However,
typical link layer usage of EAP does not involve running Diffie- typical link layer usage of EAP does not involve running Diffie-
Hellman, so using EAP to authenticate access to a network is one Hellman, so using EAP to authenticate access to a network is one
situation where the extension defined in this document can be situation where the extension defined in this document can be
helpful. helpful.
skipping to change at page 20, line 17 skipping to change at page 20, line 35
key at time T2 does not compromise some key at time T1 where T1 < key at time T2 does not compromise some key at time T1 where T1 <
T2). Protection in the other direction (compromise at time T1 does T2). Protection in the other direction (compromise at time T1 does
not compromise keys at time T2) can be achieved by rerunning ECDHE not compromise keys at time T2) can be achieved by rerunning ECDHE
frequently. If a long-term authentication key has been compromised, frequently. If a long-term authentication key has been compromised,
rerunning EAP-AKA' FS gives protection against passive attackers. rerunning EAP-AKA' FS gives protection against passive attackers.
Using the terms in [RFC7624], forward secrecy without rerunning ECDHE Using the terms in [RFC7624], forward secrecy without rerunning ECDHE
does not stop an attacker from doing static key exfiltration. does not stop an attacker from doing static key exfiltration.
Frequently rerunning EC(DHE) forces an attacker to do dynamic key Frequently rerunning EC(DHE) forces an attacker to do dynamic key
exfiltration (or content exfiltration). exfiltration (or content exfiltration).
7.1. 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 key
derivation functions, and this mechanism has been extended by the derivation functions, and this mechanism has been extended by the
extension specified in this document. The resulting mechanism extension specified in this document. The resulting mechanism
continues to be secure against bidding down attacks. continues to be secure against bidding down attacks.
skipping to change at page 22, line 11 skipping to change at page 22, line 33
This extension does not change the properties related to re- This extension does not change the properties related to re-
authentication. No new Diffie-Hellman run is performed during the authentication. No new Diffie-Hellman run is performed during the
re-authentication allowed by EAP-AKA'. However, if this extension re-authentication allowed by EAP-AKA'. However, if this extension
was in use when the original EAP-AKA' authentication was was in use when the original EAP-AKA' authentication was
performed, the keys used for re-authentication (K_re) are based on performed, the keys used for re-authentication (K_re) are based on
the Diffie-Hellman keys, and hence continue to be equally safe the Diffie-Hellman keys, and hence continue to be equally safe
against expose of the long-term secrets as the original against expose of the long-term secrets as the original
authentication. authentication.
7.2. Denial-of-Service
In addition, it is worthwhile to discuss Denial-of-Service attacks In addition, it is worthwhile to discuss Denial-of-Service attacks
and their impact on this protocol. The calculations involved in and their impact on this protocol. The calculations involved in
public key cryptography require computing power, which could be used public key cryptography require computing power, which could be used
in an attack to overpower either the peer or the server. While some in an attack to overpower either the peer or the server. While some
forms of Denial-of-Service attacks are always possible, the following forms of Denial-of-Service attacks are always possible, the following
factors help mitigate the concerns relating to public key factors help mitigate the concerns relating to public key
cryptography and EAP-AKA' FS. cryptography and EAP-AKA' FS.
o In 5G context, other parts of the connection setup involve public o In 5G context, other parts of the connection setup involve public
key cryptography, so while performing additional operations in key cryptography, so while performing additional operations in
skipping to change at page 23, line 7 skipping to change at page 23, line 31
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 secret that the parties need to show possession of the long-term secret
in some way, and only then will the FS calculations become active. in some way, and only then will the FS calculations become active.
This limits the Denial-of-Service to specific, identified This limits the Denial-of-Service to specific, identified
subscribers. While botnets and other forms of malicious parties subscribers. While botnets and other forms of malicious parties
could take advantage of actual subscribers and their key material, could take advantage of actual subscribers and their key material,
at least such attacks are (a) limited in terms of subscribers they at least such attacks are (a) limited in terms of subscribers they
control, and (b) identifiable for the purposes of blocking the control, and (b) identifiable for the purposes of blocking the
affected subscribers. affected subscribers.
7.1. Identity Privacy 7.3. Identity Privacy
Best practice privacy today is to mandate client identity protection Best practice privacy today is to mandate client identity protection
as is done in EAP-TLS 1.3, EAP-TTLS 1.3, etc. A client supporting as is done in EAP-TLS 1.3, EAP-TTLS 1.3, etc. A client supporting
EAP-AKA' FS MUST NOT send its username (or any other permanent EAP-AKA' FS MUST NOT send its username (or any other permanent
identifiers) in cleartext in the Identity Response (or any message identifiers) in cleartext in the Identity Response (or any message
used instead of the Identity Response). used instead of the Identity Response).
7.4. Unprotected Data and Privacy
Unprotected data and metadata can reveal sensitive information and
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_FS, and AT_PUB_ECDHE reveal the used cryptographic algorithms,
if these depend on the peer identity they leak information about the
peer. AT_KDF_INPUT reveals the network name, although that is done
on purpose to bind the authentication to a particular context.
An attacker observing network traffic may use the above types of
information for traffic flow analysis or to track an endpoint.
7.5. Post-Quantum Considerations
As of the publication of this specification, it is unclear when or
even if a quantum computer of sufficient size and power to exploit
elliptic curve cryptography will exist. Deployments that need to
consider risks decades into the future should transition to Post-
Quantum Cryptography (PQC) in the not-too-distant future. Other
systems may employ PQC when the quantum threat is more imminent.
Current PQC algorithms have limitations compared to Elliptic Curve
Cryptography (ECC) and the data sizes could be problematic for some
constrained systems. If a Cryptographically Relevant Quantum
Computer (CRQC) is built it could recover the SHARED_SECRET from the
ECDHE public keys.
This would not affect the ability of EAP-AKA' - with or without this
extension - to authenticate properly, however. As symmetric key
cryptography is safe even if CRQCs are built, an adversary still will
not be able to disrupt authentication as it requires computing a
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.
Other output keys do include SHARED_SECRET via MK_ECDHE, but still
include also CK' and IK' which are entirely based on symmetricy
cryptography. As a result, an adversary with a quantum computer
still cannot compute the other output keys either.
However, if the adversary has also obtained knowledge of the secrets
associated with the SIM card, they could then compute CK', IK', and
SHARED_SECRET, and any derived output keys. This means that the the
introduction of a powerful enough quantum computer would disable this
protocol extension's ability to provide the forward security
capability. This would make it necessary to update the current ECC
algorithms in this specification to PQC algorithms. This
specification does not add such algorithms, but a future update can
do that.
Symmetric algorithms used in EAP-AKA' FS such as HMAC-SHA-256 and the
algorithms use to generate AT_AUTN and AT_RES are practically secure
against even large robust quantum computers. EAP-AKA' FS is
currently only specified for use with ECDHE key exchange algorithms,
but use of any Key Encapsulation Method (KEM), including Post-Quantum
Cryptography (PQC) KEMs, can be specified in the future. While the
key exchange is specified with terms of the Diffie-Hellman protocol,
the key exchange adheres to a KEM interface. AT_PUB_ECDHE would then
contain either the ephemeral public key of the server or the
SHARED_SECRET encapsulated with the server's public 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 EAP-SIM [RFC4186], EAP-AKA [RFC4186], and EAP-AKA' [RFC9048]. with EAP-SIM [RFC4186], EAP-AKA [RFC4186], and EAP-AKA' [RFC9048].
Two new Attribute Type value (TBA1, TBA2) in the skippable range need Two new Attribute Type value (TBA1, TBA2) in the skippable range need
to be assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_FS to be assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_FS
(Section 6.2 in the EAP-AKA and EAP-SIM Parameters registry under (Section 6.2 in the EAP-AKA and EAP-SIM Parameters registry under
Attribute Types. Attribute Types.
Also, a new registry should be created to represent Diffie-Hellman Also, a new registry should be created to represent FS Key Derivation
Key Derivation Function types. The "EAP-AKA' with ECDHE and X25519" Function types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA'
and "EAP-AKA' with ECDHE and P-256" types (1 and 2, see Section 6.3) with ECDHE and P-256" types (1 and 2, see Section 6.3) need to be
need to be assigned, along with one reserved value. The initial assigned, along with one reserved value. The initial contents of
contents of this namespace are therefore as below; new values can be this namespace are therefore as below; new values can be created
created through the Specification Required policy [RFC8126]. through the Specification Required policy [RFC8126].
Value Description Reference Value Description Reference
------ ------------------------------------ --------------- ------- ------------------------------ -----------------------
0 Reserved [TBD BY IANA: THIS RFC] 0 Reserved [TBD BY IANA: THIS RFC]
1 EAP-AKA' with ECDHE and X25519 [TBD BY IANA: THIS RFC] 1 EAP-AKA' with ECDHE and X25519 [TBD BY IANA: THIS RFC]
2 EAP-AKA' with ECDHE and P-256 [TBD BY IANA: THIS RFC] 2 EAP-AKA' with ECDHE and P-256 [TBD BY IANA: THIS RFC]
3-65535 Unassigned [TBD BY IANA: THIS RFC] 3-65535 Unassigned [TBD BY IANA: THIS RFC]
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, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
skipping to change at page 24, line 37 skipping to change at page 26, line 32
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>.
[FIPS186-4] [FIPS186-4]
NIST, , "Digital Signature Standard (DSS)", July 2013. NIST, "Digital Signature Standard (DSS)", FIPS 186-4, July
2013.
[SEC2] Certicom Research, , "SEC 2: Recommended Elliptic Curve [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
Domain Parameters", September 2000. Standards for Efficient Cryptography 1 (SEC 1) Version
2.0, May 2009.
[SEC2] Certicom Research, "SEC 2: Recommended Elliptic Curve
Domain Parameters", Standards for Efficient Cryptography 2
(SEC 2) Version 2.0, January 2010.
[SP-800-56A]
Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R.
Davis, "Recommendation for Pair-Wise Key-Establishment
Schemes Using Discrete Logarithm Cryptography",
NIST Special Publication 800-56A Revision 3, April 2018,
<https://doi.org/10.6028/NIST.SP.800-56Ar3>.
9.2. Informative References 9.2. Informative References
[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
skipping to change at page 25, line 26 skipping to change at page 27, line 38
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC9190] Preu&#258;&#159; Mattsson, J. and M. Sethi, "EAP-TLS 1.3: [RFC9190] Preu&#258;&#159; Mattsson, J. and M. Sethi, "EAP-TLS 1.3:
Using the Extensible Authentication Protocol with TLS Using the Extensible Authentication Protocol with TLS
1.3", RFC 9190, DOI 10.17487/RFC9190, February 2022, 1.3", 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., Naslund, M., and B. Sahlin, "A Arkko, J., Norrman, K., Naeslund, M., and B. Sahlin, "A
USIM compatible 5G AKA protocol with perfect forward USIM compatible 5G AKA protocol with perfect forward
secrecy", August 2015 in Proceedings of the TrustCom 2015, secrecy", Proceedings of IEEE International Conference on
IEEE. Trust, Security and Privacy in Computing and
Communications (TrustCom) 2015, August 2015.
[Heist2015] [Heist2015]
Scahill, J. and J. Begley, "The great SIM heist", February Scahill, J. and J. Begley, "The Great SIM Heist", February
2015, in https://firstlook.org/theintercept/2015/02/19/ 2015.
great-sim-heist/ .
[DOW1992] Diffie, W., vanOorschot, P., and M. Wiener, [DOW1992] Diffie, W., Van Oorschot, P., and M. Wiener,
"Authentication and Authenticated Key Exchanges", June "Authentication and Authenticated Key Exchanges", Designs,
1992, in Designs, Codes and Cryptography 2 (2): pp. Codes and Cryptography 2 pp. 107-125, June 1992.
107-125.
[TS.33.501]
3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501 17.6.0, June 2022.
Appendix A. Change Log Appendix A. Change Log
RFC Editor: Please remove this appendix.
The -08 version of the WG draft has the following changes:
o Further clarification of key calculation in Section 6.3.
o 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.
o 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.
o Addition of a discussion about the impacts of potential future
quantum computing attacks with specific impacts to this extension.
o Addition of a discussion about metadata/unproctected data in
Section 7.4.
o Reference updates.
o Various editorial improvements.
The -07 version of the WG draft has the following changes: The -07 version of the WG draft has the following changes:
o The impact of forward secrecy explanation has been improved in the o The impact of forward secrecy explanation has been improved in the
abstract and security considerations. abstract and security considerations.
o The draft now more forcefully explains why the authors believe it o The draft now more forcefully explains why the authors believe it
is important to migrate existing systems to use forward secrecy, is important to migrate existing systems to use forward secrecy,
and makes a recommendation for this migration. and makes a recommendation for this migration.
o The draft does no longer refer to issues within the smart cards o The draft does no longer refer to issues within the smart cards
skipping to change at page 27, line 19 skipping to change at page 30, line 10
ephemeral mode. The AT_KDF_FS negotiation process was clarified 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 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 checking for zero key values IN ECDHE was added. The format of the
actual key in AT_PUB_ECDHE was specified. Denial-of-service actual key in AT_PUB_ECDHE was specified. Denial-of-service
considerations for the FS process have been updated. Bidding down considerations for the FS process have been updated. Bidding down
attacks against this extension itself are discussed extensively. attacks against this extension itself are discussed extensively.
This version also addressed comments from reviewers, including the This version also addressed comments from reviewers, including the
August review from Mohit Sethi, and comments made during IETF-102 August review from Mohit Sethi, and comments made during IETF-102
discussion. discussion.
Appendix B. 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. Naslund, and B. Sahlin. This were J. Arkko, K. Norrman, M. Naeslund, and B. Sahlin. This
document uses also a lot of material from [RFC4187] by J. Arkko and document uses also 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 Tero Kivinen, John Mattsson, The authors would also like to thank Ben Campbell, Tim Evans, Zhang
Mohit Sethi, Vesa Lehtovirta, Russ Housley, Sean Turner, Eliot Lear, Fu, Russ Housley, Tero Kivinen, Eliot Lear, Vesa Lehtovirta, Kathleen
Joseph Salowey, Kathleen Moriarty, Zhang Fu, Bengt Sahlin, Ben Moriarty, Prajwol Kumar Nakarmi, Anand R. Prasad, Goeran Rune, Bengt
Campbell, Prajwol Kumar Nakarmi, Goran Rune, Tim Evans, Helena Vahidi Sahlin, Joseph Salowey, Mohit Sethi, Rene Struik, Sean Turner, Helena
Mazinani, Anand R. Prasad, Rene Struik, and many other people at the Vahidi Mazinani, and many other people at the IETF, GSMA and 3GPP
IETF, GSMA and 3GPP groups for interesting discussions in this groups for interesting discussions in this problem space.
problem space.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
skipping to change at page 28, line 4 skipping to change at page 30, line 41
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Karl Norrman Karl Norrman
Ericsson Ericsson
Stockholm 16483 Stockholm 16483
Sweden Sweden
Email: karl.norrman@ericsson.com Email: karl.norrman@ericsson.com
Vesa Torvinen Vesa Torvinen
Ericsson Ericsson
Jorvas 02420 Jorvas 02420
Finland Finland
Email: vesa.torvinen@ericsson.com Email: vesa.torvinen@ericsson.com
John Preuss Mattsson
John Mattsson
Ericsson Ericsson
Kista 164 40 Kista 164 40
Sweden Sweden
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
 End of changes. 64 change blocks. 
310 lines changed or deleted 449 lines changed or added

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