draft-ietf-emu-aka-pfs-10.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: 5448, 9048 (if approved) V. Torvinen Updates: 5448, 9048 (if approved) J. Preuß Mattsson
Intended status: Informational J. Preuß Mattsson Intended status: Informational Ericsson
Expires: 30 July 2023 Ericsson Expires: 11 January 2024 10 July 2023
26 January 2023
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-10 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 Universal Subscriber Identity Module (USIM) card manufacturers and
shared secrets stored on these cards. Since the publication of those operators in an effort to compromise long-term keys stored on these
reports, manufacturing and provisioning processes have gained much cards. Since the publication of those reports, manufacturing and
scrutiny and have improved. However, the danger of resourceful provisioning processes have received much scrutiny and have improved.
attackers for these systems is still a concern. Always assuming However, resourceful attackers are always a cause for concern.
breach such as key compromise and minimizing the impact of breach are Always assuming a breach, such as long-term key compromise, and
essential zero-trust principles. minimizing the impact of breach are essential zero trust principles.
This specification updates RFC 9048, the improved Extensible This document updates RFC 9048, the improved Extensible
Authentication Protocol Method for 3GPP Mobile Network Authentication Authentication Protocol Method for 3GPP Mobile Network Authentication
and Key Agreement (EAP-AKA'), with an optional extension. Similarly, and Key Agreement (EAP-AKA'), with an optional extension providing
this specification also updates the earlier version of the EAP-AKA' ephemeral key exchange. Similarly, this document also updates the
specification in RFC 5448. The extension, when negotiated, provides earlier version of the EAP-AKA' specification in RFC 5448. The
Forward Secrecy for the session key generated as a part of the extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated,
authentication run in EAP-AKA'. This prevents an attacker who has provides forward secrecy for the session keys generated as a part of
gained access to the long-term pre-shared secret in a Subscriber the authentication run in EAP-AKA'. This prevents an attacker who
Identity Module (SIM) card from being able to decrypt any past has gained access to the long-term key from obtaining session keys
communications. In addition, if the attacker stays merely a passive established in the past, assuming these have been properly deleted.
eavesdropper, the extension prevents attacks against future sessions. In addition, EAP-AKA' FS mitigates passive attacks (e.g., large scale
This forces attackers to use active attacks instead. pervasive monitoring) 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 30 July 2023. This Internet-Draft will expire on 11 January 2024.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Design and Deployment Objectives . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Design and Deployment Objectives . . . . . . . . . . 5
3.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 7 4.1. AKA . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Attacks Against Long-Term Shared Secrets in Smart 4.2. EAP-AKA' Protocol . . . . . . . . . . . . . . . . . . . . 7
Cards . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Attacks Against Long-Term Keys in Smart Cards . . . . . . 8
4. Requirements Language . . . . . . . . . . . . . . . . . . . . 8
5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . 12
6.3. Forward Secrecy Key Derivation Functions . . . . . . . . 14 6.3. Forward Secrecy Key Derivation Functions . . . . . . . . 14
6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 16 6.4. ECDHE Groups . . . . . . . . . . . . . . . . . . . . . . 16
6.5. Message Processing . . . . . . . . . . . . . . . . . . . 16 6.5. Message Processing . . . . . . . . . . . . . . . . . . . 16
6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 16 6.5.1. EAP-Request/AKA'-Identity . . . . . . . . . . . . . . 17
6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 16 6.5.2. EAP-Response/AKA'-Identity . . . . . . . . . . . . . 17
6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 17 6.5.3. EAP-Request/AKA'-Challenge . . . . . . . . . . . . . 17
6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 17 6.5.4. EAP-Response/AKA'-Challenge . . . . . . . . . . . . . 18
6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 18 6.5.5. EAP-Request/AKA'-Reauthentication . . . . . . . . . . 18
6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 18 6.5.6. EAP-Response/AKA'-Reauthentication . . . . . . . . . 18
6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 18 6.5.7. EAP-Response/AKA'-Synchronization-Failure . . . . . . 19
6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 18 6.5.8. EAP-Response/AKA'-Authentication-Reject . . . . . . . 19
6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 18 6.5.9. EAP-Response/AKA'-Client-Error . . . . . . . . . . . 19
6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 19 6.5.10. EAP-Request/AKA'-Notification . . . . . . . . . . . . 19
6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 19 6.5.11. EAP-Response/AKA'-Notification . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Security Properties . . . . . . . . . . . . . . . . . . . 21 7.1. Deployment Considerations . . . . . . . . . . . . . . . . 21
7.2. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 23 7.2. Security Properties . . . . . . . . . . . . . . . . . . . 21
7.3. Identity Privacy . . . . . . . . . . . . . . . . . . . . 24 7.3. Denial-of-Service . . . . . . . . . . . . . . . . . . . . 23
7.4. Unprotected Data and Privacy . . . . . . . . . . . . . . 24 7.4. Identity Privacy . . . . . . . . . . . . . . . . . . . . 24
7.5. Post-Quantum Considerations . . . . . . . . . . . . . . . 24 7.5. Unprotected Data and Privacy . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 7.6. Forward Secrecy within AT_ENCR . . . . . . . . . . . . . 24
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.7. Post-Quantum Considerations . . . . . . . . . . . . . . . 25
9.1. Normative References . . . . . . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28 9.1. Normative References . . . . . . . . . . . . . . . . . . 27
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Many different attacks have been reported as part of revelations Many different attacks have been reported as part of 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 Universal Subscriber Identity Module (USIM)
SIM card manufacturers and operators in an effort to compromise card supply chain. Attacks revealing the AKA long-term key may occur
shared secrets stored on these cards. Such attacks are conceivable, for instance, during the manufacturing process of USIM cards, during
for instance, during the manufacturing process of cards, or during the transfer of the cards and associated information to the operator,
the transfer of cards and associated information to the operator. and when a system is running. Since the publication of reports about
Since the publication of reports about such attacks, manufacturing such attacks [Heist2015], manufacturing and provisioning processes
and provisioning processes have gained much scrutiny and have have gained much scrutiny and have improved.
improved.
However, the danger of resourceful attackers attempting to gain However, the danger of resourceful attackers attempting to gain
information about Subscriber Identity Module (SIM) cards is still a information about long-term keys is still a concern because many
concern. They are a high-value target and concern a large number of people use the service and these keys are high-value targets. Note
people. Note that the attacks are largely independent of the used that the attacks are largely independent of the used authentication
authentication technology; the issue is not vulnerabilities in technology; the issue is not vulnerabilities in algorithms or
algorithms or protocols, but rather the possibility of someone protocols, but rather the possibility of someone gaining unauthorized
gaining unlawful access to key material. While the better protection access to key material. Furthermore, an explicit goal of the IETF is
of manufacturing and other processes is essential in protecting to ensure that we understand the surveillance concerns related to
against this, there is one question that we as protocol designers can IETF protocols and take appropriate countermeasures [RFC7258].
ask. Is there something that we can do to limit the consequences of
attacks, should they occur?
The authors want to provide a public specification of an extension While strong protection of manufacturing and other processes is
that helps defend against one aspect of pervasive surveillance. This essential in mitigating the risks, there is one question that we as
is important, given the large number of users such practices may protocol designers can ask. Is there something that we can do to
affect. It is also a stated goal of the IETF to ensure that we limit the consequences of attacks, should they occur?
understand the surveillance concerns related to IETF protocols and
take appropriate countermeasures [RFC7258]. This document does that
for the improved Extensible Authentication Protocol Method for 3GPP
Mobile Network Authentication and Key Agreement (EAP-AKA').
This specification updates [RFC9048], the EAP-AKA' authentication This document specifies an extension that helps defend against one
method, with an optional extension and strengthens the identity aspect of pervasive surveillance. This is important, given the large
privacy requirements. While optional, the use of this extension is number of users such practices may affect. It is also a stated goal
strongly RECOMMENDED. of the IETF to ensure that we understand the surveillance concerns
related to IETF protocols and take appropriate countermeasures
[RFC7258]. This document does that for the improved Extensible
Authentication Protocol Method for 3GPP Mobile Network Authentication
and Key Agreement (EAP-AKA').
This document updates [RFC9048], the 3GPP Mobile Network
Authentication and Key Agreement (EAP-AKA') method, with an optional
extension providing ephemeral key exchange minimizing the impact of
long-term key compromise and strengthens the identity privacy
requirements. While optional, the use of this extension is strongly
recommended.
The extension, when negotiated, provides Forward Secrecy (FS) 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 key in a USIM card from getting access to past session keys. In
past communications. In addition, if the attacker stays merely a addition to FS, the included Diffie-Hellman exchange, forces
passive eavesdropper, the extension prevents attacks against future attackers to be active if they want access to future session keys
sessions. This forces attackers to use active attacks instead. This even if they have access to the long-term key. This is beneficial,
is beneficial, because active attacks demand much more resources to because active attacks demand much more resources to launch, and are
launch, and can generally be detected much easier. As with other easier to detect. As with other protocols, an active attacker with
protocols, an active attacker with access to the long-term key access to the long-term key material will of course be able to attack
material will of course be able to attack all future communications, all future communications, but risks detection, particularly if done
but risks detection, particularly if done at scale. The attacker is at scale.
forced to attempt to exfiltrate key material, if it can, on a
continuous basis, as opposed to learning it once [RFC7624].
Attacks against Authentication and Key Agreement (AKA) authentication Attacks against Authentication and Key Agreement (AKA) authentication
via compromising the long-term secrets in the SIM cards have been an via compromising the long-term keys have been an active discussion
active discussion topic in many contexts. Forward secrecy is on the topic in many contexts. Forward secrecy [DOW1992] is on the list of
list of features for the next release of 3GPP (5G Phase 2), and this features for the next release of 3GPP (5G Phase 2), and this document
document provides a basis for providing this feature in a particular provides a basis for providing this feature.
fashion.
It should also be noted that 5G network architecture [TS.33.501] It should also be noted that 5G network architecture [TS.33.501]
includes the use of the EAP framework for authentication. While any includes the use of the EAP framework for authentication. While any
methods can be run, the default authentication method within that methods can be run, the default authentication method within that
context will be EAP-AKA'. As a result, improvements in EAP-AKA' context will be EAP-AKA'. As a result, improvements in EAP-AKA'
security have a potential to improve security for large number of security have a potential to improve security for many users.
users.
2. Protocol Design and Deployment Objectives 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Protocol Design and Deployment Objectives
The 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 keeps the interface between the USIM and the mobile
Subscriber Identification Module (USIM) and the mobile terminal 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
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 FS 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 do not solve all problems, but they can provide a partial
defense that increases the cost and risk associated with pervasive defense that increases the cost and risk associated with pervasive
surveillance. surveillance.
While adding forward secrecy to the existing mobile network While adding 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, this document
believe that the approach chosen here is relatively easily specifies a solution that is relatively easily deployable. In
deployable. In particular: particular:
* As noted above, no new credentials are needed; there is no change * As noted above, no new credentials are needed; there is no change
to SIM cards. to USIM cards.
* FS property can be incorporated into any current or future system * FS property can be incorporated into any current or future system
that supports EAP, without changing any network functions beyond that supports EAP, without changing any network functions beyond
the EAP endpoints. the EAP endpoints.
* Key generation happens at the endpoints, enabling highest grade * Key generation happens at the endpoints, enabling 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).
* While EAP-AKA' is just one EAP method, for practical purposes * 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 4. Background
3.1. AKA
Authentication and Key Agreement (AKA) is based on challenge-response The reader is assumed to have basic understanding of the EAP
mechanisms and symmetric cryptography. In contrast with its earlier framework [RFC3748].
GSM counterparts, AKA provides long key lengths and mutual
authentication. AKA typically runs in a Universal Subscriber 4.1. AKA
Identity Module (USIM). USIM is technically just an application that
can reside on a removable UICC, an embedded UICC, or integrated in a We use the term Authentication and Key Agreement (AKA) for the main
Trusted Execution Environment (TEE). In this document we use the authentication and key agreement protocol used by 3GPP mobile
term "SIM card" to refer to any Subscriber Identity Module capable of networks from the third generation (3G) and onward. Later
running AKA. generations adds new features to AKA, but the core remains the same.
It is based on challenge-response mechanisms and symmetric
cryptography. In contrast to its earlier GSM counterparts, AKA
provides long key lengths and mutual authentication. The phone
typically executes AKA in a 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 "USIM card" to refer to any Subscriber
Identity Module capable of running AKA.
The goal of AKA is to mutually authenticate the USIM and the so-
called home environment, which is the authentication server in the
subscribers home operator's network.
AKA works in the following manner: AKA works in the following manner:
* The identity module and the home environment have agreed on a * The USIM and the home environment have agreed on a long-term
secret key beforehand. symmetric key beforehand.
* The actual authentication process starts by having the home * 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 long-
key and a sequence number. The authentication vector contains a term key and a sequence number. The authentication vector
random part RAND, an authenticator part AUTN used for contains a random part RAND, an authenticator part AUTN used for
authenticating the network to the identity module, an expected authenticating the network to the USIM, an expected result part
result part XRES, a 128-bit session key for integrity check IK, XRES, a 128-bit session key for integrity check IK, and a 128-bit
and a 128-bit session key for encryption CK. session key for encryption CK.
* The authentication vector is passed to the serving network, which * The authentication vector is passed to the serving network, which
uses it to authenticate the device. uses it to authenticate the device.
* The RAND and the AUTN are delivered to the identity module. * The RAND and the AUTN are delivered to the USIM.
* The identity module verifies the AUTN, again based on the secret * The USIM verifies the AUTN, again based on the long-term key and
key and the sequence number. If this process is successful (the the sequence number. If this process is successful (the AUTN is
AUTN is valid and the sequence number used to generate AUTN is valid and the sequence number used to generate AUTN is within the
within the correct range), the identity module produces an correct range), the USIM produces an authentication result RES and
authentication result RES and sends it to the serving network. sends it to the serving network.
* The serving network verifies the correct result from the identity * The serving network verifies that the result from the USIM matches
module. If the result is correct, IK and CK can be used to the expected value in the authentication vector. If it does, the
protect further communications between the identity module and the USIM is considered authenticated, and IK and CK can be used to
home environment. protect further communications between the USIM and the home
environment.
3.2. EAP-AKA' Protocol 4.2. EAP-AKA' Protocol
When AKA is embedded into EAP, the authentication on the network side When AKA is embedded into EAP, the authentication processing on the
is moved to the home environment; the serving network performs the network side is moved to the home environment. The 3GPP
role of a pass-through authenticator. Figure 1 describes the basic authentication database (AD) generates authentication vectors. The
flow in the EAP-AKA' authentication process. The definition of the 3GPP authentication server takes the role of EAP server. The USIM
full protocol behavior, along with the definition of attributes combined with the mobile phone takes the role of the client. The
AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in [RFC9048] and difference between EAP-AKA [RFC4187] and EAP-AKA' [RFC9048] is that
[RFC4187]. EAP-AKA' binds the derived keys to the name of access network.
Figure 1 describes the basic flow in the EAP-AKA' authentication
process. The definition of the full protocol behavior, along with
the definition of attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES can
be found in [RFC9048] and [RFC4187]. Note the use of EAP-terminology
from hereon. That is, the 3GPP serving network takes on the role of
an EAP access network.
Peer Server Peer Server
| | | |
| EAP-Request/Identity | | EAP-Request/Identity |
|<-----------------------------------------------------------+ |<-----------------------------------------------------------+
| | | |
| EAP-Response/Identity | | EAP-Response/Identity |
| (Includes user's Network Access Identifier, NAI) | | (Includes user's Network Access Identifier, NAI) |
+----------------------------------------------------------->| +----------------------------------------------------------->|
| +-----------------------------------------------------+--+ | +-----------------------------------------------------+--+
| | Server determines the network name and ensures that | | | Server determines the network name and ensures that |
| | the given access network is authorized to use the | | | the given access network is authorized to use the |
| | claimed name. The server then runs the AKA' algorithms | | | claimed name. The server then runs the AKA' algorithms |
| | generating RAND and AUTN, derives session keys from | | | generating RAND and AUTN, derives session keys from |
| | CK' and IK'. RAND and AUTN are sent as AT_RAND and | | | CK' and IK'. RAND and AUTN are sent as AT_RAND and |
| | AT_AUTN attributes, whereas the network name is | | | AT_AUTN attributes, whereas the network name is |
| | transported in the AT_KDF_INPUT attribute. AT_KDF | | | transported in the AT_KDF_INPUT attribute. AT_KDF |
| | signals the used key derivation function. The session | | | signals the used key derivation function. The session |
| | keys are used in creating the AT_MAC attribute. | | | keys are used to create the AT_MAC attribute. |
| +-----------------------------------------------------+--+ | +-----------------------------------------------------+--+
| | | |
| EAP-Request/AKA'-Challenge | | EAP-Request/AKA'-Challenge |
| (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) | | (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) |
|<-----------------------------------------------------------+ |<-----------------------------------------------------------+
+--+-----------------------------------------------------+ | +--+-----------------------------------------------------+ |
| The peer determines what the network name should be, | | | The peer determines what the network name should be, | |
| based on, e.g., what access technology it is using. | | | based on, e.g., what access technology it is using. | |
| The peer also retrieves the network name sent by the | | | The peer also retrieves the network name sent by the | |
| network from the AT_KDF_INPUT attribute. The two names | | | network from the AT_KDF_INPUT attribute. The two names | |
| are compared for discrepancies, and if necessary, the | | | are compared for discrepancies, and if they do not | |
| authentication is aborted. Otherwise, the network name | | | match, the authentication is aborted. Otherwise, the | |
| from AT_KDF_INPUT attribute is used in running the | | | network name from AT_KDF_INPUT attribute is used in | |
| AKA' algorithms, verifying AUTN from AT_AUTN and MAC | | | running the AKA' algorithms, verifying AUTN from | |
| from AT_MAC attributes. The peer then generates RES. | | | AT_AUTN and MAC from AT_MAC attributes. The peer then | |
| The peer also derives session keys from CK'/IK'. The | | | generates RES. The peer also derives session keys from | |
| AT_RES and AT_MAC attributes are constructed. | | | CK'/IK'. The AT_RES and AT_MAC attributes are | |
| constructed. | |
+--+-----------------------------------------------------+ | +--+-----------------------------------------------------+ |
| | | |
| EAP-Response/AKA'-Challenge | | EAP-Response/AKA'-Challenge |
| (AT_RES, AT_MAC) | | (AT_RES, AT_MAC) |
+----------------------------------------------------------->| +----------------------------------------------------------->|
| +-----------------------------------------------------+--+ | +-----------------------------------------------------+--+
| | Server checks the RES and MAC values received in | | | Server checks the RES and MAC values received in |
| | AT_RES and AT_MAC, respectively. Success requires both | | | AT_RES and AT_MAC, respectively. Success requires both |
| | to be found correct. | | | compared values match, respectively. |
| +-----------------------------------------------------+--+ | +-----------------------------------------------------+--+
| | | |
| 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 4.3. Attacks Against Long-Term Keys in Smart Cards
Current 3GPP systems use SIM pre-shared key-based protocols and
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 question in that discussion relates to the potential
reports of compromised long term pre-shared keys used in AKA compromise of long-term keys, as discussed earlier. Attacks on long-
[Heist2015]. These attacks are not specific to AKA or EAP-AKA', as term keys are not specific to AKA or EAP-AKA', and all security
all security systems fail at least to some extent if key material is systems fail at least to some extent if key material is stolen.
stolen. However, the reports indicate a need to look into solutions However, it would be preferable to retain some security even in the
that can operate at least to an extent under these types of attacks. face of such attacks. This document specifies a mechanism that
It is noted in [Heist2015] that some security can be retained even in reduces risks to compromise of key material belonging to previous
the face of the attacks by providing Forward Secrecy (FS) [DOW1992] sessions, before the long-term keys were compromised. It also forces
for the session key. If AKA would have provided FS, compromising the attackers to be active even after the compromise.
pre-shared key would not be sufficient to perform passive attacks;
the attacker is, in addition, forced to be a Man-In-The-Middle (MITM)
during the AKA run and subsequent communication between the parties.
4. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
5. Protocol Overview 5. Protocol Overview
Forward Secrecy for EAP-AKA' is achieved by using an Elliptic Curve Forward secrecy for EAP-AKA' is achieved by using an Elliptic Curve
Diffie-Hellman (ECDH) exchange [RFC7748]. To provide FS, the Diffie-Hellman (ECDH) exchange [RFC7748]. To provide FS, the
exchange must be run in an ephemeral manner, i.e., both sides exchange must be run in an ephemeral manner, i.e., both sides
generate temporary keys according to the negotiated ciphersuite, generate temporary keys according to the negotiated ciphersuite,
e.g., for X25519 this is done as specified in [RFC7748]. This method e.g., for X25519 this is done as specified in [RFC7748]. This method
is referred to as ECDHE, where the last 'E' stands for Ephemeral. is referred to as ECDHE, where the last 'E' stands for Ephemeral.
The two initially registered elliptic curves and their wire format is The two initially registered elliptic curves and their wire formats
chosen to align with the elliptic curves and formats specified for are chosen to align with the elliptic curves and formats specified
Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 for Subscription Concealed Identifier (SUCI) encryption in
of 3GPP TS 33.501 [TS.33.501]. 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 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 the 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 home environment. Recall that the home environment represent the
3GPP Authentication Database (AD) and server. The details of those
interactions are outside the scope of this document, however, and the interactions are outside the scope of this document, however, and the
reader is referred to the 3GPP specifications. reader is referred to the 3GPP specifications. For 5G this is
specified in 3GPP TS 33.501 [TS.33.501]
USIM Peer Server HSS USIM Peer Server AD
| | | | | | | |
| | EAP-Req/Identity | | | | EAP-Req/Identity | |
| |<---------------------------+ | | |<---------------------------+ |
| | | | | | | |
| | EAP-Resp/Identity | | | | EAP-Resp/Identity | |
| | (Privacy-Friendly) | | | | (Privacy-Friendly) | |
| +--------------------------->| | | +--------------------------->| |
| +-------+----------------------------+----------------+--+ | +-------+----------------------------+----------------+--+
| | Server now has an identity for the peer. The server | | | Server now has an identity for the peer. The server |
| | then asks the help of HSS to run AKA algorithms, | | | then asks the help of AD to run AKA algorithms, |
| | generating RAND, AUTN, XRES, CK, IK. Typically, the | | | generating RAND, AUTN, XRES, CK, IK. Typically, the |
| | HSS performs the first part of key derivations so that | | | AD performs the first part of key derivations so that |
| | the authentication server gets the CK' and IK' keys | | | the 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, key deriv. |
| | | function, | | | | function, |
| | | network name | | | | network name |
| | +--------------->| | | +--------------->|
| | | | | | | |
| | | RAND, AUTN, | | | | RAND, AUTN, |
skipping to change at page 11, line 13 skipping to change at page 11, line 15
| | | | | | | |
| | EAP-Resp/AKA'-Challenge | | | | EAP-Resp/AKA'-Challenge | |
| | AT_RES, AT_PUB_ECDHE, | | | | AT_RES, AT_PUB_ECDHE, | |
| | AT_MAC | | | | AT_MAC | |
| +--------------------------->| | | +--------------------------->| |
| +-------+----------------------------+----------------+--+ | +-------+----------------------------+----------------+--+
| | The server now has all the necessary values. It | | | The server now has all the necessary values. It |
| | generates the ECDHE shared secret and checks the RES | | | generates the ECDHE shared secret and checks the RES |
| | and MAC values received in AT_RES and AT_MAC, | | | and MAC values received in AT_RES and AT_MAC, |
| | respectively. Success requires both to be found | | | respectively. Success requires both to be found |
| | correct. Note that when this specification is used, | | | correct. Note that when this document is used, |
| | the keys generated from EAP-AKA' are based on both | | | the keys generated from EAP-AKA' are based on CK, IK, |
| | CK/IK as well as the ECDHE value. Even if there was an | | | and the ECDHE value. Even if there was an attacker who |
| | attacker who held the long-term secret keys, only an | | | held the long-term key, only an active attacker could |
| | active attacker could have determined the generated | | | have determined the generated session keys; in basic |
| | session keys; in basic EAP-AKA' the generated keys are | | | EAP-AKA' the generated keys are only based on CK and |
| | only based on CK and IK. | | | IK. |
| +-------+----------------------------+----------------+--+ | +-------+----------------------------+----------------+--+
| | | | | | | |
| | EAP-Success | | | | EAP-Success | |
| |<---------------------------+ | | |<---------------------------+ |
| | | | | | | |
Figure 2: EAP-AKA' FS Authentication Process Figure 2: EAP-AKA' FS Authentication Process
6. Extensions to EAP-AKA' 6. Extensions to EAP-AKA'
skipping to change at page 12, line 7 skipping to change at page 12, line 9
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 key. The value depends on This value is the sender's ECDHE public key. The value depends on
AT_KDF_FS and is calculated as follows: AT_KDF_FS and is calculated as follows:
* For X25519/Curve25519, the length of this value is 32 bytes, * For X25519, the length of this value is 32 bytes, encoded as
encoded as specified in [RFC7748] Section 5. specified in [RFC7748] Section 5.
* For P-256, the length of this value is 33 bytes, encoded using * For P-256, the length of this value is 33 bytes, encoded using
the compressed form specified in Section 2.3.3 of [SEC1]. the compressed form specified in Section 2.3.3 of [SEC1].
To retain the security of the keys, the sender SHALL generate a To retain the security of the keys, the sender SHALL generate a
fresh value for each run of the protocol. fresh value for each run of the protocol.
6.2. AT_KDF_FS 6.2. AT_KDF_FS
The AT_KDF_FS indicates the used or desired forward secrecy key The AT_KDF_FS indicates the used or desired forward secrecy key
generation function, if the Forward Secrecy extension is taken into generation function, if the Forward Secrecy (FS) extension is used.
use. It will also at the same time indicate the used or desired It will also indicate the used or desired ECDHE group. A new
ECDHE group. A new attribute is needed to carry this information, as attribute is needed to carry this information, as AT_KDF carries the
AT_KDF carries the basic KDF value which is still used together with basic KDF value which is still used together with the forward secrecy
the forward secrecy KDF value. The basic KDF value is also used by KDF value. The basic KDF value is also used by those EAP peers that
those EAP peers that cannot or do not want to use this extension. cannot or do not want to use this extension.
This specification only specifies the behavior relating to the This document only specifies the behavior relating to the following
following combinations of basic KDF values and forward secrecy KDF combinations of basic KDF values and forward secrecy KDF values: The
values: The basic KDF value in AT_KDF is 1, as specified in [RFC5448] basic KDF value in AT_KDF is 1, as specified in [RFC5448] and
and [RFC9048], and the forward secrecy KDF values in AT_KDF_FS are 1 [RFC9048], and the forward secrecy KDF values in AT_KDF_FS are 1 or
or 2, as specified below and in Section 6.3. 2, as specified below and in Section 6.3.
Any future specifications that add either new basic KDF or new Any future specifications that add either new basic KDF or new
forward secrecy KDF values need to specify how they are treated and forward secrecy KDF values need to specify how they are treated and
what combinations are allowed. This requirement is an update to how what combinations are allowed. This requirement is an update to how
[RFC5448] and [RFC9048] may be extended in the future. [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
skipping to change at page 13, line 24 skipping to change at page 13, line 27
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:
* If the peer supports and is willing to use the FS Key Derivation * 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 document,
specification, the function is taken into use without any further the function is taken into use without any further negotiation.
negotiation.
* If the peer does not support this function or is unwilling to use * If the peer does not support this function or is unwilling to use
it, it responds to the server with an indication that a different it, it responds to the server with an indication that a different
function is needed. Similarly with the negotiation process function is needed. Similarly with the negotiation process
defined in [RFC9048] for AT_KDF, the peer sends EAP-Response/AKA'- defined in [RFC9048] for AT_KDF, the peer sends 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
ones suggested by the server earlier. If there is no suitable ones suggested by the server earlier. If there is no suitable
alternative, the peer has a choice of either falling back to EAP- alternative, the peer has a choice of either falling back to EAP-
AKA' or behaving as if AUTN had been incorrect and failing AKA' or behaving as if AUTN had been incorrect and failing
authentication (see Figure 3 of [RFC4187]). The peer MUST fail authentication (see Figure 3 of [RFC4187]). The peer MUST fail
the authentication if there are any duplicate values within the the authentication if there are any duplicate values within the
list of AT_KDF_FS attributes (except where the duplication is due list of AT_KDF_FS attributes (except where the duplication is due
to a request to change the key derivation function; see below for to a request to change the key derivation function; see below for
further information). further information).
* If the peer does not recognize the extension defined in this * If the peer does not recognize the extension defined in this
specification or is unwilling to use it, it ignores the AT_KDF_FS document or is unwilling to use it, it ignores the AT_KDF_FS
attribute. attribute.
Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF_FS from the Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF_FS from the
peer, the server checks that the suggested AT_KDF_FS value was one of peer, the server checks that the suggested AT_KDF_FS value was one of
the alternatives in its offer. The first AT_KDF_FS value in the the alternatives in its offer. The first AT_KDF_FS value in the
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].
skipping to change at page 14, line 41 skipping to change at page 14, line 43
The FS Key Derivation Function type value is only used in the The FS Key Derivation Function type value is only used in the
AT_KDF_FS attribute. When the forward secrecy extension is used, the AT_KDF_FS attribute. When the forward secrecy extension is used, the
AT_KDF_FS attribute determines how to derive the keys MK_ECDHE, K_re, AT_KDF_FS attribute determines how to derive the keys MK_ECDHE, K_re,
MSK, and EMSK. The AT_KDF_FS attribute should not be confused with MSK, and EMSK. The AT_KDF_FS attribute should not be confused with
the different range of key derivation functions that can be the different range of key derivation functions that can be
represented in the AT_KDF attribute as defined in [RFC9048]. When represented in the AT_KDF attribute as defined in [RFC9048]. When
the forward secrecy extension is used, the AT_KDF attribute only the forward secrecy extension is used, the AT_KDF attribute only
specifies how to derive the keys MK, K_encr, and K_aut. 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 EAP-AKA' [RFC9048]
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 FS Key Derivation Function field in the AT_KDF_FS attribute When the FS Key Derivation Function field in the AT_KDF_FS attribute
is set to 1 or 2 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 set to 1, the Master Key (MK) is derived as follows attribute is set to 1, the Master Key (MK) and accompanying keys are
below. derived as follows.
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity) MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)
K_encr = MK[0..127] K_encr = MK[0..127]
K_aut = MK[128..383] K_aut = MK[128..383]
K_re = MK_ECDHE[0..255] K_re = MK_ECDHE[0..255]
MSK = MK_ECDHE[256..767] MSK = MK_ECDHE[256..767]
EMSK = MK_ECDHE[768..1279] EMSK = MK_ECDHE[768..1279]
Requirements for how to securely generate, validate, and process the Requirements for how to securely generate, validate, and process the
ephemeral public keys depend on the elliptic curve. ephemeral public keys depend on the elliptic curve.
For P-256 the SHARED_SECRET is the shared secret computed as For P-256 the SHARED_SECRET is the shared secret computed as
specified in Section 5.7.1.2 of [SP-800-56A]. Public key validation specified in Section 5.7.1.2 of [SP-800-56A]. Public key validation
requirements are defined in Section 5 of [SP-800-56A]. At least requirements are defined in Section 5 of [SP-800-56A]. At least
partial public-key validation MUST be done. The uncompressed partial public-key validation MUST be done for the ephemeral public
y-coordinate can be computed as described in Section 2.3.4 of [SEC1]. keys. The uncompressed y-coordinate can be computed as described in
Section 2.3.4 of [SEC1].
For X25519 the SHARED_SECRET is the shared secret computed as For X25519 the SHARED_SECRET is the shared secret computed as
specified in Section 6.1 of [RFC7748]. Both the peer and the server specified in Section 6.1 of [RFC7748]. Both the peer and the server
MAY check for zero-value shared secret as specified in Section 6.1 of MAY check for zero-value shared secret as specified in Section 6.1 of
[RFC7748]. [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 If validation of the other party's ephemeral public key or the shared
parties MUST behave as if the current EAP-AKA' authentication process secret fails, a party MUST behave as if the current EAP-AKA'
starts again from the beginning. authentication process starts again from the beginning.
The rest of computation proceeds as defined in Section 3.3 of The rest of 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,
skipping to change at page 16, line 10 skipping to change at page 16, line 22
[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. A privacy-friendly identifier [RFC9048] SHALL be used.
6.4. ECDHE Groups 6.4. ECDHE Groups
The selection of suitable groups for the elliptic curve computation The selection of suitable groups for the elliptic curve computation
is necessary. The choice of a group is made at the same time as is necessary. The choice of a group is made at the same time as
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 Appendix D.1.2.3 of [FIPS186-4] (SEC group secp256r1), specified in Section 3.2.1.3 of [SP-800-186]
or alternatively Section 2.4.2 of [SEC2]. The support for this group or alternatively Section 2.4.2 of [SEC2]. The support for this group
is REQUIRED. is REQUIRED.
The term "support" here means that the group MUST be implemented and
MUST be possible to use during a protocol run.
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]
apply. apply.
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 attributes in NOT be added to this message. The appearance of these attributes in
a received message MUST be ignored. a 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 and that a privacy-friendly identifier NOT be added to this message. The appearance of these attributes in
MUST be used. The appearance of these attributes in a received a received message MUST be ignored. The peer identifier SHALL comply
message MUST be ignored. with the privacy-friendly requirements of [RFC9190]. An example of a
compliant way of constructing a privacy-friendly peer identifier is
using a non-NULL SUCI [TS.33.501].
6.5.3. EAP-Request/AKA'-Challenge 6.5.3. EAP-Request/AKA'-Challenge
The server sends the EAP-Request/AKA'-Challenge on full The server sends the EAP-Request/AKA'-Challenge on full
authentication as specified by [RFC4187] and [RFC9048]. The authentication as specified by [RFC4187] and [RFC9048]. The
attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and checked
on reception as specified in [RFC4187]. They are also necessary for on reception as specified in [RFC4187]. They are also necessary for
backwards compatibility. backwards compatibility.
In EAP-Request/AKA'-Challenge, there is no message-specific data In EAP-Request/AKA'-Challenge, there is no message-specific data
covered by the MAC for the AT_MAC attribute. The AT_KDF_FS and covered by the MAC for the AT_MAC attribute. The AT_KDF_FS and
AT_PUB_ECDHE attributes MUST be included. The AT_PUB_ECDHE attribute AT_PUB_ECDHE attributes MUST be included. The AT_PUB_ECDHE attribute
carries the server's public Diffie-Hellman key. If either AT_KDF_FS carries the server's public Diffie-Hellman key. If either AT_KDF_FS
or AT_PUB_ECDHE is missing on reception, the peer MUST treat them as or AT_PUB_ECDHE is missing on reception, the peer MUST treat it as if
if neither one was sent, and the assume that the extension defined in neither one was sent, and the assume that the extension defined in
this specification is not in use. this document is not in use.
The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING, The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING,
AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID and other attributes may be AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID and other attributes may be
included as specified in Section 9.3 of [RFC4187]. included as specified in Section 9.3 of [RFC4187].
When processing this message, the peer MUST process AT_RAND, AT_AUTN, When processing this message, the peer MUST process AT_RAND, AT_AUTN,
AT_KDF_FS, AT_PUB_ECDHE before processing other attributes. Only if AT_KDF_FS, 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
[RFC9048]. Finally, the operation in case an error occurs is [RFC9048]. Finally, if there is an error error, see Section 6.3.1.
specified in Section 6.3.1. of [RFC4187]. 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
[RFC9048]. If the peer supports and is willing to perform the [RFC9048]. If the peer supports and is willing to perform the
extension specified in this protocol, and the server had made a valid extension specified in this protocol, and the server had made a valid
request involving the attributes specified in Section 6.5.3, the peer request involving the attributes specified in Section 6.5.3, the peer
responds per the rules specified below. Otherwise, the peer responds responds per the rules specified below. Otherwise, the peer responds
as specified in [RFC4187] and [RFC9048] and ignores the attributes as specified in [RFC4187] and [RFC9048] and ignores the attributes
skipping to change at page 18, line 7 skipping to change at page 18, line 26
requires it to always use this extension, it behaves as if AUTN had requires it to always use this extension, it behaves as if AUTN had
been incorrect and fails the authentication. been incorrect and fails the authentication.
The AT_MAC attribute MUST be included and checked as specified in The AT_MAC attribute MUST be included and checked as specified in
[RFC9048]. In EAP-Response/AKA'-Challenge, there is no message- [RFC9048]. In EAP-Response/AKA'-Challenge, there is no message-
specific data covered by the MAC. The AT_PUB_ECDHE attribute MUST be specific data covered by the MAC. The AT_PUB_ECDHE attribute MUST be
included, and carries the peer's public Diffie-Hellman key. included, and carries the peer's public Diffie-Hellman key.
The AT_RES attribute MUST be included and checked as specified in The AT_RES attribute MUST be included and checked as specified in
[RFC4187]. When processing this message, the Server MUST process [RFC4187]. When processing this message, the Server MUST process
AT_RES before processing other attributes. Only if these attribute AT_RES before processing other attributes. The Server derives keys
is verified to be valid, the Server derives keys and verifies AT_MAC. and verifies AT_MAC only when this attribute is verified to be valid.
If the Server has proposed the use of the extension specified in this If the Server has proposed the use of the extension specified in this
protocol, but the peer ignores and continues the basic EAP-AKA' protocol, but the peer ignores and continues the basic EAP-AKA'
authentication, the Server makes policy decision of whether this is authentication, the Server makes policy decision of whether this is
allowed. If this is allowed, it continues the EAP-AKA' allowed. If this is allowed, it continues the EAP-AKA'
authentication to completion. If it is not allowed, the Server MUST authentication to completion. If it is not allowed, the Server MUST
behave as if authentication failed. behave as if authentication failed.
The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA and other The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA and other
attributes may be included as specified in Section 9.4 of [RFC4187]. attributes may be included as specified in Section 9.4 of [RFC4187].
skipping to change at page 19, line 19 skipping to change at page 19, line 37
6.5.11. EAP-Response/AKA'-Notification 6.5.11. EAP-Response/AKA'-Notification
No changes. No changes.
7. Security Considerations 7. Security Considerations
This section deals only with the changes to security considerations This section deals only with the changes to security considerations
as they differ from EAP-AKA', or as new information has been gathered as they differ from EAP-AKA', or as new information has been gathered
since the publication of [RFC9048]. since the publication of [RFC9048].
The possibility of attacks against key storage offered in SIM or As discussed earlier (see Section 1 and Section 4.3, forward secrecy
other smart cards has been a known threat. But as the discussion in is an important countermeasure against well-resourced adversaries
Section 3.3 shows, the likelihood of practically feasible attacks that who may get access to the long-term keys, see Section 1. Many
such as breaches in the smart card supply chain has increased. Many of the attacks against these keys can be best dealt with improved
of these attacks can be best dealt with improved processes, e.g., processes, e.g., limiting the access to the key material within the
limiting the access to the key material within the factory or factory or personnel, etc. But not all attacks can be entirely ruled
personnel, etc. But not all attacks can be entirely ruled out for out for well-resourced adversaries, irrespective of what the
well-resourced adversaries, irrespective of what the technical technical algorithms and protection measures are. And the likelihood
algorithms and protection measures are. Always assuming breach such of practically feasible attacks has increased. To assume that a
as key compromise and minimizing the impact of breach are essential breach is inevitable or has likely already occurred [NSA-ZT], and to
zero-trust principles. minimize impact when breaches occur [NIST-ZT] are essential zero
trust principles. One type of breach is key compromise or key
exfiltration.
If a mechanism without forward secrecy such as (5G-AKA, EAP-AKA') is If a mechanism without ephemeral key exchange such as (5G-AKA, EAP-
used the effects of key compromise are devastating. The serious AKA') is used the effects of key compromise are devastating. There
consequences of breach somewhere in the supply chain or after are serious consequences of not properly providing forward secrecy
delivery that are possible when 5G-AKA or EAP-AKA' is used but not for the key establishment. For both control and user plane, and both
when something with forward secrecy like EAP-AKA-FS is used are: directions:
1. A passive attacker can eavesdrop (decrypt) all future 5G 1. An attacker can decrypt 5G communication that they previously
communication (control and user plane both directions), recorded.
2. A passive attacker can decrypt 5G communication that they 2. A passive attacker can eavesdrop (decrypt) all future 5G
previously recorded in the past (control and user plane both communication.
directions), and
3. An active attacker can impersonate UE and Network and inject 3. An active attacker can impersonate the UE or the Network and
messages in an ongoing 5G connection between the real UE and the inject messages in an ongoing 5G connection between the real UE
real network (control and user plane both directions). and the real network.
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, IKEv2, SSH, QUIC, WireGuard, done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, IKEv2, SSH, QUIC, WireGuard,
Signal, etc.). It is RECOMMENDED to long term completely phase out Signal, etc.). It is RECOMMENDED that EAP-AKA methods without
AKA without forward secrecy. forward secrecy be phased out in the long term.
This extension can provide assistance in situations where there is a This extension provide assistance against passive attacks from
danger of attacks against the key material on SIM cards by attackers that have comprimised the key material on USIM cards.
adversaries that cannot or who are unwilling to mount active attacks Passive attacks are attractive for attackers performing large scale
against a large number of sessions. The extension also provides pervasive monitoring as they require much less resources and are much
protection against active attacks as they are forced to be a Man-In- harder to detect. The extension also provides protection against
The-Middle (MITM) during the AKA run and subsequent communication active attacks as they are forced to be a Man-In-The-Middle (MITM)
between the parties. Without forward secrecy an active attacker that during the AKA run and subsequent communication between the parties.
has compromised the long-term key can inject messages in an Without forward secrecy an active attacker that has compromised the
connection between the real Peer and the real server without being a long-term key can inject messages in an connection between the real
man-in-the-middle. This extension is most useful when used in a Peer and the real server without being a man-in-the-middle. This
context where EAP keys are used without further mixing that can extension is most useful when used in a context where the MSK/EMSK
provide Forward Secrecy. For instance, when used with IKEv2 are used in protocols not providing forward secrecy. For instance,
[RFC7296], the session keys produced by IKEv2 have this property, so if used with IKEv2 [RFC7296], the session keys produced by IKEv2 have
better characteristics of EAP keys is not that useful. However, this property, so better characteristics of the MSK and EMSK is not
typical link layer usage of EAP does not involve running Diffie- that useful. However, typical link layer usage of EAP does not
Hellman, so using EAP to authenticate access to a network is one involve running another, forward secure, key exchange. Therefore,
situation where the extension defined in this document can be using EAP to authenticate access to a network is one situation where
helpful. the extension defined in this document can be 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 FS 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, FS is still Even if a compromise of the long-term keys has occurred, FS is still
provided for all future sessions, as long as the attacker does not provided for all future sessions, as long as the attacker does not
become an active attacker. Of course, as with other protocols, if 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.
Among other things, such an active attacker can impersonate any
legitimate endpoint in EAP-AKA', become a MITM in EAP-AKA' or the
extension defined in this document, retrieve all keys, or turn off
FS. Still, past sessions where FS was in use remain protected.
Achieving FS requires that when a connection is closed, each endpoint The extension does not provide protection against active attackers
MUST forget not only the ephemeral keys used by the connection but with access to the long-term key that mount a MITM attack on future
also any information that could be used to recompute those keys. EAP-AKA' runs will be able to eavesdrop on the traffic protected by
the resulting session key(s). Still, past sessions where FS was in
use remain protected.
Using EAP-AKA' FS once provides forward secrecy. Forward secrecy Using EAP-AKA' FS once provides forward secrecy. Forward secrecy
limits the effect of key leakage in one direction (compromise of a limits the effect of key leakage in one direction (compromise of a
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 7.1. Deployment Considerations
Achieving FS requires that when a connection is closed, each endpoint
MUST forget not only the ephemeral keys used by the connection but
also any information that could be used to recompute those keys.
Similarly, other parts of the system matter. For instance, when the
keys generated by EAP are transported to a pass-through
authenticator, such transport must also provide forward secure
encryption with respect to the long-term keys used to establish its
security. Otherwise, an adversary may attack the transport
connection used to carry keys from EAP, and use this method to gain
access to current and past keys from EAP, which in turn would lead to
the compromise of anything protected by those EAP keys.
Of course, these considerations apply to any EAP method, not only
this one.
7.2. Security Properties
The following security properties of EAP-AKA' are impacted through The following security properties of EAP-AKA' are impacted through
this extension: this extension:
Protected ciphersuite negotiation Protected ciphersuite negotiation
EAP-AKA' has a negotiation mechanism for selecting the key EAP-AKA' has a negotiation mechanism for selecting the 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 21, line 40 skipping to change at page 22, line 28
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_FS and AT_PUB_ECDHE attributes in the EAP-Request/AKA'- AT_KDF_FS and AT_PUB_ECDHE attributes in the EAP-Request/AKA'-
Challenge message. These attributes are protected by AT_MAC, Challenge message. These attributes are protected by AT_MAC,
so attempts to change or omit them by an adversary will be so attempts to change or omit them by an adversary will be
detected. detected.
Except of course, if the adversary holds the long-term shared Except of course, if the adversary holds the long-term key and
secret and is willing to engage in an active attack. Such an is willing to engage in an active attack. Such an attack can,
attack can, for instance, forge the negotiation process so that for instance, forge the negotiation process so that no FS will
no FS will be provided. However, as noted above, an attacker be provided. However, as noted above, an attacker with these
with these capabilities will in any case be able to impersonate capabilities will in any case be able to impersonate any party
any party in the protocol and perform MITM attacks. That is in the protocol and perform MITM attacks. That is not a
not a situation that can be improved by a technical solution. 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 laborious. surveillance more laborious.
The security properties of the extension also depend on a The security properties of the extension also depend on a
policy choice. As discussed in Section 6.5.4, both the peer policy choice. As discussed in Section 6.5.4, both the peer
and the server make a policy decision of what to do when it was and the server make a policy decision of what to do when it was
willing to perform the extension specified in this protocol, willing to perform the extension specified in this protocol,
but the other side does not wish to use the extension. but the other side does not wish to use the extension.
skipping to change at page 22, line 23 skipping to change at page 23, line 13
by the parties, no FS can obviously be provided. by the parties, no FS can obviously be provided.
If turning off the extension specified in this protocol is not If turning off the extension specified in this protocol is not
allowed by policy, the use of legacy equipment that does not allowed by policy, the use of legacy equipment that does not
support this protocol is no longer possible. This may be support this protocol is no longer possible. This may be
appropriate when, for instance, support for the extension is appropriate when, for instance, support for the extension is
sufficiently widespread, or required in a particular version of sufficiently widespread, or required in a particular version of
a mobile network. a mobile network.
Key derivation Key derivation
This extension provides key material that is based on the Diffie- This extension provides forward secrecy. As described in several
Hellman keys, yet bound to the authentication through the SIM places in this specification, this can be roughly summarized as
card. This means that subsequent payload communications between that an attacker with access to long-term keys is unable to obtain
the parties are protected with keys that are not solely based on session keys of ended past sessions, assuming these sessions
information in the clear (such as the RAND) and information deleted all relevant session key material. This extension does
derivable from the long-term shared secrets on the SIM card. As a not change the properties related to re-authentication. No new
result, if anyone successfully recovers shared secret information, Diffie-Hellman run is performed during the re-authentication
they are unable to decrypt communications protected by the keys allowed by EAP-AKA'. However, if this extension was in use when
generated through this extension. Note that the recovery of the original EAP-AKA' authentication was performed, the keys used
shared secret information could occur either before or after the for re-authentication (K_re) are based on the Diffie-Hellman keys,
time that the protected communications are used. When this and hence continue to be equally safe against expose of the long-
extension is used, communications at time t0 can be protected if term key as the original authentication.
at some later time t1 an adversary learns of long-term shared
secret and has access to a recording of the encrypted
communications.
Obviously, this extension is still vulnerable to attackers that
are willing to perform an active attack and who at the time of the
attack have access to the long-term shared secret.
This extension does not change the properties related to re-
authentication. No new Diffie-Hellman run is performed during the
re-authentication allowed by EAP-AKA'. However, if this extension
was in use when the original EAP-AKA' authentication was
performed, the keys used for re-authentication (K_re) are based on
the Diffie-Hellman keys, and hence continue to be equally safe
against expose of the long-term secrets as the original
authentication.
7.2. Denial-of-Service 7.3. Denial-of-Service
In addition, it is worthwhile to discuss Denial-of-Service attacks In addition, it is worthwhile to discuss Denial-of-Service 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.
* In 5G context, other parts of the connection setup involve public * 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.
* This specification is constructed so that a separation between the * This specification is constructed so that a separation between the
USIM and Peer on client side and the Server and HSS on network USIM and Peer on client side and the Server and AD on network side
side is possible. This ensures that the most sensitive (or is possible. This ensures that the most sensitive (or legacy)
legacy) system components cannot be the target of the attack. For system components cannot be the target of the attack. For
instance, EAP-AKA' and public key cryptography takes place in the instance, EAP-AKA' and public key cryptography takes place in the
phone and not the low-power SIM card. phone and not the low-power USIM card.
* EAP-AKA' has been designed so that the first actual message in the * EAP-AKA' has been designed so that the first actual message in the
authentication process comes from the Server, and that this authentication process comes from the Server, and that this
message will not be sent unless the user has been identified as an message will not be sent unless the user has been identified as an
active subscriber of the operator in question. While the initial active subscriber of the operator in question. While the initial
identity can be spoofed before authentication has succeeded, this identity can be spoofed before authentication has succeeded, this
reduces the efficiency of an attack. reduces the efficiency of an attack.
* Finally, this memo specifies an order in which computations and * Finally, this memo specifies an order in which computations and
checks must occur. When processing the EAP-Request/AKA'-Challenge checks must occur. 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
FS related parameters (see Section 6.5.4). The same is true of FS related parameters (see Section 6.5.4). The same is true of
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 key in
in some way, and only then will the FS calculations become active. some way, and only then will the FS calculations become active.
This limits the Denial-of-Service to specific, identified This limits the 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.3. Identity Privacy 7.4. Identity Privacy
Best practice privacy today is to mandate client identity protection As specified in Section 6.5, the peer identity sent in the Identity
as is done in EAP-TLS 1.3, EAP-TTLS 1.3, etc. A client supporting Response message needs to follow the privacy-friendly requirements in
EAP-AKA' FS MUST NOT send its username (or any other permanent [RFC9190].
identifiers) in cleartext in the Identity Response (or any message
used instead of the Identity Response).
7.4. Unprotected Data and Privacy 7.5. Unprotected Data and Privacy
Unprotected data and metadata can reveal sensitive information and Unprotected data and metadata can reveal sensitive information and
need to be selected with care. In particular, this applies to need to be selected with care. In particular, this applies to
AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF,
AT_KDF_FS, and AT_PUB_ECDHE reveal the used cryptographic algorithms, AT_KDF_FS, and AT_PUB_ECDHE reveal the used cryptographic algorithms,
if these depend on the peer identity they leak information about the if these depend on the peer identity they leak information about the
peer. AT_KDF_INPUT reveals the network name, although that is done peer. AT_KDF_INPUT reveals the network name, although that is done
on purpose to bind the authentication to a particular context. on purpose to bind the authentication to a particular context.
An attacker observing network traffic may use the above types of An attacker observing network traffic may use the above types of
information for traffic flow analysis or to track an endpoint. information for traffic flow analysis or to track an endpoint.
7.5. Post-Quantum Considerations 7.6. Forward Secrecy within AT_ENCR
As of the publication of this specification, it is unclear when or They keys K_encr and K_aut are calculated and used before the shared
even if a quantum computer of sufficient size and power to exploit secret from the ephemeral key exchange is available.
elliptic curve cryptography will exist. Deployments that need to
consider risks decades into the future should transition to Post- K_encr and K_aut are used to encrypt and MAC data in the EAP-Req/
Quantum Cryptography (PQC) in the not-too-distant future. Other AKA'-Challenge message, especially the DH g^x ephemeral pub key. At
systems may employ PQC when the quantum threat is more imminent. that point the server does not yet have the corresponding g^y from
Current PQC algorithms have limitations compared to Elliptic Curve the peer and cannot compute the shared secret. K_aut is then used as
Cryptography (ECC) and the data sizes could be problematic for some the authentication key for the shared secret.
constrained systems. If a Cryptographically Relevant Quantum
Computer (CRQC) is built it could recover the SHARED_SECRET from the For K_encr though, none of the encrypted data sent in the EAP-Req/
ECDHE public keys. AKA'-Challenge message in the AT_ENCR attribute will be forward
secret. That data may include re-authentication pseudonyms, so an
adversary compromising the long-term key would be able to link re-
authentication protocol-runs when pseudonyms are used, within a
sequence of runs followed after a full EAP-AKA' authentication. No
such linking would be possible across different full authentaction
runs. If the pseudonum linkage risk is not acceptable, one way to
avoid the linkage is to always require full EAP-AKA' authentication.
7.7. Post-Quantum Considerations
As of the publication of this document, it is unclear when or even if
a quantum computer of sufficient size and power to exploit elliptic
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 This would not affect the ability of EAP-AKA' - with or without this
extension - to authenticate properly, however. As symmetric key extension - to authenticate properly, however. As symmetric key
cryptography is safe even if CRQCs are built, an adversary still will cryptography is safe even if CRQCs are built, an adversary still will
not be able to disrupt authentication as it requires computing a not be able to disrupt authentication as it requires computing a
correct AT_MAC value. This computation requires the K_aut key which correct AT_MAC value. This computation requires the K_aut key which
is based on MK and, ultimately, CK' and IK', but not SHARED_SECRET. is based on MK and, ultimately, CK' and IK', but not SHARED_SECRET.
Other output keys do include SHARED_SECRET via MK_ECDHE, but still Other output keys do include SHARED_SECRET via MK_ECDHE, but still
include also CK' and IK' which are entirely based on symmetric include also CK' and IK' which are entirely based on symmetric
cryptography. As a result, an adversary with a quantum computer cryptography. As a result, an adversary with a quantum computer
still cannot compute the other output keys either. still cannot compute the other output keys either.
However, if the adversary has also obtained knowledge of the secrets However, if the adversary has also obtained knowledge of the long-
associated with the SIM card, they could then compute CK', IK', and term key, they could then compute CK', IK', and SHARED_SECRET, and
SHARED_SECRET, and any derived output keys. This means that the any derived output keys. This means that the introduction of a
introduction of a powerful enough quantum computer would disable this powerful enough quantum computer would disable this protocol
protocol extension's ability to provide the forward security extension's ability to provide the forward security capability. This
capability. This would make it necessary to update the current ECC would make it necessary to update the current ECC algorithms in this
algorithms in this specification to PQC algorithms. This document to PQC algorithms. This document does not add such
specification does not add such algorithms, but a future update can algorithms, but a future update can do that.
do that.
Symmetric algorithms used in EAP-AKA' FS such as HMAC-SHA-256 and the Symmetric algorithms used in EAP-AKA' FS such as HMAC-SHA-256 and the
algorithms use to generate AT_AUTN and AT_RES are practically secure algorithms use to generate AT_AUTN and AT_RES are practically secure
against even large robust quantum computers. EAP-AKA' FS is against even large robust quantum computers. EAP-AKA' FS is
currently only specified for use with ECDHE key exchange algorithms, currently only specified for use with ECDHE key exchange algorithms,
but use of any Key Encapsulation Method (KEM), including Post-Quantum but use of any Key Encapsulation Method (KEM), including Post-Quantum
Cryptography (PQC) KEMs, can be specified in the future. While the Cryptography (PQC) KEMs, can be specified in the future. While the
key exchange is specified with terms of the Diffie-Hellman protocol, key exchange is specified with terms of the Diffie-Hellman protocol,
the key exchange adheres to a KEM interface. AT_PUB_ECDHE would then the key exchange adheres to a KEM interface. AT_PUB_ECDHE would then
contain either the ephemeral public key of the server or the contain either the ephemeral public key of the server or the
SHARED_SECRET encapsulated with the server's public key. SHARED_SECRET encapsulated with the server's public key. Note that
the use of a KEM might require other changes such as including the
ephemeral public key of the server in the key derivation to retain
the property that both parties contribute randomness to the session
key.
8. IANA Considerations 8. IANA Considerations
This extension of EAP-AKA' shares its attribute space and subtypes This extension of EAP-AKA' shares its attribute space and subtypes
with Extensible Authentication Protocol Method for Global System for with Extensible Authentication Protocol Method for Global System for
Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)
[RFC4186], EAP-AKA [RFC4186], and EAP-AKA' [RFC9048]. [RFC4186], EAP-AKA [RFC4186], and EAP-AKA' [RFC9048].
Two new values (TBA1, TBA2) in the skippable range need to be Two new values (TBA1, TBA2) in the skippable range need to be
assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_FS (Section 6.2 in assigned for AT_PUB_ECDHE (Section 6.1) and AT_KDF_FS (Section 6.2)
the "Attribute Types" registry under the "EAP-AKA and EAP-SIM in the "Attribute Types" registry under the "EAP-AKA and EAP-SIM
Parameters" group. Parameters" group.
Also, a new registry "EAP-AKA' AT_KDF_FS Key Derivation Function Also, IANA is requested to create a new registry "EAP-AKA' AT_KDF_FS
Values" should be created to represent FS Key Derivation Function Key Derivation Function Values" to represent FS Key Derivation
types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA' with ECDHE Function types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA'
and P-256" types (1 and 2, see Section 6.3) need to be assigned, with ECDHE and P-256" types (1 and 2, see Section 6.3) need to be
along with one reserved value. The initial contents of this registry assigned, along with one reserved value. The initial contents of
is illustrated in Table 1; new values can be created through the this registry is illustrated in Table 1; new values can be created
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 | [TBD BY IANA: THIS RFC] | | 1 | EAP-AKA' with | [TBD BY IANA: THIS RFC] |
| | ECDHE and X25519 | | | | ECDHE and X25519 | |
+---------+------------------+-------------------------+ +---------+------------------+-------------------------+
| 2 | EAP-AKA' with | [TBD BY IANA: THIS RFC] | | 2 | EAP-AKA' with | [TBD BY IANA: THIS RFC] |
skipping to change at page 27, line 24 skipping to change at page 28, line 11
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9048] Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen, [RFC9048] Arkko, J., Lehtovirta, V., Torvinen, V., and P. Eronen,
"Improved Extensible Authentication Protocol Method for "Improved Extensible Authentication Protocol Method for
3GPP Mobile Network Authentication and Key Agreement (EAP- 3GPP Mobile Network Authentication and Key Agreement (EAP-
AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021, AKA')", RFC 9048, DOI 10.17487/RFC9048, October 2021,
<https://www.rfc-editor.org/info/rfc9048>. <https://www.rfc-editor.org/info/rfc9048>.
[FIPS186-4] [SP-800-186]
NIST, "Digital Signature Standard (DSS)", FIPS 186-4, July NIST, "Recommendations for Discrete Logarithm-based
2013, <https://doi.org/10.6028/NIST.FIPS.186-4>. Cryptography: Elliptic Curve Domain Parameters",
NIST Special Publication 800-186, February 2023,
<https://doi.org/10.6028/NIST.SP.800-186>.
[SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography", [SEC1] Certicom Research, "SEC 1: Elliptic Curve Cryptography",
Standards for Efficient Cryptography 1 (SEC 1) Version Standards for Efficient Cryptography 1 (SEC 1) Version
2.0, May 2009, <https://www.secg.org/sec1-v2.pdf>. 2.0, May 2009, <https://www.secg.org/sec1-v2.pdf>.
[SEC2] Certicom Research, "SEC 2: Recommended Elliptic Curve [SEC2] Certicom Research, "SEC 2: Recommended Elliptic Curve
Domain Parameters", Standards for Efficient Cryptography 2 Domain Parameters", Standards for Efficient Cryptography 2
(SEC 2) Version 2.0, January 2010, (SEC 2) Version 2.0, January 2010,
<https://www.secg.org/sec2-v2.pdf>. <https://www.secg.org/sec2-v2.pdf>.
skipping to change at page 28, line 43 skipping to change at page 29, line 30
2015, 2015,
<https://theintercept.com/2015/02/19/great-sim-heist/>. <https://theintercept.com/2015/02/19/great-sim-heist/>.
[DOW1992] Diffie, W., Van Oorschot, P., and M. Wiener, [DOW1992] Diffie, W., Van Oorschot, P., and M. Wiener,
"Authentication and Authenticated Key Exchanges", Designs, "Authentication and Authenticated Key Exchanges", Designs,
Codes and Cryptography 2 pp. 107-125, June 1992, Codes and Cryptography 2 pp. 107-125, June 1992,
<https://doi.org/10.1007/BF00124891>. <https://doi.org/10.1007/BF00124891>.
[TS.33.501] [TS.33.501]
3GPP, "Security architecture and procedures for 5G 3GPP, "Security architecture and procedures for 5G
System", 3GPP TS 33.501 18.0.0, December 2022. System", 3GPP TS 33.501 18.1.0, March 2023.
[NIST-ZT] National Institute of Standards and Technology,
"Implementing a Zero Trust Architecture", December 2022,
<https://www.nccoe.nist.gov/sites/default/files/2022-12/
zta-nist-sp-1800-35b-preliminary-draft-2.pdf>.
[NSA-ZT] National Security Agency, "Embracing a Zero Trust Security
Model", February 2021, <https://media.defense.gov/2021/
Feb/25/2002588479/-1/-1/0/
CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF>.
Appendix A. Change Log Appendix A. Change Log
RFC Editor: Please remove this appendix. RFC Editor: Please remove this appendix.
The -11 version of the WG draft has the following changes:
* Addressed IETF Last Call comments from directorates, Security AD,
Meiling Cheng, and a detailed review from the author Karl. In
particular:
* Replaced the reference to the deprecated FIPS 186-4 with SP
800-186.
* Changed HSS to Authentication Database (AD) as HSS is a 4G term.
* Explained difference between EAP-AKA and EAP-AKA'
* Explained that the emphemeral key exhange provide more that
forward secrecy and how this is important to mitigate pervasive
monitoring.
* Included links for the zero trust principles.
* Explained why K_encr and K_auth not being protected by the ECDHE
addition.
* Added that a future introduction of KEM might require additional
changes.
* Explained how ephemeral key exchange is linked to pervasive
monitoring.
* Changed SIM to USIM everywhere. A USIM is required for AKA.
* Changed to long-term key instead of long-term secret or long-term
shared secret.
* Reference updates.
* Various editorial improvements.
The -10 version of the WG draft has the following changes: The -10 version of the WG draft has the following changes:
* Various nits found by Peter Yee. * Various nits found by Peter Yee.
The -09 version of the WG draft has the following changes: The -09 version of the WG draft has the following changes:
* Scalable Vector Graphics (SVG) versions for all figures has been * Scalable Vector Graphics (SVG) versions for all figures has been
added and the figures has been slightly modified to render nicely added and the figures has been slightly modified to render nicely
with aasvg. with aasvg.
skipping to change at page 29, line 41 skipping to change at page 31, line 29
encryption requirements. encryption requirements.
* The interaction between AT_KDF and AT_KDF_FS has been specified * The interaction between AT_KDF and AT_KDF_FS has been specified
more clearly, including specifying how future specifications need more clearly, including specifying how future specifications need
to specify the treatment of new combinations. to specify the treatment of new combinations.
* Addition of a discussion about the impacts of potential future * Addition of a discussion about the impacts of potential future
quantum computing attacks with specific impacts to this extension. quantum computing attacks with specific impacts to this extension.
* Addition of a discussion about metadata/unprotected data in * Addition of a discussion about metadata/unprotected data in
Section 7.4. Section 7.5.
* Reference updates. * Reference updates.
* Various editorial improvements. * 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:
* The impact of forward secrecy explanation has been improved in the * The impact of forward secrecy explanation has been improved in the
abstract and security considerations. abstract and security considerations.
skipping to change at page 30, line 38 skipping to change at page 32, line 25
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 document now suggests an alternate
alternate group/curve as an optional one besides X25519. The group/curve as an optional one besides X25519. The specific choice
specific choice of particular groups and algorithms is still up to 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, [RFC9048]), changed the wording of the recommendation with successor, [RFC9048]), changed the wording of the recommendation with
regards to the use of this extension, clarified the references to the regards to the use of this extension, clarified the references to the
definition of X25519 and Curve25519, clarified the distinction to definition of X25519 and Curve25519, clarified the distinction to
ECDH methods that use partially static keys, and simplified the use ECDH methods that use partially static keys, and simplified the use
of AKA and SIM card terminology. Some editorial changes were also of AKA and USIM card terminology. Some editorial 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.
skipping to change at page 31, line 34 skipping to change at page 33, line 18
Acknowledgments Acknowledgments
The authors would like to note that the technical solution in this The authors would like to note that the technical solution in this
document came out of the TrustCom paper [TrustCom2015], whose authors document came out of the TrustCom paper [TrustCom2015], whose authors
were J. Arkko, K. Norrman, M. Näslund, and B. Sahlin. This document were J. Arkko, K. Norrman, M. Näslund, and B. Sahlin. This document
uses also a lot of material from [RFC4187] by J. Arkko and 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 Ben Campbell, Tim Evans, Zhang The authors would also like to thank Ben Campbell, Meiling Chen,
Fu, Russ Housley, Tero Kivinen, Eliot Lear, Vesa Lehtovirta, Kathleen Linda Dunbar, Tim Evans, Zhang Fu, Russ Housley, Tero Kivinen, Eliot
Moriarty, Prajwol Kumar Nakarmi, Anand R. Prasad, Michael Richardson, Lear, Vesa Lehtovirta, Kathleen Moriarty, Prajwol Kumar Nakarmi,
Göran Rune, Bengt Sahlin, Joseph Salowey, Mohit Sethi, Rene Struik, Anand R. Prasad, Michael Richardson, Göran Rune, Bengt Sahlin, Joseph
Sean Turner, Helena Vahidi Mazinani, and many other people at the Salowey, Mohit Sethi, Rene Struik, Vesa Torvinen, Sean Turner, Helena
Vahidi Mazinani, Paul Wouters, Bo Wu, and many other people at the
IETF, GSMA and 3GPP groups for interesting discussions in this IETF, GSMA and 3GPP groups for interesting discussions in this
problem space. problem space.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
FI-02420 Jorvas FI-02420 Jorvas
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
skipping to change at page 32, line 4 skipping to change at page 33, line 34
IETF, GSMA and 3GPP groups for interesting discussions in this IETF, GSMA and 3GPP groups for interesting discussions in this
problem space. problem space.
Authors' Addresses Authors' Addresses
Jari Arkko Jari Arkko
Ericsson Ericsson
FI-02420 Jorvas FI-02420 Jorvas
Finland Finland
Email: jari.arkko@piuha.net Email: jari.arkko@piuha.net
Karl Norrman Karl Norrman
Ericsson Ericsson
SE-16483 Stockholm SE-16483 Stockholm
Sweden Sweden
Email: karl.norrman@ericsson.com Email: karl.norrman@ericsson.com
Vesa Torvinen
Ericsson
FI-02420 Jorvas
Finland
Email: vesa.torvinen@ericsson.com
John Preuß Mattsson John Preuß Mattsson
Ericsson Ericsson
SE-164 40 Kista SE-164 40 Kista
Sweden Sweden
Email: john.mattsson@ericsson.com Email: john.mattsson@ericsson.com
 End of changes. 99 change blocks. 
387 lines changed or deleted 474 lines changed or added

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