draft-ietf-emu-aka-pfs-05.txt   draft-arkko-eap-aka-pfs.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: RFC5448 (if approved) V. Torvinen
Intended status: Informational Ericsson Intended status: Informational Ericsson
Expires: May 3, 2021 October 30, 2020 Expires: September 8, 2022 March 7, 2022
Perfect-Forward Secrecy for the Extensible Authentication Protocol Forward Secrecy for the Extensible Authentication Protocol Method for
Method for Authentication and Key Agreement (EAP-AKA' PFS) Authentication and Key Agreement (EAP-AKA' FS)
draft-ietf-emu-aka-pfs-05 draft-ietf-emu-aka-pfs-06
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 smart cards, such as attacking SIM card involved compromising smart cards, such as attacking SIM card
manufacturers and operators in an effort to compromise shared secrets manufacturers and operators in an effort to compromise shared secrets
stored on these cards. Since the publication of those reports, stored on these cards. Since the publication of those reports,
manufacturing and provisioning processes have gained much scrutiny manufacturing and provisioning processes have gained much scrutiny
and have improved. However, the danger of resourceful attackers for and have improved. However, the danger of resourceful attackers for
these systems is still a concern. these systems is still a concern.
This specification is an optional extension to the EAP-AKA' This specification is an optional extension to the EAP-AKA'
authentication method which was defined in [I-D.ietf-emu-rfc5448bis]. authentication method which was defined in [RFC9048]. The extension,
The extension, when negotiated, provides Perfect Forward Secrecy for when negotiated, provides Forward Secrecy for the session key
the session key generated as a part of the authentication run in EAP- generated as a part of the authentication run in EAP-AKA'. This
AKA'. This prevents an attacker who has gained access to the long- prevents an attacker who has gained access to the long-term pre-
term pre-shared secret in a SIM card from being able to decrypt any shared secret in a SIM card from being able to decrypt any past
past communications. In addition, if the attacker stays merely a communications. In addition, if the attacker stays merely a passive
passive eavesdropper, the extension prevents attacks against future eavesdropper, the extension prevents attacks against future sessions.
sessions. This forces attackers to use active attacks instead. 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 May 3, 2021. This Internet-Draft will expire on September 8, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . 8
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_PFS . . . . . . . . . . . . . . . . . . . . . . . 12 6.2. AT_KDF_FS . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. New Key Derivation Functions . . . . . . . . . . . . . . 14 6.3. New Key Derivation Functions . . . . . . . . . . . . . . 14
6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 15 6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 15
6.5. Message Processing . . . . . . . . . . . . . . . . . . . 15 6.5. Message Processing . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . 17 6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 16
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 . . . . . . . . . 17
6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 18 6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 17
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
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
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 smart cards, such as attacking SIM card involved compromising smart cards, such as attacking SIM card
manufacturers and operators in an effort to compromise shared secrets manufacturers and operators in an effort to compromise shared secrets
skipping to change at page 3, line 40 skipping to change at page 3, line 40
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 is an optional extension to the EAP-AKA'
authentication method [I-D.ietf-emu-rfc5448bis]. While optional, the authentication method [RFC9048]. While optional, the use of this
use of this extension is RECOMMENDED. extension is RECOMMENDED.
The extension, when negotiated, provides Perfect Forward Secrecy for The extension, when negotiated, provides Forward Secrecy for the
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. but risks detection, particularly if done at scale. The attacker is
forced to attempt to exfiltrate key material, if it can, on a
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. Perfect forward secrecy is on the list of features for the contexts. Forward secrecy is on the list of features for the next
next release of 3GPP (5G Phase 2), and this document provides a basis release of 3GPP (5G Phase 2), and this document provides a basis for
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 includes the use
of the EAP framework for authentication. While any methods can be of the EAP framework for authentication. While any methods can be
run, the default authentication method within that context will be run, the default authentication method within that context will be
EAP-AKA'. As a result, improvements in EAP-AKA' security have a EAP-AKA'. As a result, improvements in EAP-AKA' security have a
potential to improve security for large number of users. 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 This extension specified here re-uses large portions of the current
skipping to change at page 4, line 43 skipping to change at page 4, line 45
widely supported EAP-AKA' method, rather than a completely new widely supported EAP-AKA' method, rather than a completely new
authentication method. The extension is implemented as a set of new, authentication method. The extension is implemented as a set of new,
optional attributes, that are provided alongside the base attributes optional attributes, that are provided alongside the base attributes
in EAP-AKA'. Old implementations can ignore these attributes, but in EAP-AKA'. Old implementations can ignore these attributes, but
their presence will nevertheless be verified as part of base EAP-AKA' their presence will nevertheless be verified as part of base EAP-AKA'
integrity verification process, helping protect against bidding down integrity verification process, helping protect against bidding down
attacks. This extension does not increase the number of rounds attacks. This extension does not increase the number of rounds
necessary to complete the protocol. 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 PFS and defenses against passive parties. It should be noted that FS and defenses against passive
attacks are by no means a panacea, but they can provide a partial attacks are by no means a panacea, 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 perfect forward secrecy to the existing mobile network While adding forward secrecy to the existing mobile network
infrastructure can be done in multiple different ways, the authors infrastructure can be done in multiple different ways, the authors
believe that the approach chosen here is relatively easily believe that the approach chosen here is relatively easily
deployable. In particular: deployable. In particular:
o As noted above, no new credentials are needed; there is no change o As noted above, no new credentials are needed; there is no change
to SIM cards. to SIM cards.
o PFS property can be incorporated into any current or future system o 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.
o Key generation happens at the endpoints, enabling highest grade o Key generation happens at the endpoints, enabling highest grade
key material to be used both by the endpoints and the intermediate key material to be used both by the endpoints and the intermediate
systems (such as access points that are given access to specific systems (such as access points that are given access to specific
keys). keys).
o While EAP-AKA' is just one EAP method, for practical purposes o While EAP-AKA' is just one EAP method, for practical purposes
perfect forward secrecy being available for both EAP-TLS [RFC5216] forward secrecy being available for both EAP-TLS [RFC5216]
[I-D.ietf-emu-eap-tls13] and EAP-AKA' ensures that for many [RFC9190] and EAP-AKA' ensures that for many practical systems
practical systems perfect forward secrecy can be enabled for forward secrecy can be enabled for either all or significant
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 AKA is based on challenge-response mechanisms and symmetric
cryptography. AKA typically runs in a UMTS Subscriber Identity cryptography. AKA typically runs in a UMTS Subscriber Identity
Module (USIM) or a CDMA2000 (Removable) User Identity Module Module (USIM) or a CDMA2000 (Removable) User Identity Module
((R)UIM). In contrast with its earlier GSM counterparts, AKA ((R)UIM). In contrast with its earlier GSM counterparts, AKA
provides long key lengths and mutual authentication. provides long key lengths and mutual authentication.
skipping to change at page 6, line 20 skipping to change at page 6, line 23
protect further communications between the identity module and the protect further communications between the identity module and the
home environment. home environment.
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 AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in [RFC9048] and
[I-D.ietf-emu-rfc5448bis] and [RFC4187]. [RFC4187].
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 | | | Server determines the network name and ensures |
skipping to change at page 8, line 10 skipping to change at page 8, line 10
| 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 [I-D.ietf-emu-rfc5448bis]. 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
[Heist2015]. These attacks are not specific to AKA or EAP-AKA', as [Heist2015]. These attacks are not specific to AKA or EAP-AKA', as
all security systems fail at least to some extent if key material is all security systems fail at least to some extent if key material is
stolen. However, the reports indicate a need to look into solutions stolen. However, the reports indicate a need to look into solutions
that can operate at least to an extent under these types of attacks. that can operate at least to an extent under these types of attacks.
It is noted in [Heist2015] that some security can be retained even in It is noted in [Heist2015] that some security can be retained even in
the face of the attacks by providing Perfect Forward Secrecy (PFS) the face of the attacks by providing Forward Secrecy (FS) [DOW1992]
[DOW1992] for the session key. If AKA would have provided PFS, for the session key. If AKA would have provided FS, compromising the
compromising the pre-shared key would not be sufficient to perform pre-shared key would not be sufficient to perform passive attacks;
passive attacks; the attacker is, in addition, forced to be a Man-In- the attacker is, in addition, forced to be a Man-In-The-Middle (MITM)
The-Middle (MITM) during the AKA run and subsequent communication during the AKA run and subsequent communication between the parties.
between the parties.
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 PFS for EAP-AKA' can be achieved by using an Elliptic Introducing FS for EAP-AKA' can be achieved by using an Elliptic
Curve Diffie-Hellman (ECDH) exchange [RFC7748]. In EAP-AKA' PFS this Curve Diffie-Hellman (ECDH) exchange [RFC7748]. In EAP-AKA' FS this
exchange is run in an ephemeral manner, i.e., both sides generate exchange is run in an ephemeral manner, i.e., both sides generate
temporary keys as specified in [RFC7748]. This method is referred to temporary keys as specified in [RFC7748]. This method is referred to
as ECDHE, where the last 'E' stands for Ephemeral. as ECDHE, where the last 'E' stands for Ephemeral.
The enhancements in the EAP-AKA' PFS 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.
skipping to change at page 9, line 47 skipping to change at page 9, line 47
| | | XRES, CK', | | | | XRES, CK', |
| | | IK' | | | | IK' |
| | |<------------| | | |<------------|
| | | | | | | |
| +-------------------------------------------------+ | +-------------------------------------------------+
| | Server now has the needed authentication vector.| | | Server now has the needed authentication vector.|
| | It generates an ephemeral key pair, sends the | | | It generates an ephemeral key pair, sends the |
| | public key of that key pair and the first EAP | | | public key of that key pair and the first EAP |
| | method message to the peer. In the message the | | | method message to the peer. In the message the |
| | AT_PUB_ECDHE attribute carries the public key | | | AT_PUB_ECDHE attribute carries the public key |
| | and the AT_KDF_PFS attribute carries other PFS- | | | and the AT_KDF_FS attribute carries other FS- |
| | related parameters. Both of these are skippable | | | related parameters. Both of these are skippable |
| | attributes that can be ignored if the peer does | | | attributes that can be ignored if the peer does |
| | not support this extension. | | | not support this extension. |
| +-------------------------------------------------+ | +-------------------------------------------------+
| | | | | | | |
| | EAP-Req/AKA'-Challenge | | | | EAP-Req/AKA'-Challenge | |
| | AT_RAND, AT_AUTN, AT_KDF,| | | | AT_RAND, AT_AUTN, AT_KDF,| |
| | AT_KDF_PFS, AT_KDF_INPUT,| | | | AT_KDF_FS, AT_KDF_INPUT, | |
| | AT_PUB_ECDHE, AT_MAC | | | | AT_PUB_ECDHE, AT_MAC | |
| |<-------------------------| | | |<-------------------------| |
+-----------------------------------------------------+ | +-----------------------------------------------------+ |
| The peer checks if it wants to do the PFS extension.| | | The peer checks if it wants to do the FS extension.| |
| If yes, it will eventually respond with AT_PUB_ECDHE| | | If yes, it will eventually respond with AT_PUB_ECDHE| |
| and AT_MAC. If not, it will ignore AT_PUB_ECDHE and | | | and AT_MAC. If not, it will ignore AT_PUB_ECDHE and | |
| AT_KDF_PFS and base all calculations on basic | | | AT_KDF_FS and base all calculations on basic | |
| EAP-AKA' attributes, continuing just as in EAP-AKA' | | | EAP-AKA' attributes, continuing just as in EAP-AKA' | |
| per RFC 5448 (draft-ietf-emu-rfc5448bis) rules. | | | per RFC 5448 (draft-ietf-emu-rfc5448bis) rules. | |
| In any case, the peer needs to query the auth | | | In any case, the peer needs to query the auth | |
| parameters from the USIM card. | | | parameters from the USIM card. | |
+-----------------------------------------------------+ | +-----------------------------------------------------+ |
| | | | | | | |
| RAND, AUTN | | | | RAND, AUTN | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
| CK, IK, RES | | | | CK, IK, RES | | |
|-------------->| | | |-------------->| | |
| | | | | | | |
+-----------------------------------------------------+ | +-----------------------------------------------------+ |
| The peer now has everything to respond. If it wants | | | The peer now has everything to respond. If it wants | |
| to participate in the PFS extension, it will then | | | to participate in the FS extension, it will then | |
| generate its key pair, calculate a shared key based | | | generate its key pair, calculate a shared key based | |
| on its key pair and the server's public key. | | | on its key pair and the server's public key. | |
| Finally, it proceeds to derive all EAP-AKA' key | | | Finally, it proceeds to derive all EAP-AKA' key | |
| values and and constructs a full response. | | | values and and constructs a full response. | |
+-----------------------------------------------------+ | +-----------------------------------------------------+ |
| | | | | | | |
| | EAP-Resp/AKA'-Challenge | | | | EAP-Resp/AKA'-Challenge | |
| | AT_RES, AT_PUB_ECDHE, | | | | AT_RES, AT_PUB_ECDHE, | |
| | AT_MAC | | | | AT_MAC | |
| |------------------------->| | | |------------------------->| |
skipping to change at page 11, line 9 skipping to change at page 11, line 9
| | CK/IK as well as the ECDHE value. Even if there | | | CK/IK as well as the ECDHE value. Even if there |
| | was an attacker who held the long-term secret | | | was an attacker who held the long-term secret |
| | keys, only an active attacker could have | | | keys, only an active attacker could have |
| | determined the generated session keys; in basic | | | determined the generated session keys; in basic |
| | EAP-AKA' the keys are only based on CK and IK. | | | EAP-AKA' the keys are only based on CK and IK. |
| +-------------------------------------------------+ | +-------------------------------------------------+
| | | | | | | |
| | EAP-Success | | | | EAP-Success | |
| |<-------------------------| | | |<-------------------------| |
Figure 2: EAP-AKA' PFS 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
skipping to change at page 12, line 5 skipping to change at page 12, line 5
* 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 in binary as specified [RFC7748] Section 6.1.
* 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 in
binary as specified in [FIPS186-4], using the compressed form binary as specified in [FIPS186-4], using the compressed form
from Section 2.7.1 of [SEC2]. 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_PFS 6.2. AT_KDF_FS
The AT_KDF_PFS indicates the used or desired key generation function, The AT_KDF_FS indicates the used or desired key generation function,
if the Perfect Forward Secrecy extension is taken into use. It will if the Forward Secrecy extension is taken into use. It will also at
also at the same time indicate the used or desired ECDHE group. A the same time indicate the used or desired ECDHE group. A new
new attribute is needed to carry this information, as AT_KDF carries attribute is needed to carry this information, as AT_KDF carries the
the legacy KDF value for those EAP peers that cannot or do not want legacy KDF value for those EAP peers that cannot or do not want to
to use this extension. use this extension.
The format of the AT_KDF_PFS 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_PFS | Length | Key Derivation Function | | AT_KDF_FS | Length | Key Derivation Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields are as follows: The fields are as follows:
AT_KDF_PFS 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 Key Derivation Function
An enumerated value representing the key derivation function that An enumerated value representing the key derivation function that
the server (or peer) wishes to use. See Section 6.3 for the the server (or peer) wishes to use. See Section 6.3 for the
functions specified in this document. Note: This field has a functions specified in this document. Note: This field has a
different name space than the similar field in the AT_KDF different name space than the similar field in the AT_KDF
attribute Key Derivation Function defined in attribute Key Derivation Function defined in [RFC9048].
[I-D.ietf-emu-rfc5448bis].
Servers MUST send one or more AT_KDF_PFS 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_PFS 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 key derivation
function indicated by the first AT_KDF_PFS 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 [I-D.ietf-emu-rfc5448bis] for AT_KDF, the peer sends defined in [RFC9048] for AT_KDF, the peer sends EAP-Response/AKA'-
EAP-Response/AKA'-Challenge message that contains only one Challenge message that contains only one attribute, AT_KDF_FS with
attribute, AT_KDF_PFS with the value set to the desired the value set to the desired alternative function from among the
alternative function from among the ones suggested by the server ones suggested by the server earlier. If there is no suitable
earlier. If there is no suitable alternative, the peer has a alternative, the peer has a choice of either falling back to EAP-
choice of either falling back to EAP-AKA' or behaving as if AUTN AKA' or behaving as if AUTN had been incorrect and failing
had been incorrect and failing authentication (see Figure 3 of authentication (see Figure 3 of [RFC4187]). The peer MUST fail
[RFC4187]). The peer MUST fail the authentication if there are the authentication if there are any duplicate values within the
any duplicate values within the list of AT_KDF_PFS attributes list of AT_KDF_FS attributes (except where the duplication is due
(except where the duplication is due to a request to change the to a request to change the key derivation function; see below for
key derivation function; see below for further information). further information).
o If the peer does not recognize the extension defined in this o If the peer does not recognize the extension defined in this
specification or is unwilling to use it, it ignores the AT_KDF_PFS specification or is unwilling to use it, it ignores the AT_KDF_FS
attribute. attribute.
Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF_PFS from Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF_FS from the
the peer, the server checks that the suggested AT_KDF_PFS value was peer, the server checks that the suggested AT_KDF_FS value was one of
one of the alternatives in its offer. The first AT_KDF_PFS value in the alternatives in its offer. The first AT_KDF_FS value in the
the message from the server is not a valid alternative. If the peer message from the server is not a valid alternative. If the peer has
has replied with the first AT_KDF_PFS 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_PFS 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 key derivation function is the only legal situation where
such duplication may occur. 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_PFS 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_PFS attributes without Challenge messages with differing AT_KDF_FS attributes without having
having requested negotiation, the peer MUST behave as if AT_MAC had requested negotiation, the peer MUST behave as if AT_MAC had been
been incorrect and fail the authentication. incorrect and fail the authentication.
6.3. New Key Derivation Functions 6.3. New Key Derivation Functions
Two new Key Derivation Function types are defined for "EAP-AKA' with Two new Key Derivation Function types are defined for "EAP-AKA' with
ECDHE and X25519", represented by value 1, and "EAP-AKA' with ECDHE ECDHE and X25519", represented by value 1, and "EAP-AKA' with ECDHE
and P-256", represented by value 2. These represent a particular and P-256", represented by value 2. These represent a particular
choice of key derivation function and at the same time selects an choice of key derivation function and at the same time selects an
ECDHE group to be used. ECDHE group to be used.
The Key Derivation Function type value is only used in the AT_KDF_PFS The Key Derivation Function type value is only used in the AT_KDF_FS
attribute, and should not be confused with the different range of key attribute, and should not be confused with the different range of key
derivation functions that can be represented in the AT_KDF attribute derivation functions that can be represented in the AT_KDF attribute
as defined in [I-D.ietf-emu-rfc5448bis]. as defined in [RFC9048].
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 internal use within one authentication run as [RFC9048] EAP-AKA'
[I-D.ietf-emu-rfc5448bis] EAP-AKA' does. For instance, K_aut that is does. For instance, K_aut that is used in AT_MAC is still exactly as
used in AT_MAC is still exactly as it was in EAP-AKA'. The only it was in EAP-AKA'. The only change to key derivation is in re-
change to key derivation is in re-authentication keys and keys authentication keys and keys exported out of the EAP method, MSK and
exported out of the EAP method, MSK and EMSK. As a result, EAP-AKA' EMSK. As a result, EAP-AKA' attributes such as AT_MAC continue to be
attributes such as AT_MAC continue to be usable even when this usable even when this extension is in use.
extension is in use.
When the Key Derivation Function field in the AT_KDF_PFS attribute is When the Key Derivation Function field in the AT_KDF_FS attribute is
set to 1 and the Key Derivation Function field in the AT_KDF set to 1 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 also 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' PFS"|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 Where SHARED_SECRET is the shared secret computed via ECDHE, as
specified in Section 6.1 of [RFC7748]. specified in Section 6.1 of [RFC7748].
Both the peer and the server MAY check for zero-value shared secret Both the peer and the server MAY check for zero-value shared secret
skipping to change at page 15, line 12 skipping to change at page 15, line 6
behave as if the current EAP-AKA' authentication process starts again behave as if the current EAP-AKA' authentication process starts again
from the beginning. from the beginning.
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.
The rest of computation proceeds as defined in Section 3.3 of The rest of computation proceeds as defined in Section 3.3 of
[I-D.ietf-emu-rfc5448bis]. [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 [I-D.ietf-emu-rfc5448bis]. pseudo-random function specified in [RFC9048]. K_encr is the
K_encr is the encryption key, 128 bits, K_aut is the authentication encryption key, 128 bits, K_aut is the authentication key, 256 bits,
key, 256 bits, K_re is the re-authentication key, 256 bits, MSK is K_re is the re-authentication key, 256 bits, MSK is the Master
the Master Session Key, 512 bits, and EMSK is the Extended Master Session Key, 512 bits, and EMSK is the Extended Master Session Key,
Session Key, 512 bits. MSK and EMSK are outputs from a successful 512 bits. MSK and EMSK are outputs from a successful EAP method run
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 [I-D.ietf-emu-rfc5448bis] 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' PFS" is a twelve-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].
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_PFS. 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 [FIPS186-4]. The support for
this group is OPTIONAL. this group is OPTIONAL.
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 [I-D.ietf-emu-rfc5448bis] or otherwise specified here, the rules from [RFC9048] or [RFC4187]
[RFC4187] apply. apply.
6.5.1. EAP-Request/AKA'-Identity 6.5.1. EAP-Request/AKA'-Identity
No changes, except that the AT_KDF_PFS or AT_PUB_ECDHE attributes No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST
MUST NOT be added to this message. The appearance of these messages NOT be added to this message. The appearance of these messages in a
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_PFS or AT_PUB_ECDHE attributes No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST
MUST NOT be added to this message. The appearance of these messages NOT be added to this message. The appearance of these messages in a
in a received message MUST be ignored. 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 authentication as specified by [RFC4187] and [RFC9048]. The
[I-D.ietf-emu-rfc5448bis]. The attributes AT_RAND, AT_AUTN, and attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked
AT_MAC MUST be included and checked on reception as specified in on reception as specified in [RFC4187]. They are also necessary for
[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
covered by the MAC for the AT_MAC attribute. The AT_KDF_PFS 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_PFS 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 them as or AT_PUB_ECDHE is missing on reception, the peer MUST treat them as
if neither one was sent, and the assume that the extension defined in if neither one was sent, and the assume that the extension defined in
this specification is not in use. this specification 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_PFS, AT_PUB_ECDHE before processing other attributes. Only if AT_KDF_FS, AT_PUB_ECDHE before processing other attributes. Only if
these attributes are verified to be valid, the peer derives keys and these attributes are verified to be valid, the peer derives keys and
verifies AT_MAC. If the peer is unable or unwilling to perform the verifies AT_MAC. If the peer is unable or unwilling to perform the
extension specified in this document, it proceeds as defined in extension specified in this document, it proceeds as defined in
[I-D.ietf-emu-rfc5448bis]. Finally, the operation in case an error [RFC9048]. Finally, the operation in case an error occurs is
occurs is specified in Section 6.3.1. of [RFC4187]. specified in Section 6.3.1. of [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 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
[I-D.ietf-emu-rfc5448bis]. If the peer supports and is willing to [RFC9048]. If the peer supports and is willing to perform the
perform the extension specified in this protocol, and the server had extension specified in this protocol, and the server had made a valid
made a valid request involving the attributes specified in request involving the attributes specified in Section 6.5.3, the peer
Section 6.5.3, the peer responds per the rules specified below. responds per the rules specified below. Otherwise, the peer responds
Otherwise, the peer responds as specified in [RFC4187] and as specified in [RFC4187] and [RFC9048] and ignores the attributes
[I-D.ietf-emu-rfc5448bis] and ignores the attributes related to this related to this extension. If the peer has not received attributes
extension. If the peer has not received attributes related to this related to this extension from the Server, and has a policy that
extension from the Server, and has a policy that requires it to requires it to always use this extension, it behaves as if AUTN had
always use this extension, it behaves as if AUTN had been incorrect been incorrect and fails the authentication.
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
[I-D.ietf-emu-rfc5448bis]. In EAP-Response/AKA'-Challenge, there is [RFC9048]. In EAP-Response/AKA'-Challenge, there is no message-
no message-specific data covered by the MAC. The AT_PUB_ECDHE specific data covered by the MAC. The AT_PUB_ECDHE attribute MUST be
attribute MUST be included, and carries the peer's public Diffie- included, and carries the peer's public Diffie-Hellman key.
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. Only if these attribute AT_RES before processing other attributes. Only if these attribute
is verified to be valid, the Server derives keys and verifies AT_MAC. is verified to be valid, the Server derives keys and verifies AT_MAC.
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 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'
skipping to change at page 18, line 7 skipping to change at page 17, line 45
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
No changes, except that the AT_KDF_PFS or AT_PUB_ECDHE attributes No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST
MUST NOT be added to this message. The appearance of these messages NOT be added to this message. The appearance of these messages in a
in a received message MUST be ignored. received message MUST be ignored.
6.5.8. EAP-Response/AKA'-Authentication-Reject 6.5.8. EAP-Response/AKA'-Authentication-Reject
No changes, except that the AT_KDF_PFS or AT_PUB_ECDHE attributes No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST
MUST NOT be added to this message. The appearance of these messages NOT be added to this message. The appearance of these messages in a
in a received message MUST be ignored. received message MUST be ignored.
6.5.9. EAP-Response/AKA'-Client-Error 6.5.9. EAP-Response/AKA'-Client-Error
No changes, except that the AT_KDF_PFS or AT_PUB_ECDHE attributes No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST
MUST NOT be added to this message. The appearance of these messages NOT be added to this message. The appearance of these messages in a
in a received message MUST be ignored. received message MUST be ignored.
6.5.10. EAP-Request/AKA'-Notification 6.5.10. EAP-Request/AKA'-Notification
No changes. No changes.
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 [I-D.ietf-emu-rfc5448bis]. since the publication of [RFC9048].
The possibility of attacks against key storage offered in SIM or The possibility of attacks against key storage offered in SIM or
other smart cards has been a known threat. But as the discussion in other smart cards has been a known threat. But as the discussion in
Section 3.3 shows, the likelihood of practically feasible attacks has Section 3.3 shows, the likelihood of practically feasible attacks has
increased. Many of these attacks can be best dealt with improved increased. Many of these attacks can be best dealt with improved
processes, e.g., limiting the access to the key material within the processes, e.g., limiting the access to the key material within the
factory or personnel, etc. But not all attacks can be entirely ruled factory or personnel, etc. But not all attacks can be entirely ruled
out for well-resourced adversaries, irrespective of what the out for well-resourced adversaries, irrespective of what the
technical algorithms and protection measures are. technical algorithms and protection measures are.
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 can not or who are unwilling to mount active attacks adversaries that can not or who are unwilling to mount active attacks
against large number of sessions. This extension is most useful when against large number of sessions. This extension is most useful when
used in a context where EAP keys are used without further mixing that used in a context where EAP keys are used without further mixing that
can provide Perfect Forward Secrecy. For instance, when used with can provide Forward Secrecy. For instance, when used with IKEv2
IKEv2 [RFC7296], the session keys produced by IKEv2 have this [RFC7296], the session keys produced by IKEv2 have this property, so
property, so better characteristics of EAP keys is not that useful. better characteristics of EAP keys 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 Diffie-
Diffie-Hellman, so using EAP to authenticate access to a network is Hellman, so using EAP to authenticate access to a network is one
one situation where the extension defined in this document can be situation where the extension defined in this document can be
helpful. helpful.
This extension generates keying material using the ECDHE exchange in This extension generates keying material using the ECDHE exchange in
order to gain the PFS property. This means that once an EAP-AKA' 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 forgotten, even someone who closed, and the corresponding keys are forgotten, 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, PFS 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. Of course, as with other protocols, if become an active attacker. Of course, as with other protocols, if
the attacker has learned the keys and does become an active attacker, the attacker has learned the keys and does become an active attacker,
there is no protection that that can be provided for future sessions. there is no protection that that can be provided for future sessions.
Among other things, such an active attacker can impersonate any Among other things, such an active attacker can impersonate any
legitimate endpoint in EAP-AKA', become a MITM in EAP-AKA' or the legitimate endpoint in EAP-AKA', become a MITM in EAP-AKA' or the
extension defined in this document, retrieve all keys, or turn off extension defined in this document, retrieve all keys, or turn off
PFS. Still, past sessions where PFS was in use remain protected. FS. Still, past sessions where FS was in use remain protected.
Achieving PFS requires that when a connection is closed, each Achieving FS requires that when a connection is closed, each endpoint
endpoint MUST forget not only the ephemeral keys used by the MUST forget not only the ephemeral keys used by the connection but
connection but also any information that could be used to recompute also any information that could be used to recompute those keys.
those keys.
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 20, line 10 skipping to change at page 20, line 4
The negotiation mechanism allows changing the offered key The negotiation mechanism allows changing the offered key
derivation function, but the change is visible in the final derivation function, but the change is visible in the final
EAP- Request/AKA'-Challenge message that the server sends to EAP- Request/AKA'-Challenge message that the server sends to
the peer. This message is authenticated via the AT_MAC the peer. This message is authenticated via the AT_MAC
attribute, and carries both the chosen alternative and the attribute, and carries both the chosen alternative and the
initially offered list. The peer refuses to accept a change it initially offered list. The peer refuses to accept a change it
did not initiate. As a result, both parties are aware that a did not initiate. As a result, both parties are aware that a
change is being made and what the original offer was. change is being made and what the 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_PFS 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 shared Except of course, if the adversary holds the long-term shared
secret and is willing to engage in an active attack. Such an secret and is willing to engage in an active attack. Such an
attack can, for instance, forge the negotiation process so that attack can, for instance, forge the negotiation process so that
no PFS will be provided. However, as noted above, an attacker no FS will be provided. However, as noted above, an attacker
with these capabilities will in any case be able to impersonate with these capabilities will in any case be able to impersonate
any party in the protocol and perform MITM attacks. That is any party in the protocol and perform MITM attacks. That is
not a situation that can be improved by a technical solution. not 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 a MITM on with access to the long-term keys is required to be a MITM on
each AKA run and subsequent communication, which makes mass each AKA run and subsequent communication, which makes mass
surveillance more laborous. surveillance more laborous.
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 peform the extension specified in this protocol, but willing to peform the extension specified in this protocol, but
the other side does not wish to use the extension. Allowing the other side does not wish to use the extension. Allowing
this has the benefit of allowing backwards compatibility to this has the benefit of allowing backwards compatibility to
equipment that did not yet support the extension. When the equipment that did not yet support the extension. When the
extension is not supported or negotiated by the parties, no PFS extension is not supported or negotiated by the parties, no FS
can obviously provided. can obviously 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
skipping to change at page 21, line 35 skipping to change at page 21, line 28
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.
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' PFS. 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
EAP-AKA' is an additional concern, it does not change the overall EAP-AKA' is an additional concern, it does not change the overall
situation. As a result, the relevant system components need to be situation. As a result, the relevant system components need to be
dimensioned appropriately, and detection and management mechanisms dimensioned appropriately, and detection and management mechanisms
to reduce the effect of attacks need to be in place. to reduce the effect of attacks need to be in place.
o This specification is constructed so that a separation between the o This specification is constructed so that a separation between the
USIM and Peer on client side and the Server and HSS on network USIM and Peer on client side and the Server and HSS on network
skipping to change at page 22, line 16 skipping to change at page 22, line 9
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.
o Finally, this memo specifies an order in which computations and o Finally, this memo specifies an order in which computations and
checks must occur. When processing the EAP-Request/AKA'-Challenge checks must occur. When processing the EAP-Request/AKA'-Challenge
message, for instance, the AKA authentication must be checked and message, for instance, 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
PFS 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
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 PFS calculations become in some way, and only then will the FS calculations become active.
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.
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' with EAP-SIM [RFC4186], EAP-AKA [RFC4186], and EAP-AKA' [RFC9048].
[I-D.ietf-emu-rfc5448bis].
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_PFS 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 Diffie-Hellman
Key Derivation Function types. The "EAP-AKA' with ECDHE and X25519" 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) 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 need to be assigned, along with one reserved value. The initial
contents of this namespace are therefore as below; new values can be contents of this namespace are therefore as below; new values can be
created through the Specification Required policy [RFC8126]. created through the Specification Required policy [RFC8126].
skipping to change at page 23, line 24 skipping to change at page 23, line 15
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>. <https://www.rfc-editor.org/info/rfc3748>.
[RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication
Protocol Method for 3rd Generation Authentication and Key Protocol Method for 3rd Generation Authentication and Key
Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187, Agreement (EAP-AKA)", RFC 4187, DOI 10.17487/RFC4187,
January 2006, <https://www.rfc-editor.org/info/rfc4187>. January 2006, <https://www.rfc-editor.org/info/rfc4187>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015, <https://www.rfc-
editor.org/info/rfc7624>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January for Security", RFC 7748, DOI 10.17487/RFC7748, January
2016, <https://www.rfc-editor.org/info/rfc7748>. 2016, <https://www.rfc-editor.org/info/rfc7748>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
[I-D.ietf-emu-rfc5448bis] [RFC9048] Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
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')", draft-ietf-emu-rfc5448bis-07 (work in progress), AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021,
March 2020. <https://www.rfc-editor.org/info/rfc9048>.
[FIPS186-4] [FIPS186-4]
NIST, , "Digital Signature Standard (DSS)", July 2013. NIST, , "Digital Signature Standard (DSS)", July 2013.
[SEC2] Certicom Research, , "SEC 2: Recommended Elliptic Curve [SEC2] Certicom Research, , "SEC 2: Recommended Elliptic Curve
Domain Parameters", September 2000. Domain Parameters", September 2000.
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
skipping to change at page 24, line 32 skipping to change at page 24, line 30
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
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>.
[I-D.ietf-emu-eap-tls13] [RFC9190] Preu&#258;&#159; Mattsson, J. and M. Sethi, "EAP-TLS 1.3:
Mattsson, J. and M. Sethi, "Using EAP-TLS with TLS 1.3", Using the Extensible Authentication Protocol with TLS
draft-ietf-emu-eap-tls13-11 (work in progress), October 1.3", RFC 9190, DOI 10.17487/RFC9190, February 2022,
2020. <https://www.rfc-editor.org/info/rfc9190>.
[TrustCom2015] [TrustCom2015]
Arkko, J., Norrman, K., Naslund, M., and B. Sahlin, "A Arkko, J., Norrman, K., Naslund, 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", August 2015 in Proceedings of the TrustCom 2015,
IEEE. IEEE.
[Heist2015] [Heist2015]
Scahill, J. and J. Begley, "The great SIM heist", February Scahill, J. and J. Begley, "The great SIM heist", February
2015, in https://firstlook.org/theintercept/2015/02/19/ 2015, in https://firstlook.org/theintercept/2015/02/19/
great-sim-heist/ . great-sim-heist/ .
[DOW1992] Diffie, W., vanOorschot, P., and M. Wiener, [DOW1992] Diffie, W., vanOorschot, P., and M. Wiener,
"Authentication and Authenticated Key Exchanges", June "Authentication and Authenticated Key Exchanges", June
1992, in Designs, Codes and Cryptography 2 (2): pp. 1992, in Designs, Codes and Cryptography 2 (2): pp.
107-125. 107-125.
Appendix A. Change Log Appendix A. Change Log
The -06 version of the WG draft is a refresh and a reference update.
However, the following should be noted:
o The draft now uses "forward secrecy" terminology and references
RFC 7624 per recommendations on mailing list discussion.
o There's been mailing list disccussion 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 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 working group list, about the number of bytes needed to encode P-256
values. values.
The -04 version of the WG draft takes into account feedback from the The -04 version of the WG draft takes into account feedback from the
May 2020 WG interim meeting, correcting the reference to the NIST May 2020 WG interim meeting, correcting the reference to the NIST
P-256 specification. P-256 specification.
The -03 version of the WG draft is first of all a refresh; there are 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 no issues that we think need addressing, beyond the one for which
there is a suggestion in -03: The specification now suggests an there is a suggestion in -03: The specification now suggests an
alternate group/curve as an optional one besides X25519. The alternate group/curve as an optional one besides X25519. The
specific choice of particular groups and algorithms is still up to specific choice of particular groups and algorithms is still up to
the working group. the working group.
The -02 version of the WG draft took into account additional reviews, The -02 version of the WG draft took into account additional reviews,
and changed the document to update RFC 5448 (or rather, its and changed the document to update RFC 5448 (or rather, its
successor, [I-D.ietf-emu-rfc5448bis]), changed the wording of the successor, [RFC9048]), changed the wording of the recommendation with
recommendation with regards to the use of this extension, clarified regards to the use of this extension, clarified the references to the
the references to the definition of X25519 and Curve25519, clarified definition of X25519 and Curve25519, clarified the distinction to
the distinction to ECDH methods that use partially static keys, and ECDH methods that use partially static keys, and simplified the use
simplified the use of AKA and SIM card terminology. Some editorial of AKA and SIM card terminology. Some editorial changes were also
changes were also made. made.
The -00 and -01 versions of the WG draft made no major changes, only The -00 and -01 versions of the WG draft made no major changes, only
updates to some references. updates to some references.
The -05 version is merely a refresh while the draft was waiting for The -05 version is merely a refresh while the draft was waiting for
WG adoption. WG adoption.
The -04 version of this draft made only editorial changes. The -04 version of this draft made only editorial changes.
The -03 version of this draft changed the naming of various protocol The -03 version of this draft changed the naming of various protocol
components, values, and notation to match with the use of ECDH in components, values, and notation to match with the use of ECDH in
ephemeral mode. The AT_KDF_PFS 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 PFS 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 Appendix B. 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. Naslund, and B. Sahlin. This
 End of changes. 89 change blocks. 
192 lines changed or deleted 202 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/