rfc9678xml2.original.xml   rfc9678.xml 
<?xml version="1.0" encoding="utf-8" ?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<rfc ipr="trust200902" docName="draft-ietf-emu-aka-pfs-12"
category="std" updates="5448,9048" consensus="true">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<front>
<title abbrev="EAP-AKA' FS">Forward Secrecy for the
Extensible Authentication Protocol Method for Authentication and Key Agreement (
EAP-AKA' FS)</title>
<author initials="J" surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Jorvas</city> <code>02420</code>
<country>Finland</country>
</postal>
<email>jari.arkko@piuha.net</email>
</address>
</author>
<author initials="K" surname="Norrman" fullname="Karl Norrman">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Stockholm</city> <code>16483</code>
<country>Sweden</country>
</postal>
<email>karl.norrman@ericsson.com</email>
</address>
</author>
<author initials="J" surname="Preuß Mattsson" fullname="John Preuß Mattsson">
<organization>Ericsson</organization>
<address>
<postal>
<street/>
<city>Kista</city> <code>164 40</code>
<country>Sweden</country>
</postal>
<email>john.mattsson@ericsson.com</email>
</address>
</author>
<keyword>EAP</keyword> <!DOCTYPE rfc [
<keyword>AKA</keyword> <!ENTITY nbsp "&#160;">
<keyword>AKA'</keyword> <!ENTITY zwsp "&#8203;">
<keyword>EAP-AKA'</keyword> <!ENTITY nbhy "&#8209;">
<keyword>EAP-AKA' FS</keyword> <!ENTITY wj "&#8288;">
<keyword>3GPP</keyword> ]>
<abstract> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft -ietf-emu-aka-pfs-12" number="9678" category="std" updates="5448,9048" consensus ="true" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRe fs="true" sortRefs="true" version="3">
<t>This document updates RFC 9048, the improved Extensible <front>
Authentication Protocol Method for 3GPP Mobile Network Authentication <title abbrev="EAP-AKA' FS">Forward Secrecy Extension to the Improved Extens
and Key Agreement (EAP-AKA'), with an optional extension providing ephemeral k ible Authentication Protocol Method for Authentication and Key Agreement (EAP-AK
ey exchange. A' FS)</title>
Similarly, this document also updates the earlier version <seriesInfo name="RFC" value="9678"/>
of the EAP-AKA' specification in RFC 5448. The extension EAP-AKA' Forward Secr <author initials="J." surname="Arkko" fullname="Jari Arkko">
ecy (EAP-AKA' FS), when <organization>Ericsson</organization>
negotiated, provides forward secrecy for the session keys <address>
generated as a part of the authentication run in EAP-AKA'. This <postal>
prevents an attacker who has gained access to the long-term <city>Jorvas</city>
key from obtaining session keys established in the past, assuming <code>02420</code>
these have been properly deleted. In addition, EAP-AKA' FS mitigates <country>Finland</country>
passive attacks (e.g., large scale pervasive monitoring) </postal>
against future sessions. This forces attackers to use active attacks instead.< <email>jari.arkko@piuha.net</email>
/t> </address>
</author>
<author initials="K." surname="Norrman" fullname="Karl Norrman">
<organization>Ericsson</organization>
<address>
<postal>
<city>Stockholm</city>
<code>16483</code>
<country>Sweden</country>
</postal>
<email>karl.norrman@ericsson.com</email>
</address>
</author>
<author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson
">
<organization>Ericsson</organization>
<address>
<postal>
<city>Kista</city>
<code>164 40</code>
<country>Sweden</country>
</postal>
<email>john.mattsson@ericsson.com</email>
</address>
</author>
</abstract> <date month="December" year="2024"/>
</front> <area>SEC</area>
<middle> <workgroup>emu</workgroup>
<section anchor="sec:intro" title="Introduction"> <keyword>EAP</keyword>
<keyword>AKA</keyword>
<keyword>AKA'</keyword>
<keyword>EAP-AKA'</keyword>
<keyword>EAP-AKA' FS</keyword>
<keyword>3GPP</keyword>
<t>Many different attacks have been reported as part of revelations <abstract>
<t>This document updates RFC 9048, "Improved Extensible Authentication
Protocol Method for 3GPP Mobile Network Authentication and Key Agreement
(EAP-AKA')", and its predecessor RFC 5448 with an optional extension provi
ding ephemeral key
exchange. The extension EAP-AKA' Forward
Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the
session keys generated as a part of the authentication run in
EAP-AKA'. This prevents an attacker who has gained access to the
long-term key from obtaining session keys established in the past,
assuming these have been properly deleted. In addition, EAP-AKA' FS
mitigates passive attacks (e.g., large-scale pervasive monitoring)
against future sessions. This forces attackers to use active attacks
instead.</t>
</abstract>
</front>
<middle>
<section anchor="sec_intro" numbered="true" toc="default">
<name>Introduction</name>
<t>Many different attacks have been reported as part of the revelations
associated with pervasive surveillance. Some of the reported attacks associated with pervasive surveillance. Some of the reported attacks
involved compromising the Universal Subscriber Identity Module involved compromising the Universal Subscriber Identity Module
(USIM) card supply chain. Attacks revealing the AKA long-term key may occur fo (USIM) card supply chain. Attacks revealing the AKA long-term key may occur, f
r or
instance, during the manufacturing process of USIM cards, during the instance:</t>
transfer of the cards and associated information to <ul><li>during the manufacturing process of USIM cards,</li>
the operator, and when a system is running. Since <li>during the transfer of the cards and associated information to
the operator, and</li>
<li>when a system is running.</li></ul>
<t>Since
the publication of reports about such attacks the publication of reports about such attacks
<xref target="Heist2015"/>, manufacturing and provisioning (see <xref target="Heist2015" format="default"/>), manufacturing and provision ing
processes have gained much scrutiny and have improved.</t> processes have gained much scrutiny and have improved.</t>
<t>However, the danger of resourceful attackers attempting to gain
<t>However, the danger of resourceful attackers attempting to gain
information about long-term keys is still a concern because these keys are hig h-value targets. information about long-term keys is still a concern because these keys are hig h-value targets.
Note that Note that
the attacks are largely independent of the used authentication the attacks are largely independent of the used authentication
technology; the issue is not vulnerabilities in algorithms or technology; the issue is not vulnerabilities in algorithms or
protocols, but rather the possibility of someone gaining unauthorized protocols, but rather the possibility of someone gaining unauthorized
access to key material. Furthermore, an explicit goal of the IETF is to ensure access to key material. Furthermore, an explicit goal of the IETF is to ensure
that we understand the surveillance concerns related to IETF that we understand the surveillance concerns related to IETF
protocols and take appropriate countermeasures <xref target="RFC7258"/>.</t> protocols and take appropriate countermeasures <xref target="RFC7258" format="
default"/>.</t>
<t>While strong protection of manufacturing and other processes is <t>While strong protection of manufacturing and other processes is
essential in mitigating surveillance and other risks associated with essential in mitigating surveillance and other risks associated with
AKA long-term keys, there are also protocol mechanisms that can AKA long-term keys, there are also protocol mechanisms that can
help.</t> help.</t>
<t>This document updates <xref target="RFC9048" format="default"/>,
"Improved Extensible Authentication Protocol Method for 3GPP Mobile
Network Authentication and Key Agreement (EAP-AKA')", with an optional
extension providing ephemeral key exchange, which minimizes the impact of
long-term key compromise and strengthens the identity privacy
requirements. This is important, given the large number of users of AKA
in mobile networks.</t>
<t>This document updates <xref target="RFC9048"/>, the Improved 3GPP <t>The extension, when
Mobile Network Authentication and Key Agreement (EAP-AKA') method, negotiated, provides Forward Secrecy (FS) <xref target="DOW1992" format="defau
with an optional extension providing ephemeral key exchange lt"/> for the session key
minimizing the impact of long-term key compromise and strengthens
the identity privacy requirements. This is important, given the
large number of users of AKA in mobile networks.</t>
<t>The extension, when
negotiated, provides Forward Secrecy (FS) <xref target="DOW1992"/> for the ses
sion key
generated as a part of the authentication run in EAP-AKA'. This generated as a part of the authentication run in EAP-AKA'. This
prevents an attacker who has gained access to the long-term prevents an attacker who has gained access to the long-term
key in a USIM card from getting access to past session key in a USIM card from getting access to past session
keys. In addition to FS, the included Diffie-Hellman exchange, forces keys. In addition to FS, the included Diffie-Hellman exchange forces
attackers to be active if they want access to future session keys even attackers to be active if they want access to future session keys, even
if they have access to the long-term key. This is beneficial, because if they have access to the long-term key. This is beneficial because
active attacks demand much more resources to launch, and are easier to active attacks demand many more resources to launch and are easier to
detect. As detect. As
with other protocols, an active attacker with access to the with other protocols, an active attacker with access to the
long-term key material will of course be able to attack all future long-term key material will, of course, be able to attack all future
communications, but risks detection, particularly if done at communications, but risks detection, particularly if done at
scale.</t> scale.</t>
<t>It should also be noted that 5G network architecture <xref target="TS.3
<t>It should also be noted that 5G network architecture <xref target="TS.33.50 3.501" format="default"/>
1"/>
includes the includes the
use of the EAP framework for authentication. While any methods can use of the EAP framework for authentication. While any methods can
be run, the default authentication method within that context will be run, the default authentication method within that context will
be EAP-AKA'. As a result, improvements in EAP-AKA' security have a be EAP-AKA'. As a result, improvements in EAP-AKA' security have the
potential to improve security for many users.</t> potential to improve security for many users.</t>
</section>
</section> <section numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Requirements Language"> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and ",
"OPTIONAL" in this document are to be interpreted as described in BCP "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
</section> interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
<section title="Protocol Design and Deployment Objectives"> shown here.
</t>
<t>The extension specified here re-uses large portions of the </section>
<section numbered="true" toc="default">
<name>Protocol Design and Deployment Objectives</name>
<t>The extension specified here reuses large portions of the
current structure of 3GPP interfaces and functions, with the current structure of 3GPP interfaces and functions, with the
rationale that this will make the construction more easily adopted. rationale that this will make the construction more easily adopted.
In particular, the construction keeps the interface between the In particular, the construction keeps the interface between the
USIM and the mobile USIM and the mobile
terminal intact. As a consequence, there is no need to roll out new terminal intact. As a consequence, there is no need to roll out new
credentials to existing subscribers. The work is based on an earlier credentials to existing subscribers. The work is based on an earlier
paper <xref target="TrustCom2015"/>, and uses much of the same paper (see <xref target="TrustCom2015" format="default"/>) and uses much of th
material, but applied to EAP rather than the underlying AKA e same
material but is applied to EAP rather than the underlying AKA
method.</t> method.</t>
<t>It has been a goal to implement this change as an extension <t>It has been a goal to implement this change as an extension
of the widely supported EAP-AKA' method, rather than a completely new of the widely supported EAP-AKA' method, rather than implement a completely ne w
authentication method. The extension is implemented as a set of authentication method. The extension is implemented as a set of
new, optional attributes, that are provided alongside the new, optional attributes that are provided alongside the
base attributes in EAP-AKA'. Old implementations can ignore base attributes in EAP-AKA'. Old implementations can ignore
these attributes, but their presence will nevertheless be verified these attributes, but their presence will nevertheless be verified
as part of base EAP-AKA' integrity verification process, helping as part of the base EAP-AKA' integrity verification process, helping
protect against bidding down attacks. This extension does protect against bidding down attacks. This extension does
not increase the number of rounds necessary to complete the not increase the number of rounds necessary to complete the
protocol.</t> protocol.</t>
<t>The use of this extension is at the discretion of the
<t>The use of this extension is at the discretion of the
authenticating parties. It should be noted that FS and defenses authenticating parties. It should be noted that FS and defenses
against passive attacks do not solve all problems, but they can against passive attacks do not solve all problems, but they can
provide a partial defense that increases the cost and risk provide a partial defense that increases the cost and risk
associated with pervasive surveillance.</t> associated with pervasive surveillance.</t>
<t>While adding FS to the existing mobile
<t>While adding forward secrecy to the existing mobile
network infrastructure can be done in multiple different ways, this network infrastructure can be done in multiple different ways, this
document specifies a solution that is relatively easily document specifies a solution that is relatively easy to deploy. In particular
deployable. In particular: :
<list style="symbols"> </t>
<ul spacing="normal">
<t>As noted above, no new credentials are needed; there is no <li>As noted above, no new credentials are needed; there is no change
change to USIM cards.</t> to USIM cards.</li>
<li>FS property can be incorporated into any current or future system
<t>FS property can be incorporated into any current or future that supports EAP, without changing any network functions beyond the
system that supports EAP, without changing EAP endpoints.</li>
any network functions beyond the EAP endpoints.</t> <li>Key generation happens at the endpoints, enabling the highest grade
key material to be used both by the endpoints and the intermediate
<t>Key generation happens at the endpoints, enabling highest grade systems (such as access points that are given access to specific
key material to be used both by the endpoints and the intermediate keys).</li>
systems (such as access points that are given access to specific <li>While EAP-AKA' is just one EAP method, for practical purposes,
keys).</t> FS being available for both EAP-TLS <xref
target="RFC5216" format="default"/> <xref target="RFC9190"
<t>While EAP-AKA' is just one EAP method, for practical purposes format="default"/> and EAP-AKA' ensures that, for many practical
forward secrecy being available for both EAP-TLS <xref systems, FS can be enabled for either all or a significant
target="RFC5216"/> <xref target="RFC9190"/> and fraction of users.</li>
EAP-AKA' ensures that for many practical systems forward </ul>
secrecy can be enabled for either all or significant fraction of </section>
users.</t> <section numbered="true" toc="default">
<name>Background</name>
</list></t> <t>The reader is assumed to
have a basic understanding of the EAP framework <xref target="RFC3748" forma
</section> t="default"/>.</t>
<section numbered="true" toc="default">
<section title="Background"> <name>AKA</name>
<t>The reader is assumed to <t>We use the term "Authentication and Key Agreement" (or "AKA") for the
have basic understanding of the EAP framework <xref target="RFC3748"/>.</t>
<section title="AKA">
<t>We use the term Authentication and Key Agreement (AKA) for the
main authentication and key agreement protocol used by 3GPP mobile main authentication and key agreement protocol used by 3GPP mobile
networks from the third generation (3G) and onward. Later networks from the third generation (3G) and onward. Later
generations adds new features to AKA, but the core remains the generations add new features to AKA, but the core remains the
same. It is based on challenge-response mechanisms and symmetric same. It is based on challenge-response mechanisms and symmetric
cryptography. In contrast to its earlier GSM counterparts, AKA cryptography. In contrast to its earlier GSM counterparts, AKA
provides long key lengths and mutual authentication. The phone provides long key lengths and mutual authentication. The phone
typically executes AKA in a USIM. USIM is technically just an typically executes AKA in a USIM. A USIM is technically just an
application that can reside on a removable UICC (Universal application that can reside on a removable Universal
Integrated Circuit Card), an embedded UICC, or integrated in a Integrated Circuit Card (UICC), an embedded UICC, or integrated in a
Trusted Execution Environment (TEE). In this document we use the Trusted Execution Environment (TEE). In this document, we use the
term "USIM card" to refer to any Subscriber Identity Module term "USIM card" to refer to any Subscriber Identity Module (SIM)
capable of running AKA.</t> capable of running AKA.</t>
<t>The goal of AKA is to mutually authenticate the USIM and the so-called <t>The goal of AKA is to mutually authenticate the USIM and the
home environment, which is the authentication server in the subscribers so-called home environment, which is the authentication Server in the
home operator's network.</t> subscriber's home operator's network.</t>
<t>AKA works in the following manner:
<list style="symbols">
<t>The USIM and the home environment have agreed on a
long-term symmetric key beforehand.</t>
<t>The actual authentication process starts by having the home
environment produce an authentication vector, based on the long-term
key and a sequence number. The authentication vector contains a
random part RAND, an authenticator part AUTN used for
authenticating the network to the USIM, an expected
result part XRES, a 128-bit session key for integrity check IK,
and a 128-bit session key for encryption CK.</t>
<t>The authentication vector is passed to the serving network, which
uses it to authenticate the device.</t>
<t>The RAND and the AUTN are delivered to the USIM.</t>
<t>The USIM verifies the AUTN, again based on the long-term
key and the sequence number. If this process is successful (the
AUTN is valid and the sequence number used to generate AUTN is
within the correct range), the USIM produces an
authentication result RES and sends it to the serving network.</t>
<t>The serving network verifies that the result from the USIM
matches the expected value in the authentication vector.
If it does, the USIM is considered authenticated,
and IK and CK can be used to
protect further communications between the USIM and the
home environment.</t>
</list></t>
</section>
<section title="EAP-AKA' Protocol">
<t>When AKA is embedded into EAP, the authentication processing on <t>AKA works in the following manner:</t>
the network side is moved to the home environment. The 3GPP authentication <ul spacing="normal">
database (AD) generates authentication vectors. The 3GPP authentication <li>The USIM and the home environment have agreed on a long-term
server takes the role of EAP server. The USIM combined with symmetric key beforehand.</li>
the mobile phone takes the role of the client. <li>The actual authentication process starts by having the home
The difference between EAP-AKA <xref target="RFC4187"/> and environment produce an authentication vector, based on the long-term
EAP-AKA' <xref target="RFC9048"/> is that EAP-AKA' key and a sequence number. The authentication vector contains a
binds the derived keys to the name of access network. random part RAND, an authenticator part AUTN used for authenticating
<xref target="figaka"/> describes the basic flow in the EAP-AKA' the network to the USIM, an expected result part XRES, a 128-bit
session key for the integrity check IK, and a 128-bit session key for
the
encryption CK.</li>
<li>The authentication vector is passed to the serving network,
which uses it to authenticate the device.</li>
<li>The RAND and the AUTN are delivered to the USIM.</li>
<li>The USIM verifies the AUTN, again based on the long-term key and
the sequence number. If this process is successful (the AUTN is
valid and the sequence number used to generate the AUTN is within the
correct range), the USIM produces an authentication result RES and
sends it to the serving network.</li>
<li>The serving network verifies that the result from the USIM
matches the expected value in the authentication vector. If it
does, the USIM is considered authenticated, and the IK and CK can be
used to protect further communications between the USIM and the home
environment.</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>EAP-AKA' Protocol</name>
<t>When AKA is embedded into EAP, the authentication processing on
the network side is moved to the home environment. The 3GPP Authentication
Database (AD) generates authentication vectors. The 3GPP authentication
Server takes the role of EAP Server. The USIM combined with
the mobile phone takes the role of client.
The difference between EAP-AKA <xref target="RFC4187" format="default"/> and
EAP-AKA' <xref target="RFC9048" format="default"/> is that EAP-AKA'
binds the derived keys to the name of the access network.
<xref target="figaka" format="default"/> describes the basic flow in the EAP
-AKA'
authentication process. The definition of the full protocol authentication process. The definition of the full protocol
behavior, along with the definition of attributes AT_RAND, behavior, along with the definition of the attributes AT_RAND,
AT_AUTN, AT_MAC, and AT_RES can be found in <xref AT_AUTN, AT_MAC, and AT_RES can be found in <xref target="RFC9048" format="d
target="RFC9048"/> and <xref target="RFC4187"/>. efault"/> and <xref target="RFC4187" format="default"/>.
Note the use of EAP-terminology from hereon. That is, the 3GPP Note the use of EAP terminology from hereon. That is, the 3GPP
serving network takes on the role of an EAP access network. serving network takes on the role of an EAP access network.
</t> </t>
<figure anchor="figaka">
<figure title="EAP-AKA' Authentication Process" anchor="figaka"> <name>EAP-AKA' Authentication Process</name>
<artset> <artset>
<artwork type="ascii-art"><![CDATA[ <artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
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 | | | The 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 EAP-AKA' |
| | generating RAND and AUTN, derives session keys from | | | algorithms generating RAND and AUTN, and derives session |
| | CK' and IK'. RAND and AUTN are sent as AT_RAND and | | | keys from CK' and IK'. RAND and AUTN are sent as |
| | AT_AUTN attributes, whereas the network name is | | | AT_RAND and AT_AUTN attributes, whereas the network name |
| | transported in the AT_KDF_INPUT attribute. AT_KDF | | | is 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 to create 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 they do not | | | are compared for discrepancies, and if they do not | |
| match, the authentication is aborted. Otherwise, the | | | match, the authentication is aborted. Otherwise, the | |
| network name from AT_KDF_INPUT attribute is used in | | | network name from the AT_KDF_INPUT attribute is used | |
| running the AKA' algorithms, verifying AUTN from | | | in running the EAP-AKA' algorithms, verifying AUTN from | |
| AT_AUTN and MAC from AT_MAC attributes. The peer then | | | AT_AUTN and Message Authentication Code (MAC) from the | |
| generates RES. The peer also derives session keys from | | | AT_MAC attributes. The Peer then generates RES. The | |
| CK'/IK'. The AT_RES and AT_MAC attributes are | | | Peer also derives session keys from CK'/IK. The AT_RES | |
| constructed. | | | 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 | | | The 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 |
| | compared values match, respectively. | | | both compared values match, respectively. |
| +-----------------------------------------------------+--+ | +-----------------------------------------------------+--+
| | | |
| EAP-Success | | EAP-Success |
|<-----------------------------------------------------------+ |<-----------------------------------------------------------+
| | | |
]]></artwork> ]]></artwork>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1
.1" height="832" width="552" viewBox="0 0 552 832" class="diagram" text-anchor="
middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<path d="M 8,400 L 8,608" fill="none" stroke="black"/>
<path d="M 32,48 L 32,400" fill="none" stroke="black"/>
<path d="M 32,608 L 32,816" fill="none" stroke="black"/>
<path d="M 88,160 L 88,320" fill="none" stroke="black"/>
<path d="M 88,688 L 88,752" fill="none" stroke="black"/>
<path d="M 464,400 L 464,608" fill="none" stroke="black"/>
<path d="M 520,48 L 520,160" fill="none" stroke="black"/>
<path d="M 520,320 L 520,688" fill="none" stroke="black"/>
<path d="M 520,752 L 520,816" fill="none" stroke="black"/>
<path d="M 544,160 L 544,320" fill="none" stroke="black"/>
<path d="M 544,688 L 544,752" fill="none" stroke="black"/>
<path d="M 40,80 L 520,80" fill="none" stroke="black"/>
<path d="M 32,144 L 512,144" fill="none" stroke="black"/>
<path d="M 88,160 L 544,160" fill="none" stroke="black"/>
<path d="M 88,320 L 544,320" fill="none" stroke="black"/>
<path d="M 40,384 L 520,384" fill="none" stroke="black"/>
<path d="M 8,400 L 464,400" fill="none" stroke="black"/>
<path d="M 8,608 L 464,608" fill="none" stroke="black"/>
<path d="M 32,672 L 512,672" fill="none" stroke="black"/>
<path d="M 88,688 L 544,688" fill="none" stroke="black"/>
<path d="M 88,752 L 544,752" fill="none" stroke="black"/>
<path d="M 40,800 L 520,800" fill="none" stroke="black"/>
<path d="M 144,640 L 144,640" fill="none" stroke="black"/>
<polygon class="arrowhead" points="520,672 508,666.4 508,677.6" fi
ll="black" transform="rotate(0,512,672)"/>
<polygon class="arrowhead" points="520,144 508,138.4 508,149.6" fi
ll="black" transform="rotate(0,512,144)"/>
<polygon class="arrowhead" points="48,800 36,794.4 36,805.6" fill=
"black" transform="rotate(180,40,800)"/>
<polygon class="arrowhead" points="48,384 36,378.4 36,389.6" fill=
"black" transform="rotate(180,40,384)"/>
<polygon class="arrowhead" points="48,80 36,74.4 36,85.6" fill="bl
ack" transform="rotate(180,40,80)"/>
<g class="text">
<text x="28" y="36">Peer</text>
<text x="516" y="36">Server</text>
<text x="428" y="68">EAP-Request/Identity</text>
<text x="128" y="116">EAP-Response/Identity</text>
<text x="80" y="132">(Includes</text>
<text x="148" y="132">user's</text>
<text x="208" y="132">Network</text>
<text x="268" y="132">Access</text>
<text x="344" y="132">Identifier,</text>
<text x="412" y="132">NAI)</text>
<text x="124" y="180">Server</text>
<text x="196" y="180">determines</text>
<text x="256" y="180">the</text>
<text x="304" y="180">network</text>
<text x="356" y="180">name</text>
<text x="392" y="180">and</text>
<text x="440" y="180">ensures</text>
<text x="492" y="180">that</text>
<text x="112" y="196">the</text>
<text x="152" y="196">given</text>
<text x="204" y="196">access</text>
<text x="264" y="196">network</text>
<text x="308" y="196">is</text>
<text x="364" y="196">authorized</text>
<text x="420" y="196">to</text>
<text x="448" y="196">use</text>
<text x="480" y="196">the</text>
<text x="128" y="212">claimed</text>
<text x="184" y="212">name.</text>
<text x="224" y="212">The</text>
<text x="268" y="212">server</text>
<text x="316" y="212">then</text>
<text x="356" y="212">runs</text>
<text x="392" y="212">the</text>
<text x="428" y="212">AKA'</text>
<text x="492" y="212">algorithms</text>
<text x="140" y="228">generating</text>
<text x="204" y="228">RAND</text>
<text x="240" y="228">and</text>
<text x="280" y="228">AUTN,</text>
<text x="336" y="228">derives</text>
<text x="400" y="228">session</text>
<text x="452" y="228">keys</text>
<text x="492" y="228">from</text>
<text x="112" y="244">CK'</text>
<text x="144" y="244">and</text>
<text x="180" y="244">IK'.</text>
<text x="220" y="244">RAND</text>
<text x="256" y="244">and</text>
<text x="292" y="244">AUTN</text>
<text x="328" y="244">are</text>
<text x="364" y="244">sent</text>
<text x="396" y="244">as</text>
<text x="440" y="244">AT_RAND</text>
<text x="488" y="244">and</text>
<text x="128" y="260">AT_AUTN</text>
<text x="208" y="260">attributes,</text>
<text x="288" y="260">whereas</text>
<text x="336" y="260">the</text>
<text x="384" y="260">network</text>
<text x="436" y="260">name</text>
<text x="468" y="260">is</text>
<text x="144" y="276">transported</text>
<text x="204" y="276">in</text>
<text x="232" y="276">the</text>
<text x="300" y="276">AT_KDF_INPUT</text>
<text x="396" y="276">attribute.</text>
<text x="468" y="276">AT_KDF</text>
<text x="128" y="292">signals</text>
<text x="176" y="292">the</text>
<text x="212" y="292">used</text>
<text x="248" y="292">key</text>
<text x="308" y="292">derivation</text>
<text x="392" y="292">function.</text>
<text x="448" y="292">The</text>
<text x="496" y="292">session</text>
<text x="116" y="308">keys</text>
<text x="152" y="308">are</text>
<text x="188" y="308">used</text>
<text x="220" y="308">to</text>
<text x="260" y="308">create</text>
<text x="304" y="308">the</text>
<text x="348" y="308">AT_MAC</text>
<text x="420" y="308">attribute.</text>
<text x="404" y="356">EAP-Request/AKA'-Challenge</text>
<text x="160" y="372">(AT_RAND,</text>
<text x="236" y="372">AT_AUTN,</text>
<text x="304" y="372">AT_KDF,</text>
<text x="392" y="372">AT_KDF_INPUT,</text>
<text x="480" y="372">AT_MAC)</text>
<text x="32" y="420">The</text>
<text x="68" y="420">peer</text>
<text x="132" y="420">determines</text>
<text x="196" y="420">what</text>
<text x="232" y="420">the</text>
<text x="280" y="420">network</text>
<text x="332" y="420">name</text>
<text x="380" y="420">should</text>
<text x="424" y="420">be,</text>
<text x="40" y="436">based</text>
<text x="80" y="436">on,</text>
<text x="120" y="436">e.g.,</text>
<text x="164" y="436">what</text>
<text x="212" y="436">access</text>
<text x="284" y="436">technology</text>
<text x="340" y="436">it</text>
<text x="364" y="436">is</text>
<text x="404" y="436">using.</text>
<text x="32" y="452">The</text>
<text x="68" y="452">peer</text>
<text x="108" y="452">also</text>
<text x="168" y="452">retrieves</text>
<text x="224" y="452">the</text>
<text x="272" y="452">network</text>
<text x="324" y="452">name</text>
<text x="364" y="452">sent</text>
<text x="396" y="452">by</text>
<text x="424" y="452">the</text>
<text x="48" y="468">network</text>
<text x="100" y="468">from</text>
<text x="136" y="468">the</text>
<text x="204" y="468">AT_KDF_INPUT</text>
<text x="300" y="468">attribute.</text>
<text x="360" y="468">The</text>
<text x="392" y="468">two</text>
<text x="432" y="468">names</text>
<text x="32" y="484">are</text>
<text x="84" y="484">compared</text>
<text x="136" y="484">for</text>
<text x="212" y="484">discrepancies,</text>
<text x="288" y="484">and</text>
<text x="316" y="484">if</text>
<text x="348" y="484">they</text>
<text x="380" y="484">do</text>
<text x="408" y="484">not</text>
<text x="44" y="500">match,</text>
<text x="88" y="500">the</text>
<text x="164" y="500">authentication</text>
<text x="236" y="500">is</text>
<text x="284" y="500">aborted.</text>
<text x="364" y="500">Otherwise,</text>
<text x="424" y="500">the</text>
<text x="48" y="516">network</text>
<text x="100" y="516">name</text>
<text x="140" y="516">from</text>
<text x="212" y="516">AT_KDF_INPUT</text>
<text x="304" y="516">attribute</text>
<text x="356" y="516">is</text>
<text x="388" y="516">used</text>
<text x="420" y="516">in</text>
<text x="48" y="532">running</text>
<text x="96" y="532">the</text>
<text x="132" y="532">AKA'</text>
<text x="200" y="532">algorithms,</text>
<text x="288" y="532">verifying</text>
<text x="348" y="532">AUTN</text>
<text x="388" y="532">from</text>
<text x="48" y="548">AT_AUTN</text>
<text x="96" y="548">and</text>
<text x="128" y="548">MAC</text>
<text x="164" y="548">from</text>
<text x="212" y="548">AT_MAC</text>
<text x="288" y="548">attributes.</text>
<text x="352" y="548">The</text>
<text x="388" y="548">peer</text>
<text x="428" y="548">then</text>
<text x="56" y="564">generates</text>
<text x="116" y="564">RES.</text>
<text x="152" y="564">The</text>
<text x="188" y="564">peer</text>
<text x="228" y="564">also</text>
<text x="280" y="564">derives</text>
<text x="344" y="564">session</text>
<text x="396" y="564">keys</text>
<text x="436" y="564">from</text>
<text x="52" y="580">CK'/IK'.</text>
<text x="104" y="580">The</text>
<text x="148" y="580">AT_RES</text>
<text x="192" y="580">and</text>
<text x="236" y="580">AT_MAC</text>
<text x="308" y="580">attributes</text>
<text x="368" y="580">are</text>
<text x="68" y="596">constructed.</text>
<text x="92" y="644">EAP-Response</text>
<text x="204" y="644">AKA'-Challenge</text>
<text x="76" y="660">(AT_RES,</text>
<text x="144" y="660">AT_MAC)</text>
<text x="124" y="708">Server</text>
<text x="180" y="708">checks</text>
<text x="224" y="708">the</text>
<text x="256" y="708">RES</text>
<text x="288" y="708">and</text>
<text x="320" y="708">MAC</text>
<text x="364" y="708">values</text>
<text x="428" y="708">received</text>
<text x="476" y="708">in</text>
<text x="124" y="724">AT_RES</text>
<text x="168" y="724">and</text>
<text x="216" y="724">AT_MAC,</text>
<text x="304" y="724">respectively.</text>
<text x="392" y="724">Success</text>
<text x="460" y="724">requires</text>
<text x="516" y="724">both</text>
<text x="132" y="740">compared</text>
<text x="196" y="740">values</text>
<text x="252" y="740">match,</text>
<text x="336" y="740">respectively.</text>
<text x="464" y="788">EAP-Success</text>
</g>
</svg>
</artwork>
</artset>
</figure>
</section>
<section anchor="attacks" title="Attacks Against Long-Term Keys in Smart Cards
">
<t>The general security properties and potential
vulnerabilities of AKA and EAP-AKA' are discussed in <xref
target="RFC9048"/>.</t>
<t>An important question in that discussion relates to the
potential compromise of long-term keys, as discussed earlier.
Attacks on long-term keys are not specific to
AKA or EAP-AKA', and all security systems fail at least to some
extent if key material is stolen. However, it would be preferable
to retain some security even in
the face of such attacks. This document specifies a mechanism
that reduces risks to compromise of key material belonging to
previous sessions, before the long-term keys were compromised. It
also forces attackers to be active even after the compromise.</t>
</section> <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/20
00/svg" version="1.1" height="832" width="552" viewBox="0 0 552 832" class="diag
</section> ram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-lineca
p="round">
<section title="Protocol Overview">
<t>Forward secrecy for EAP-AKA' is achieved by using an Elliptic
Curve Diffie-Hellman (ECDH) exchange <xref target="RFC7748"/>. To provide
FS, the exchange must be run in an ephemeral manner, i.e.,
both sides generate temporary keys according to the negotiated ciphersuite,
e.g., for X25519 this is done as specified in <xref target="RFC7748"/>.
This method is referred to as ECDHE, where the last 'E' stands
for Ephemeral. The two initially registered elliptic curves and their
wire formats are chosen to align with the elliptic curves and formats
specified for Subscription Concealed Identifier (SUCI) encryption in
Appendix C.3.4 of 3GPP TS 33.501 <xref target="TS.33.501"/>.</t>
<t>The enhancements in the EAP-AKA' FS protocol are compatible <path d="M 8,400 L 8,608" fill="none" stroke="black"/>
<path d="M 32,48 L 32,400" fill="none" stroke="black"/>
<path d="M 32,608 L 32,816" fill="none" stroke="black"/>
<path d="M 88,160 L 88,320" fill="none" stroke="black"/>
<path d="M 88,688 L 88,752" fill="none" stroke="black"/>
<path d="M 464,400 L 464,608" fill="none" stroke="black"/>
<path d="M 520,48 L 520,160" fill="none" stroke="black"/>
<path d="M 520,320 L 520,688" fill="none" stroke="black"/>
<path d="M 520,752 L 520,816" fill="none" stroke="black"/>
<path d="M 544,160 L 544,320" fill="none" stroke="black"/>
<path d="M 544,688 L 544,752" fill="none" stroke="black"/>
<path d="M 40,80 L 520,80" fill="none" stroke="black"/>
<path d="M 32,144 L 512,144" fill="none" stroke="black"/>
<path d="M 88,160 L 544,160" fill="none" stroke="black"/>
<path d="M 88,320 L 544,320" fill="none" stroke="black"/>
<path d="M 40,384 L 520,384" fill="none" stroke="black"/>
<path d="M 8,400 L 464,400" fill="none" stroke="black"/>
<path d="M 8,608 L 464,608" fill="none" stroke="black"/>
<path d="M 32,672 L 512,672" fill="none" stroke="black"/>
<path d="M 88,688 L 544,688" fill="none" stroke="black"/>
<path d="M 88,752 L 544,752" fill="none" stroke="black"/>
<path d="M 40,800 L 520,800" fill="none" stroke="black"/>
<path d="M 144,640 L 144,640" fill="none" stroke="black"/>
<polygon class="arrowhead" points="520,672 508,666.4 508,677.6"
fill="black" transform="rotate(0,512,672)"/>
<polygon class="arrowhead" points="520,144 508,138.4 508,149.6"
fill="black" transform="rotate(0,512,144)"/>
<polygon class="arrowhead" points="48,800 36,794.4 36,805.6" fil
l="black" transform="rotate(180,40,800)"/>
<polygon class="arrowhead" points="48,384 36,378.4 36,389.6" fil
l="black" transform="rotate(180,40,384)"/>
<polygon class="arrowhead" points="48,80 36,74.4 36,85.6" fill="
black" transform="rotate(180,40,80)"/>
<g class="text">
<text x="28" y="36">Peer</text>
<text x="516" y="36">Server</text>
<text x="428" y="68">EAP-Request/Identity</text>
<text x="128" y="116">EAP-Response/Identity</text>
<text x="80" y="132">(Includes</text>
<text x="148" y="132">user's</text>
<text x="208" y="132">Network</text>
<text x="268" y="132">Access</text>
<text x="344" y="132">Identifier</text>
<text x="412" y="132">(NAI))</text>
<text x="124" y="180">Server</text>
<text x="196" y="180">determines</text>
<text x="256" y="180">the</text>
<text x="304" y="180">network</text>
<text x="356" y="180">name</text>
<text x="392" y="180">and</text>
<text x="440" y="180">ensures</text>
<text x="492" y="180">that</text>
<text x="112" y="196">the</text>
<text x="152" y="196">given</text>
<text x="204" y="196">access</text>
<text x="264" y="196">network</text>
<text x="308" y="196">is</text>
<text x="364" y="196">authorized</text>
<text x="420" y="196">to</text>
<text x="448" y="196">use</text>
<text x="480" y="196">the</text>
<text x="128" y="212">claimed</text>
<text x="184" y="212">name.</text>
<text x="224" y="212">The</text>
<text x="268" y="212">Server</text>
<text x="316" y="212">then</text>
<text x="356" y="212">runs</text>
<text x="392" y="212">the</text>
<text x="428" y="212">AKA'</text>
<text x="492" y="212">algorithms</text>
<text x="140" y="228">generating</text>
<text x="204" y="228">RAND</text>
<text x="240" y="228">and</text>
<text x="280" y="228">AUTN,</text>
<text x="336" y="228">derives</text>
<text x="400" y="228">session</text>
<text x="452" y="228">keys</text>
<text x="492" y="228">from</text>
<text x="112" y="244">CK'</text>
<text x="144" y="244">and</text>
<text x="180" y="244">IK'.</text>
<text x="220" y="244">RAND</text>
<text x="256" y="244">and</text>
<text x="292" y="244">AUTN</text>
<text x="328" y="244">are</text>
<text x="364" y="244">sent</text>
<text x="396" y="244">as</text>
<text x="440" y="244">AT_RAND</text>
<text x="488" y="244">and</text>
<text x="128" y="260">AT_AUTN</text>
<text x="208" y="260">attributes,</text>
<text x="288" y="260">whereas</text>
<text x="336" y="260">the</text>
<text x="384" y="260">network</text>
<text x="436" y="260">name</text>
<text x="468" y="260">is</text>
<text x="144" y="276">transported</text>
<text x="204" y="276">in</text>
<text x="232" y="276">the</text>
<text x="300" y="276">AT_KDF_INPUT</text>
<text x="396" y="276">attribute.</text>
<text x="468" y="276">AT_KDF</text>
<text x="128" y="292">signals</text>
<text x="176" y="292">the</text>
<text x="212" y="292">used</text>
<text x="248" y="292">key</text>
<text x="308" y="292">derivation</text>
<text x="392" y="292">function.</text>
<text x="448" y="292">The</text>
<text x="496" y="292">session</text>
<text x="116" y="308">keys</text>
<text x="152" y="308">are</text>
<text x="188" y="308">used</text>
<text x="220" y="308">to</text>
<text x="260" y="308">create</text>
<text x="304" y="308">the</text>
<text x="348" y="308">AT_MAC</text>
<text x="420" y="308">attribute.</text>
<text x="404" y="356">EAP-Request/AKA'-Challenge</text>
<text x="160" y="372">(AT_RAND,</text>
<text x="236" y="372">AT_AUTN,</text>
<text x="304" y="372">AT_KDF,</text>
<text x="392" y="372">AT_KDF_INPUT,</text>
<text x="480" y="372">AT_MAC)</text>
<text x="32" y="420">The</text>
<text x="68" y="420">Peer</text>
<text x="132" y="420">determines</text>
<text x="196" y="420">what</text>
<text x="232" y="420">the</text>
<text x="280" y="420">network</text>
<text x="332" y="420">name</text>
<text x="380" y="420">should</text>
<text x="424" y="420">be,</text>
<text x="40" y="436">based</text>
<text x="80" y="436">on,</text>
<text x="120" y="436">e.g.,</text>
<text x="164" y="436">what</text>
<text x="212" y="436">access</text>
<text x="284" y="436">technology</text>
<text x="340" y="436">it</text>
<text x="364" y="436">is</text>
<text x="404" y="436">using.</text>
<text x="32" y="452">The</text>
<text x="68" y="452">Peer</text>
<text x="108" y="452">also</text>
<text x="168" y="452">retrieves</text>
<text x="224" y="452">the</text>
<text x="272" y="452">network</text>
<text x="324" y="452">name</text>
<text x="364" y="452">sent</text>
<text x="396" y="452">by</text>
<text x="424" y="452">the</text>
<text x="48" y="468">network</text>
<text x="100" y="468">from</text>
<text x="136" y="468">the</text>
<text x="204" y="468">AT_KDF_INPUT</text>
<text x="300" y="468">attribute.</text>
<text x="360" y="468">The</text>
<text x="392" y="468">two</text>
<text x="432" y="468">names</text>
<text x="32" y="484">are</text>
<text x="84" y="484">compared</text>
<text x="136" y="484">for</text>
<text x="212" y="484">discrepancies,</text>
<text x="288" y="484">and</text>
<text x="316" y="484">if</text>
<text x="348" y="484">they</text>
<text x="380" y="484">do</text>
<text x="408" y="484">not</text>
<text x="44" y="500">match,</text>
<text x="88" y="500">the</text>
<text x="164" y="500">authentication</text>
<text x="236" y="500">is</text>
<text x="284" y="500">aborted.</text>
<text x="364" y="500">Otherwise,</text>
<text x="424" y="500">the</text>
<text x="48" y="516">network</text>
<text x="100" y="516">name</text>
<text x="140" y="516">from</text>
<text x="212" y="516">AT_KDF_INPUT</text>
<text x="304" y="516">attribute</text>
<text x="356" y="516">is</text>
<text x="388" y="516">used</text>
<text x="420" y="516">in</text>
<text x="48" y="532">running</text>
<text x="96" y="532">the</text>
<text x="132" y="532">AKA'</text>
<text x="200" y="532">algorithms,</text>
<text x="288" y="532">verifying</text>
<text x="348" y="532">AUTN</text>
<text x="388" y="532">from</text>
<text x="48" y="548">AT_AUTN</text>
<text x="96" y="548">and</text>
<text x="128" y="548">MAC</text>
<text x="164" y="548">from</text>
<text x="212" y="548">AT_MAC</text>
<text x="288" y="548">attributes.</text>
<text x="352" y="548">The</text>
<text x="388" y="548">Peer</text>
<text x="428" y="548">then</text>
<text x="56" y="564">generates</text>
<text x="116" y="564">RES.</text>
<text x="152" y="564">The</text>
<text x="188" y="564">Peer</text>
<text x="228" y="564">also</text>
<text x="280" y="564">derives</text>
<text x="344" y="564">session</text>
<text x="396" y="564">keys</text>
<text x="436" y="564">from</text>
<text x="52" y="580">CK'/IK'.</text>
<text x="104" y="580">The</text>
<text x="148" y="580">AT_RES</text>
<text x="192" y="580">and</text>
<text x="236" y="580">AT_MAC</text>
<text x="308" y="580">attributes</text>
<text x="368" y="580">are</text>
<text x="68" y="596">constructed.</text>
<text x="92" y="644">EAP-Response</text>
<text x="204" y="644">AKA'-Challenge</text>
<text x="76" y="660">(AT_RES,</text>
<text x="144" y="660">AT_MAC)</text>
<text x="124" y="708">Server</text>
<text x="180" y="708">checks</text>
<text x="224" y="708">the</text>
<text x="256" y="708">RES</text>
<text x="288" y="708">and</text>
<text x="320" y="708">MAC</text>
<text x="364" y="708">values</text>
<text x="428" y="708">received</text>
<text x="476" y="708">in</text>
<text x="124" y="724">AT_RES</text>
<text x="168" y="724">and</text>
<text x="216" y="724">AT_MAC,</text>
<text x="304" y="724">respectively.</text>
<text x="392" y="724">Success</text>
<text x="460" y="724">requires</text>
<text x="516" y="724">both</text>
<text x="132" y="740">compared</text>
<text x="196" y="740">values</text>
<text x="252" y="740">match,</text>
<text x="336" y="740">respectively.</text>
<text x="464" y="788">EAP-Success</text>
</g>
</svg>
</artwork>
</artset>
</figure>
</section>
<section anchor="attacks" numbered="true" toc="default">
<name>Attacks Against Long-Term Keys in Smart Cards</name>
<t>The general security properties and potential vulnerabilities of
AKA and EAP-AKA' are discussed in <xref target="RFC9048"
format="default"/>.</t>
<t>An important question in that discussion relates to the potential
compromise of long-term keys, as discussed earlier. Attacks on
long-term keys are not specific to AKA or EAP-AKA', and all security
systems fail, at least to some extent, if key material is
stolen. However, it would be preferable to retain some security even
in the face of such attacks. This document specifies a mechanism that
reduces the risks of compromising key material belonging to previous
sessions, before the long-term keys were compromised. It also forces
attackers to be active even after the compromise.</t>
</section>
</section>
<section numbered="true" toc="default">
<name>Protocol Overview</name>
<t>Forward Secrecy (FS) for EAP-AKA' is achieved by using an Elliptic
Curve Diffie-Hellman (ECDH) exchange <xref target="RFC7748"
format="default"/>. To provide FS, the exchange must be run in an
ephemeral manner, i.e., both sides generate temporary keys according to
the negotiated ciphersuite. For example, for X25519, this is done as
specified in <xref target="RFC7748" format="default"/>. This method is
referred to as "ECDHE", where the last "E" stands for "Ephemeral". The
two initially registered elliptic curves and their wire formats are
chosen to align with the elliptic curves and formats specified for
Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of
3GPP <xref target="TS.33.501" format="default"/>.</t>
<t>The enhancements in the EAP-AKA' FS protocol are compatible
with the signaling flow and other basic structures of both AKA and with the signaling flow and other basic structures of both AKA and
EAP-AKA'. The intent is to implement the enhancement as optional EAP-AKA'. The intent is to implement the enhancement as optional
attributes that legacy implementations ignore.</t> attributes that legacy implementations ignore.</t>
<t>The purpose of the protocol is to achieve mutual authentication <t>The purpose of the protocol is to achieve mutual authentication
between the EAP server and peer, and to establish keying material between the EAP Server and Peer and to establish key material
for secure communication between the two. This document specifies for secure communication between the two. This document specifies
the calculation of key material, providing new properties that are the calculation of key material, providing new properties that are
not present in key material provided by EAP-AKA' in its original not present in key material provided by EAP-AKA' in its original
form.</t> form.</t>
<t><xref target="figakafs"/> below describes the overall process. Since the go
al
has been to not require new infrastructure or credentials, the
flow diagrams also show the conceptual interaction with the USIM card
and 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 reader
is referred to the 3GPP specifications. For 5G this is
specified in 3GPP TS 33.501 <xref target="TS.33.501"/></t>
<figure title="EAP-AKA' FS Authentication Process" anchor="figakafs"> <t><xref target="figakafs" format="default"/> describes the overall
<artset> process. Since the goal has been to not require new infrastructure or
<artwork type="ascii-art"><![CDATA[ credentials, the flow diagrams also show the conceptual interaction with
the USIM card and the home environment. Recall that the home environment
represents the 3GPP Authentication Database (AD) and Server. The
details of those interactions are outside the scope of this document;
however, and the reader is referred to the 3GPP specifications (for 5G,
this is specified in 3GPP <xref target="TS.33.501"
format="default"/>).</t>
<figure anchor="figakafs">
<name>EAP-AKA' FS Authentication Process</name>
<artset>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
USIM Peer Server AD 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 | | | The Server now has an identity for the Peer. The Server |
| | then asks the help of AD to run AKA algorithms, | | | then asks the help of the AD to run EAP-AKA algorithms, |
| | generating RAND, AUTN, XRES, CK, IK. Typically, the | | | generating RAND, AUTN, XRES, CK, and IK. Typically, the |
| | AD performs the first part of key derivations so that | | | AD performs the first part of derivations so that the |
| | the authentication server gets the CK' and IK' keys | | | authentication Server gets the CK' and IK' keys already |
| | already tied to a particular network name. | | | tied to a particular network name. |
| +-------+----------------------------+----------------+--+ | +-------+----------------------------+----------------+----+
| | | | | | | |
| | | ID, key deriv. | | | | ID, key deriv. |
| | | function, | | | | function, |
| | | network name | | | | network name |
| | +--------------->| | | +--------------->|
| | | | | | | |
| | | RAND, AUTN, | | | | RAND, AUTN, |
| | | XRES, CK', IK' | | | | XRES, CK', IK' |
| | |<---------------+ | | |<---------------+
| +-------+----------------------------+----------------+--+ | +-------+----------------------------+----------------+----+
| | Server now has the needed authentication vector. It | | | The Server now has the needed authentication vector. It |
| | generates an ephemeral key pair, sends the public key | | | generates an ephemeral key pair, and sends the public |
| | of that key pair and the first EAP method message to | | | key of that key pair and the first EAP method message to |
| | the peer. In the message the AT_PUB_ECDHE attribute | | | the Peer. In the message the AT_PUB_ECDHE attribute |
| | carries the public key and the AT_KDF_FS attribute | | | carries the public key and the AT_KDF_FS attribute |
| | carries other FS-related parameters. Both of these are | | | carries other FS-related parameters. Both of these are |
| | skippable attributes that can be ignored if the peer | | | skippable attributes that can be ignored if the Peer |
| | does not support this extension. | | | does not support this extension. |
| +-------+----------------------------+----------------+--+ | +-------+----------------------------+----------------+----+
| | | | | | | |
| | EAP-Req/AKA'-Challenge | | | | EAP-Req/AKA'-Challenge | |
| | AT_RAND, AT_AUTN, AT_KDF, | | | | AT_RAND, AT_AUTN, AT_KDF, | |
| | AT_KDF_FS, AT_KDF_INPUT, | | | | AT_KDF_FS, AT_KDF_INPUT, | |
| | AT_PUB_ECDHE, AT_MAC | | | | AT_PUB_ECDHE, AT_MAC | |
| |<---------------------------+ | | |<---------------------------+ |
+--+--------------+----------------------------+---------+ | +--+--------------+----------------------------+---------+ |
| The peer checks if it wants to do the FS extension. If | | | The Peer checks if it wants to do the FS extension. | |
| yes, it will eventually respond with AT_PUB_ECDHE and | | | If yes, it will eventually respond with AT_PUB_ECDHE | |
| AT_MAC. If not, it will ignore AT_PUB_ECDHE and | | | and AT_MAC. If not, it will ignore AT_PUB_ECDHE and | |
| AT_KDF_FS and base all calculations on basic EAP-AKA' | | | AT_KDF_FS and base all calculations on basic EAP-AKA' | |
| attributes, continuing just as in EAP-AKA' per RFC | | | attributes, continuing just as in EAP-AKA' per RFC | |
| 9048 rules. In any case, the peer needs to query the | | | 9048 rules. In any case, the Peer needs to query the | |
| auth parameters from the USIM card. | | | auth parameters from the USIM card. | |
+--+--------------+----------------------------+---------+ | +--+--------------+----------------------------+---------+ |
| | | | | | | |
| RAND, AUTN | | | | RAND, AUTN | | |
|<-------------+ | | |<-------------+ | |
| | | | | | | |
| CK, IK, RES | | | | CK, IK, RES | | |
+------------->| | | +------------->| | |
+--+--------------+----------------------------+---------+ | +--+--------------+----------------------------+---------+ |
| The peer now has everything to respond. If it wants to | | | The Peer now has everything to respond. If it wants | |
| participate in the FS extension, it will then generate | | | to participate in the FS extension, it will then | |
| its key pair, calculate a shared key based on its key | | | generate its key pair, calculate a shared key based on | |
| pair and the server's public key. Finally, it proceeds | | | its key pair and the Server's public key. Finally, it | |
| to derive all EAP-AKA' key values and constructs a | | | proceeds to derive all EAP-AKA' key values and | |
| full response. | | | constructs a full response. | |
+--+--------------+----------------------------+---------+ | +--+--------------+----------------------------+---------+ |
| | | | | | | |
| | EAP-Resp/AKA'-Challenge | | | | EAP-Resp/AKA'-Challenge | |
| | AT_RES, AT_PUB_ECDHE, | | | | AT_RES, AT_PUB_ECDHE, | |
| | AT_MAC | | | | AT_MAC | |
| +--------------------------->| | | +--------------------------->| |
| +-------+----------------------------+----------------+--+ | +-------+----------------------------+----------------+--+
| | 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 document is used, | | | correct. Note that when this document is used, |
| | the keys generated from EAP-AKA' are based on CK, IK, | | | the keys generated from EAP-AKA' are based on CK, IK, |
| | and the ECDHE value. Even if there was an attacker who | | | and the ECDHE value. Even if there was an attacker |
| | held the long-term key, only an active attacker could | | | who held the long-term key, only an active attacker |
| | have determined the generated session keys; in basic | | | could have determined the generated session keys; in |
| | EAP-AKA' the generated keys are only based on CK and | | | basic EAP-AKA' the generated keys are only based on CK |
| | IK. | | | and IK. |
| +-------+----------------------------+----------------+--+ | +-------+----------------------------+----------------+--+
| | | | | | | |
| | EAP-Success | | | | EAP-Success | |
| |<---------------------------+ | | |<---------------------------+ |
| | | | | | | |
]]></artwork> ]]></artwork>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version="1 .1" height="1408" width="552" viewBox="0 0 552 1408" class="diagram" text-anchor ="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/20 00/svg" version="1.1" height="1200" width="875" viewBox="0 0 552 1408" class="di agram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-line cap="round">
<path d="M 8,688 L 8,816" fill="none" stroke="black"/> <path d="M 8,688 L 8,816" fill="none" stroke="black"/>
<path d="M 8,928 L 8,1040" fill="none" stroke="black"/> <path d="M 8,928 L 8,1040" fill="none" stroke="black"/>
<path d="M 32,48 L 32,688" fill="none" stroke="black"/> <path d="M 32,48 L 32,688" fill="none" stroke="black"/>
<path d="M 32,816 L 32,928" fill="none" stroke="black"/> <path d="M 32,816 L 32,928" fill="none" stroke="black"/>
<path d="M 32,1040 L 32,1392" fill="none" stroke="black"/> <path d="M 32,1040 L 32,1392" fill="none" stroke="black"/>
<path d="M 88,160 L 88,272" fill="none" stroke="black"/> <path d="M 88,160 L 88,272" fill="none" stroke="black"/>
<path d="M 88,432 L 88,576" fill="none" stroke="black"/> <path d="M 88,432 L 88,576" fill="none" stroke="black"/>
<path d="M 88,1136 L 88,1328" fill="none" stroke="black"/> <path d="M 88,1136 L 88,1328" fill="none" stroke="black"/>
<path d="M 152,48 L 152,160" fill="none" stroke="black"/> <path d="M 152,48 L 152,160" fill="none" stroke="black"/>
<path d="M 152,272 L 152,432" fill="none" stroke="black"/> <path d="M 152,272 L 152,432" fill="none" stroke="black"/>
skipping to change at line 799 skipping to change at line 779
<text x="308" y="68">EAP-Req/Identity</text> <text x="308" y="68">EAP-Req/Identity</text>
<text x="232" y="116">EAP-Resp/Identity</text> <text x="232" y="116">EAP-Resp/Identity</text>
<text x="236" y="132">(Privacy-Friendly)</text> <text x="236" y="132">(Privacy-Friendly)</text>
<text x="124" y="180">Server</text> <text x="124" y="180">Server</text>
<text x="168" y="180">now</text> <text x="168" y="180">now</text>
<text x="200" y="180">has</text> <text x="200" y="180">has</text>
<text x="228" y="180">an</text> <text x="228" y="180">an</text>
<text x="276" y="180">identity</text> <text x="276" y="180">identity</text>
<text x="328" y="180">for</text> <text x="328" y="180">for</text>
<text x="360" y="180">the</text> <text x="360" y="180">the</text>
<text x="400" y="180">peer.</text> <text x="400" y="180">Peer.</text>
<text x="440" y="180">The</text> <text x="440" y="180">The</text>
<text x="484" y="180">server</text> <text x="484" y="180">Server</text>
<text x="116" y="196">then</text> <text x="116" y="196">then</text>
<text x="156" y="196">asks</text> <text x="156" y="196">asks</text>
<text x="192" y="196">the</text> <text x="192" y="196">the</text>
<text x="228" y="196">help</text> <text x="228" y="196">help</text>
<text x="260" y="196">of</text> <text x="260" y="196">of</text>
<text x="284" y="196">AD</text> <text x="284" y="196">AD</text>
<text x="308" y="196">to</text> <text x="308" y="196">to</text>
<text x="336" y="196">run</text> <text x="336" y="196">run</text>
<text x="368" y="196">AKA</text> <text x="368" y="196">AKA</text>
<text x="432" y="196">algorithms,</text> <text x="432" y="196">algorithms,</text>
skipping to change at line 832 skipping to change at line 812
<text x="208" y="228">the</text> <text x="208" y="228">the</text>
<text x="248" y="228">first</text> <text x="248" y="228">first</text>
<text x="292" y="228">part</text> <text x="292" y="228">part</text>
<text x="324" y="228">of</text> <text x="324" y="228">of</text>
<text x="352" y="228">key</text> <text x="352" y="228">key</text>
<text x="416" y="228">derivations</text> <text x="416" y="228">derivations</text>
<text x="476" y="228">so</text> <text x="476" y="228">so</text>
<text x="508" y="228">that</text> <text x="508" y="228">that</text>
<text x="112" y="244">the</text> <text x="112" y="244">the</text>
<text x="188" y="244">authentication</text> <text x="188" y="244">authentication</text>
<text x="276" y="244">server</text> <text x="276" y="244">Server</text>
<text x="324" y="244">gets</text> <text x="324" y="244">gets</text>
<text x="360" y="244">the</text> <text x="360" y="244">the</text>
<text x="392" y="244">CK'</text> <text x="392" y="244">CK'</text>
<text x="424" y="244">and</text> <text x="424" y="244">and</text>
<text x="456" y="244">IK'</text> <text x="456" y="244">IK'</text>
<text x="492" y="244">keys</text> <text x="492" y="244">keys</text>
<text x="128" y="260">already</text> <text x="128" y="260">already</text>
<text x="180" y="260">tied</text> <text x="180" y="260">tied</text>
<text x="212" y="260">to</text> <text x="212" y="260">to</text>
<text x="232" y="260">a</text> <text x="232" y="260">a</text>
skipping to change at line 886 skipping to change at line 866
<text x="176" y="484">key</text> <text x="176" y="484">key</text>
<text x="212" y="484">pair</text> <text x="212" y="484">pair</text>
<text x="248" y="484">and</text> <text x="248" y="484">and</text>
<text x="280" y="484">the</text> <text x="280" y="484">the</text>
<text x="320" y="484">first</text> <text x="320" y="484">first</text>
<text x="360" y="484">EAP</text> <text x="360" y="484">EAP</text>
<text x="404" y="484">method</text> <text x="404" y="484">method</text>
<text x="464" y="484">message</text> <text x="464" y="484">message</text>
<text x="508" y="484">to</text> <text x="508" y="484">to</text>
<text x="112" y="500">the</text> <text x="112" y="500">the</text>
<text x="152" y="500">peer.</text> <text x="152" y="500">Peer.</text>
<text x="188" y="500">In</text> <text x="188" y="500">In</text>
<text x="216" y="500">the</text> <text x="216" y="500">the</text>
<text x="264" y="500">message</text> <text x="264" y="500">message</text>
<text x="312" y="500">the</text> <text x="312" y="500">the</text>
<text x="380" y="500">AT_PUB_ECDHE</text> <text x="380" y="500">AT_PUB_ECDHE</text>
<text x="472" y="500">attribute</text> <text x="472" y="500">attribute</text>
<text x="128" y="516">carries</text> <text x="128" y="516">carries</text>
<text x="176" y="516">the</text> <text x="176" y="516">the</text>
<text x="220" y="516">public</text> <text x="220" y="516">public</text>
<text x="264" y="516">key</text> <text x="264" y="516">key</text>
skipping to change at line 917 skipping to change at line 897
<text x="480" y="532">these</text> <text x="480" y="532">these</text>
<text x="520" y="532">are</text> <text x="520" y="532">are</text>
<text x="136" y="548">skippable</text> <text x="136" y="548">skippable</text>
<text x="220" y="548">attributes</text> <text x="220" y="548">attributes</text>
<text x="284" y="548">that</text> <text x="284" y="548">that</text>
<text x="320" y="548">can</text> <text x="320" y="548">can</text>
<text x="348" y="548">be</text> <text x="348" y="548">be</text>
<text x="392" y="548">ignored</text> <text x="392" y="548">ignored</text>
<text x="436" y="548">if</text> <text x="436" y="548">if</text>
<text x="464" y="548">the</text> <text x="464" y="548">the</text>
<text x="500" y="548">peer</text> <text x="500" y="548">Peer</text>
<text x="116" y="564">does</text> <text x="116" y="564">does</text>
<text x="152" y="564">not</text> <text x="152" y="564">not</text>
<text x="200" y="564">support</text> <text x="200" y="564">support</text>
<text x="252" y="564">this</text> <text x="252" y="564">this</text>
<text x="316" y="564">extension.</text> <text x="316" y="564">extension.</text>
<text x="284" y="612">EAP-Req/AKA'-Challenge</text> <text x="284" y="612">EAP-Req/AKA'-Challenge</text>
<text x="204" y="628">AT_RAND,</text> <text x="204" y="628">AT_RAND,</text>
<text x="276" y="628">AT_AUTN,</text> <text x="276" y="628">AT_AUTN,</text>
<text x="344" y="628">AT_KDF,</text> <text x="344" y="628">AT_KDF,</text>
<text x="220" y="644">AT_KDF_FS,</text> <text x="220" y="644">AT_KDF_FS,</text>
<text x="320" y="644">AT_KDF_INPUT,</text> <text x="320" y="644">AT_KDF_INPUT,</text>
<text x="264" y="660">AT_PUB_ECDHE,</text> <text x="264" y="660">AT_PUB_ECDHE,</text>
<text x="348" y="660">AT_MAC</text> <text x="348" y="660">AT_MAC</text>
<text x="32" y="708">The</text> <text x="32" y="708">The</text>
<text x="68" y="708">peer</text> <text x="68" y="708">Peer</text>
<text x="116" y="708">checks</text> <text x="116" y="708">checks</text>
<text x="156" y="708">if</text> <text x="156" y="708">if</text>
<text x="180" y="708">it</text> <text x="180" y="708">it</text>
<text x="216" y="708">wants</text> <text x="216" y="708">wants</text>
<text x="252" y="708">to</text> <text x="252" y="708">to</text>
<text x="276" y="708">do</text> <text x="276" y="708">do</text>
<text x="304" y="708">the</text> <text x="304" y="708">the</text>
<text x="332" y="708">FS</text> <text x="332" y="708">FS</text>
<text x="388" y="708">extension.</text> <text x="388" y="708">extension.</text>
<text x="444" y="708">If</text> <text x="444" y="708">If</text>
skipping to change at line 981 skipping to change at line 961
<text x="276" y="772">in</text> <text x="276" y="772">in</text>
<text x="324" y="772">EAP-AKA'</text> <text x="324" y="772">EAP-AKA'</text>
<text x="376" y="772">per</text> <text x="376" y="772">per</text>
<text x="408" y="772">RFC</text> <text x="408" y="772">RFC</text>
<text x="36" y="788">9048</text> <text x="36" y="788">9048</text>
<text x="84" y="788">rules.</text> <text x="84" y="788">rules.</text>
<text x="124" y="788">In</text> <text x="124" y="788">In</text>
<text x="152" y="788">any</text> <text x="152" y="788">any</text>
<text x="192" y="788">case,</text> <text x="192" y="788">case,</text>
<text x="232" y="788">the</text> <text x="232" y="788">the</text>
<text x="268" y="788">peer</text> <text x="268" y="788">Peer</text>
<text x="312" y="788">needs</text> <text x="312" y="788">needs</text>
<text x="348" y="788">to</text> <text x="348" y="788">to</text>
<text x="384" y="788">query</text> <text x="384" y="788">query</text>
<text x="424" y="788">the</text> <text x="424" y="788">the</text>
<text x="36" y="804">auth</text> <text x="36" y="804">auth</text>
<text x="100" y="804">parameters</text> <text x="100" y="804">parameters</text>
<text x="164" y="804">from</text> <text x="164" y="804">from</text>
<text x="200" y="804">the</text> <text x="200" y="804">the</text>
<text x="236" y="804">USIM</text> <text x="236" y="804">USIM</text>
<text x="280" y="804">card.</text> <text x="280" y="804">card.</text>
<text x="80" y="852">RAND,</text> <text x="80" y="852">RAND,</text>
<text x="124" y="852">AUTN</text> <text x="124" y="852">AUTN</text>
<text x="56" y="900">CK,</text> <text x="56" y="900">CK,</text>
<text x="88" y="900">IK,</text> <text x="88" y="900">IK,</text>
<text x="120" y="900">RES</text> <text x="120" y="900">RES</text>
<text x="32" y="948">The</text> <text x="32" y="948">The</text>
<text x="68" y="948">peer</text> <text x="68" y="948">Peer</text>
<text x="104" y="948">now</text> <text x="104" y="948">now</text>
<text x="136" y="948">has</text> <text x="136" y="948">has</text>
<text x="196" y="948">everything</text> <text x="196" y="948">everything</text>
<text x="252" y="948">to</text> <text x="252" y="948">to</text>
<text x="300" y="948">respond.</text> <text x="300" y="948">respond.</text>
<text x="348" y="948">If</text> <text x="348" y="948">If</text>
<text x="372" y="948">it</text> <text x="372" y="948">it</text>
<text x="408" y="948">wants</text> <text x="408" y="948">wants</text>
<text x="444" y="948">to</text> <text x="444" y="948">to</text>
<text x="64" y="964">participate</text> <text x="64" y="964">participate</text>
skipping to change at line 1031 skipping to change at line 1011
<text x="216" y="980">a</text> <text x="216" y="980">a</text>
<text x="252" y="980">shared</text> <text x="252" y="980">shared</text>
<text x="296" y="980">key</text> <text x="296" y="980">key</text>
<text x="336" y="980">based</text> <text x="336" y="980">based</text>
<text x="372" y="980">on</text> <text x="372" y="980">on</text>
<text x="400" y="980">its</text> <text x="400" y="980">its</text>
<text x="432" y="980">key</text> <text x="432" y="980">key</text>
<text x="36" y="996">pair</text> <text x="36" y="996">pair</text>
<text x="72" y="996">and</text> <text x="72" y="996">and</text>
<text x="104" y="996">the</text> <text x="104" y="996">the</text>
<text x="156" y="996">server's</text> <text x="156" y="996">Server's</text>
<text x="220" y="996">public</text> <text x="220" y="996">public</text>
<text x="268" y="996">key.</text> <text x="268" y="996">key.</text>
<text x="324" y="996">Finally,</text> <text x="324" y="996">Finally,</text>
<text x="372" y="996">it</text> <text x="372" y="996">it</text>
<text x="420" y="996">proceeds</text> <text x="420" y="996">proceeds</text>
<text x="28" y="1012">to</text> <text x="28" y="1012">to</text>
<text x="68" y="1012">derive</text> <text x="68" y="1012">derive</text>
<text x="112" y="1012">all</text> <text x="112" y="1012">all</text>
<text x="164" y="1012">EAP-AKA'</text> <text x="164" y="1012">EAP-AKA'</text>
<text x="216" y="1012">key</text> <text x="216" y="1012">key</text>
skipping to change at line 1053 skipping to change at line 1033
<text x="304" y="1012">and</text> <text x="304" y="1012">and</text>
<text x="364" y="1012">constructs</text> <text x="364" y="1012">constructs</text>
<text x="416" y="1012">a</text> <text x="416" y="1012">a</text>
<text x="36" y="1028">full</text> <text x="36" y="1028">full</text>
<text x="96" y="1028">response.</text> <text x="96" y="1028">response.</text>
<text x="256" y="1076">EAP-Resp/AKA'-Challenge</text> <text x="256" y="1076">EAP-Resp/AKA'-Challenge</text>
<text x="192" y="1092">AT_RES,</text> <text x="192" y="1092">AT_RES,</text>
<text x="280" y="1092">AT_PUB_ECDHE,</text> <text x="280" y="1092">AT_PUB_ECDHE,</text>
<text x="188" y="1108">AT_MAC</text> <text x="188" y="1108">AT_MAC</text>
<text x="112" y="1156">The</text> <text x="112" y="1156">The</text>
<text x="156" y="1156">server</text> <text x="156" y="1156">Server</text>
<text x="200" y="1156">now</text> <text x="200" y="1156">now</text>
<text x="232" y="1156">has</text> <text x="232" y="1156">has</text>
<text x="264" y="1156">all</text> <text x="264" y="1156">all</text>
<text x="296" y="1156">the</text> <text x="296" y="1156">the</text>
<text x="352" y="1156">necessary</text> <text x="352" y="1156">necessary</text>
<text x="424" y="1156">values.</text> <text x="424" y="1156">values.</text>
<text x="468" y="1156">It</text> <text x="468" y="1156">It</text>
<text x="136" y="1172">generates</text> <text x="136" y="1172">generates</text>
<text x="192" y="1172">the</text> <text x="192" y="1172">the</text>
<text x="232" y="1172">ECDHE</text> <text x="232" y="1172">ECDHE</text>
skipping to change at line 1146 skipping to change at line 1126
<text x="372" y="1300">only</text> <text x="372" y="1300">only</text>
<text x="416" y="1300">based</text> <text x="416" y="1300">based</text>
<text x="452" y="1300">on</text> <text x="452" y="1300">on</text>
<text x="476" y="1300">CK</text> <text x="476" y="1300">CK</text>
<text x="504" y="1300">and</text> <text x="504" y="1300">and</text>
<text x="112" y="1316">IK.</text> <text x="112" y="1316">IK.</text>
<text x="328" y="1364">EAP-Success</text> <text x="328" y="1364">EAP-Success</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
</artset> </artset>
</figure> </figure>
</section>
</section> <section numbered="true" toc="default">
<name>Extensions to EAP-AKA'</name>
<section title="Extensions to EAP-AKA'"> <section anchor="at_pub_dh" numbered="true" toc="default">
<section anchor="at_pub_dh" title="AT_PUB_ECDHE"> <name>AT_PUB_ECDHE</name>
<t>The AT_PUB_ECDHE attribute carries an ECDHE value.</t>
<t>The AT_PUB_ECDHE carries an ECDHE value.</t> <t>The format of the AT_PUB_ECDHE attribute is shown below.</t>
<artset>
<t>The format of the AT_PUB_ECDHE attribute is shown below.</t> <artwork type="ascii-art" align="center" name="" alt=""><![CDATA[
<figure>
<artset>
<artwork type="ascii-art" align="center">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_PUB_ECDHE | Length | Value | | AT_PUB_ECDHE | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version=" <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www
1.1" height="112" width="528" viewBox="0 0 528 112" class="diagram" text-anchor= .w3.org/2000/svg" version="1.1" height="112" width="528" viewBox="0 0 528 112" c
"middle" font-family="monospace" font-size="13px"> lass="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
<path d="M 8,64 L 8,96" fill="none" stroke="black"/> <path d="M 8,64 L 8,96" fill="none" stroke="black"/>
<path d="M 136,64 L 136,96" fill="none" stroke="black"/> <path d="M 136,64 L 136,96" fill="none" stroke="black"/>
<path d="M 264,64 L 264,96" fill="none" stroke="black"/> <path d="M 264,64 L 264,96" fill="none" stroke="black"/>
<path d="M 520,64 L 520,96" fill="none" stroke="black"/> <path d="M 520,64 L 520,96" fill="none" stroke="black"/>
<path d="M 8,64 L 520,64" fill="none" stroke="black"/> <path d="M 8,64 L 520,64" fill="none" stroke="black"/>
<path d="M 8,96 L 520,96" fill="none" stroke="black"/> <path d="M 8,96 L 520,96" fill="none" stroke="black"/>
<g class="text"> <g class="text">
<text x="16" y="36">0</text> <text x="16" y="36">0</text>
<text x="176" y="36">1</text> <text x="176" y="36">1</text>
<text x="336" y="36">2</text> <text x="336" y="36">2</text>
skipping to change at line 1218 skipping to change at line 1194
<text x="480" y="52">9</text> <text x="480" y="52">9</text>
<text x="496" y="52">0</text> <text x="496" y="52">0</text>
<text x="512" y="52">1</text> <text x="512" y="52">1</text>
<text x="68" y="84">AT_PUB_ECDHE</text> <text x="68" y="84">AT_PUB_ECDHE</text>
<text x="172" y="84">Length</text> <text x="172" y="84">Length</text>
<text x="296" y="84">Value</text> <text x="296" y="84">Value</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
</artset> </artset>
</figure>
<t>The fields are as follows:</t>
<t><list style="hanging">
<t hangText="AT_PUB_ECDHE"><vspace blankLines="1"/>This is set to TBA <t>The fields are as follows:</t>
1 BY
IANA.</t>
<t hangText="Length"><vspace blankLines="1"/>The length of
the attribute, set as other attributes in EAP-AKA <xref
target="RFC4187"/>. The length is expressed in multiples of
4 bytes. The length includes the attribute type field, the
Length field itself, and the Value field (along with any padding).
</t>
<t hangText="Value"><vspace blankLines="1"/>This value is
the sender's ECDHE public key. The value depends on AT_KDF_FS and
is calculated as follows:
<list style="symbols">
<t>For X25519,
the length of this value is 32 bytes, encoded as specified in
<xref target="RFC7748"/> Section 5.</t>
<t>For P-256, the length of this value is 33 bytes, encoded
using the compressed form specified in Section 2.3.3 of
<xref target="SEC1"/>.</t>
</list>
<vspace blankLines="1"/>
Because the length of the attribute must be a multiple of 4
bytes, the sender pads the Value field with zero bytes when
necessary.
To retain the security of the keys, the sender SHALL generate
a fresh value for each run of the protocol.</t>
</list></t> <dl newline="true" spacing="normal">
<dt>AT_PUB_ECDHE:</dt>
<dd>This is set to 152 by IANA.</dd>
</section> <dt>Length:</dt>
<dd>This is the length of the attribute, set as other attributes in
EAP-AKA <xref target="RFC4187" format="default"/>. The length is
expressed in multiples of 4 bytes. The length includes the attribute
type field, the Length field itself, and the Value field (along with
any padding).</dd>
<section anchor="at_kdf_dh" title="AT_KDF_FS"> <dt>Value:</dt>
<dd>
<t>This value is
the sender's ECDHE public key. The value depends on the AT_KDF_FS att
ribute and
is calculated as follows:</t>
<ul spacing="normal">
<li>
<t>For X25519, the length of this value is 32 bytes, encoded
as specified in <xref target="RFC7748" sectionFormat="of"
section="5"/>.</t>
</li>
<li>
<t>For P-256, the length of this value is 33 bytes, encoded
using the compressed form specified in Section 2.3.3 of <xref
target="SEC1" format="default"/>.</t>
</li>
</ul>
<t>Because the length of the attribute must be a multiple of 4
bytes, the sender pads the Value field with zero bytes when
necessary. To retain the security of the keys, the sender
<bcp14>SHALL</bcp14> generate a fresh value for each run of the
protocol.</t>
</dd>
</dl>
</section>
<t>The AT_KDF_FS indicates the used or desired forward secrecy key <section anchor="at_kdf_dh" numbered="true" toc="default">
generation function, if the Forward Secrecy (FS) extension <name>AT_KDF_FS</name>
<t>The AT_KDF_FS attribute indicates the used or desired FS key
generation function, if the FS extension
is used. It will also indicate the is used. It will also indicate the
used or desired ECDHE group. A new attribute is needed to used or desired ECDHE group. A new attribute is needed to
carry this information, as AT_KDF carries the basic KDF carry this information, as AT_KDF carries the basic KDF
value which is still used together with the forward secrecy KDF value that is still used together with the FS KDF
value. The basic KDF value is also used by those EAP peers value. The basic KDF value is also used by those EAP Peers
that cannot or do not want to use this extension.</t> that cannot or do not want to use this extension.</t>
<t>This document only specifies the behavior relating to the following
<t>This document only specifies the behavior relating to combinations of basic KDF values and FS KDF values:</t>
the following combinations of basic KDF values and forward secrecy <ul>
KDF values: <li>the
The basic KDF value in AT_KDF is 1, as specified in <xref target="RFC544 basic KDF value in AT_KDF is 1, as specified in <xref target="RFC5448"
8"/> and <xref target="RFC9048"/>, format="default"/> and <xref target="RFC9048" format="default"/> and</li
and the forward secrecy KDF values in AT_KDF_FS are 1 or 2, as specified >
below and in <xref target="kdf2"/>.</t> <li>the FS KDF values in AT_KDF_FS are 1 or 2, as specified
below and in <xref target="kdf2" format="default"/>.</li></ul>
<t>Any future specifications that add either new basic KDF or new forwar <t>Any future specifications that add either new basic KDFs or new FS KD
d secrecy KDF values need to specify F values need to specify
how they are treated and what combinations are allowed. This requirement is an update to how how they are treated and what combinations are allowed. This requirement is an update to how
<xref target="RFC5448"/> and <xref target="RFC9048"/> may be extended in <xref target="RFC5448" format="default"/> and <xref target="RFC9048" for
the future.</t> mat="default"/> may be extended in the future.</t>
<t>The format of the AT_KDF_FS attribute is shown below.</t>
<t>The format of the AT_KDF_FS attribute is shown below.</t> <artset>
<artwork type="ascii-art" align="center" name="" alt=""><![CDATA[
<figure>
<artset>
<artwork type="ascii-art" align="center">
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF_FS | Length | FS Key Derivation Function | | AT_KDF_FS | Length | FS Key Derivation Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork> ]]></artwork>
<artwork type="svg"><svg xmlns="http://www.w3.org/2000/svg" version=" <artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www
1.1" height="112" width="528" viewBox="0 0 528 112" class="diagram" text-anchor= .w3.org/2000/svg" version="1.1" height="112" width="528" viewBox="0 0 528 112" c
"middle" font-family="monospace" font-size="13px"> lass="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
<path d="M 8,64 L 8,96" fill="none" stroke="black"/> <path d="M 8,64 L 8,96" fill="none" stroke="black"/>
<path d="M 136,64 L 136,96" fill="none" stroke="black"/> <path d="M 136,64 L 136,96" fill="none" stroke="black"/>
<path d="M 264,64 L 264,96" fill="none" stroke="black"/> <path d="M 264,64 L 264,96" fill="none" stroke="black"/>
<path d="M 520,64 L 520,96" fill="none" stroke="black"/> <path d="M 520,64 L 520,96" fill="none" stroke="black"/>
<path d="M 8,64 L 520,64" fill="none" stroke="black"/> <path d="M 8,64 L 520,64" fill="none" stroke="black"/>
<path d="M 8,96 L 520,96" fill="none" stroke="black"/> <path d="M 8,96 L 520,96" fill="none" stroke="black"/>
<g class="text"> <g class="text">
<text x="16" y="36">0</text> <text x="16" y="36">0</text>
<text x="176" y="36">1</text> <text x="176" y="36">1</text>
<text x="336" y="36">2</text> <text x="336" y="36">2</text>
skipping to change at line 1345 skipping to change at line 1317
<text x="512" y="52">1</text> <text x="512" y="52">1</text>
<text x="56" y="84">AT_KDF_FS</text> <text x="56" y="84">AT_KDF_FS</text>
<text x="172" y="84">Length</text> <text x="172" y="84">Length</text>
<text x="284" y="84">FS</text> <text x="284" y="84">FS</text>
<text x="312" y="84">Key</text> <text x="312" y="84">Key</text>
<text x="372" y="84">Derivation</text> <text x="372" y="84">Derivation</text>
<text x="452" y="84">Function</text> <text x="452" y="84">Function</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
</artset> </artset>
</figure>
<t>The fields are as follows:</t>
<t><list style="hanging">
<t hangText="AT_KDF_FS"><vspace blankLines="1"/>This is set to TBA2 B
Y
IANA.</t>
<t hangText="Length"><vspace blankLines="1"/>The length of the
attribute, MUST be set to 1.</t>
<t hangText="FS Key Derivation Function"><vspace blankLines="1"/>An
enumerated value representing the forward secrecy key derivation func
tion that the
server (or peer) wishes to use. See <xref target="kdf2"/> for the fun
ctions
specified in this document. Note: This field has a
different name space than the similar field in the AT_KDF
attribute Key Derivation Function defined in <xref
target="RFC9048"/>.</t>
</list></t>
<t>Servers MUST send one or more AT_KDF_FS attributes in the
EAP-Request/AKA'-Challenge message. These attributes represent the desi
red
functions ordered by preference, the most preferred function being the
first
attribute. The most preferred function is the only one that the server
includes a
public key value for, however. So for a set of AT_KDF_FS attributes, th
ere is
always only one AT_PUB_ECDHE attribute.</t>
<t>Upon receiving a set of these attributes:
<list style="symbols">
<t>If the peer supports and is willing to use the FS Key Derivation Fu
nction
indicated by the first AT_KDF_FS attribute, and is willing and able to
use the
extension defined in this document, the function is taken into use wit
hout
any further negotiation.</t>
<t>If the peer does not support this function or is unwilling to use i
t, it
responds to the server with an indication that a different function is
needed. Similarly with the negotiation process defined in <xref
target="RFC9048"/> for AT_KDF, the peer sends
EAP-Response/AKA'-Challenge message that contains only one attribute,
AT_KDF_FS with the value set to the desired alternative function from
among
the ones suggested by the server earlier. If there is no suitable alte
rnative,
the peer has a choice of either falling back to EAP-AKA' or behaving a
s if AUTN
had been incorrect and failing authentication (see Figure 3 of <xref
target="RFC4187"/>). The peer MUST fail the authentication if there ar
e any
duplicate values within the list of AT_KDF_FS attributes (except where
the
duplication is due to a request to change the key derivation function;
see
below for further information).</t>
<t>If the peer does not recognize the extension defined in this docum <t>The fields are as follows:</t>
ent
or is unwilling to use it, it ignores the AT_KDF_FS attribute.</t>
</list></t> <dl newline="true" spacing="normal">
<dt>AT_KDF_FS:</dt>
<dd>This is set to 153 by
IANA.</dd>
<t>Upon receiving an EAP-Response/AKA'-Challenge with AT_KDF_FS from th <dt>Length:</dt>
e <dd>This is the length of the
peer, the server checks that the suggested AT_KDF_FS value was one of t attribute; it <bcp14>MUST</bcp14> be set to 1.</dd>
he
alternatives in its offer. The first AT_KDF_FS value in the message fro
m
the server is not a valid alternative. If the peer has replied with
the first AT_KDF_FS value, the server behaves as if AT_MAC of the
response had been incorrect and fails the authentication. For an
overview of the failed authentication process in the server side, see
Section 3 and Figure 2 in <xref target="RFC4187"/>. Otherwise, the
server re-sends the EAP-Response/AKA'-Challenge message, but adds the
selected alternative to the beginning of the list of AT_KDF_FS
attributes, and retains the entire list following it. Note that this
means that the selected alternative appears twice in the set of AT_KDF
values. Responding to the peer's request to change the FS Key Derivatio
n Function
is the only valid situation where such duplication may
occur.</t>
<t>When the peer receives the new EAP-Request/AKA'-Challenge message, <dt>FS Key Derivation Function:</dt>
it MUST check that the requested change, and only the requested change <dd>This is an enumerated value representing the FS Key Derivation Fun
occurred in the list of AT_KDF_FS attributes. If yes, it continues. If ction (KDF) that the Server (or Peer) wishes to use. See
not, it behaves as if AT_MAC had been incorrect and fails the <xref target="kdf2" format="default"/> for the functions specified
authentication. If the peer receives multiple in this document. Note: this field has a different name space than
EAP-Request/AKA'-Challenge messages with differing AT_KDF_FS attributes the similar field in the AT_KDF attribute KDF
without having requested negotiation, the peer MUST behave as if defined in <xref target="RFC9048" format="default"/>.</dd>
AT_MAC had been incorrect and fail the authentication.</t> </dl>
</section> <t>Servers <bcp14>MUST</bcp14> send one or more AT_KDF_FS attributes
in the EAP-Request/AKA'-Challenge message. These attributes represent
the desired functions ordered by preference, with the most preferred
function being the first attribute. The most preferred function is the
only 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 attribute.</t>
<section anchor="kdf2" title="Forward Secrecy Key Derivation Functions"> <t>Upon receiving a set of these attributes:</t>
<t>Two new FS Key Derivation Function types are defined for <ul spacing="normal">
"EAP-AKA' with ECDHE and X25519", represented by value 1, and <li>If the Peer supports and is willing to use the FS KDF indicated
"EAP-AKA' with ECDHE and P-256", represented by by the first AT_KDF_FS attribute, and is willing and able to use the
value 2. These represent a particular choice of key extension defined in this document, the function will be used
derivation function and at the same time selects an ECDHE without any further negotiation.</li>
group to be used.</t>
<t>The FS Key Derivation Function type value is only used <li>If the Peer does not support this function or is unwilling to
in the AT_KDF_FS attribute. When the forward secrecy extension use it, it responds to the Server with an indication that a
is used, the AT_KDF_FS attribute determines how to derive the different function is needed. Similarly, with the negotiation process
keys MK_ECDHE, K_re, MSK, and EMSK. The AT_KDF_FS attribute should defined in <xref target="RFC9048" format="default"/> for AT_KDF, the
not be confused with the different range of key derivation functions Peer sends an EAP-Response/AKA'-Challenge message that contains only
that can be represented in the AT_KDF attribute as defined in one attribute, AT_KDF_FS, with the value set to the desired
<xref target="RFC9048"/>. When the forward secrecy extension alternative function from among the ones suggested by the Server
is used, the AT_KDF attribute only specifies how to derive the earlier. If there is no suitable alternative, the Peer has a choice
keys MK, K_encr, and K_aut.</t> of either falling back to EAP-AKA' or behaving as if the AUTN had been
incorrect and failing authentication (see Figure 3 of <xref
target="RFC4187" format="default"/>). The Peer <bcp14>MUST</bcp14>
fail the authentication if there are any duplicate values within the
list of AT_KDF_FS attributes (except where the duplication is due to
a request to change the KDF; see below for
further information).</li>
<t>Key derivation in this extension produces exactly the same <li>If the Peer does not recognize the extension defined in this
keys for internal use within one authentication run as EAP-AKA' <xref document or is unwilling to use it, it ignores the AT_KDF_FS
target="RFC9048"/> does. For attribute.</li>
instance, K_aut that is used in AT_MAC is still exactly as it </ul>
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 EMSK. As a result, EAP-AKA' attributes such
as AT_MAC continue to be usable even when this extension is
in use.</t>
<t>When the FS Key Derivation Function field in the AT_KDF_FS <t>Upon receiving an EAP-Response/AKA'-Challenge message with an AT_KDF_
attribute is set to 1 or 2 and the Key Derivation Function field FS attribute
in the AT_KDF attribute is set to 1, the Master Key (MK) and from the Peer, the Server checks that the suggested AT_KDF_FS value
accompanying keys are derived as follows. was one of 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 replied with the first AT_KDF_FS value, the Server behaves as if
the AT_MAC of the response had been incorrect and fails the
authentication. For an overview of the failed authentication process
in the Server side, see Section <xref target="RFC4187"
sectionFormat="bare" section="3"/> and Figure 2 in <xref
target="RFC4187"/>. Otherwise, the Server re-sends the
EAP-Response/AKA'-Challenge message, but adds the selected alternative
to the beginning of the list of AT_KDF_FS attributes and retains the
entire list following it. Note that this means that the selected
alternative appears twice in the set of AT_KDF values. Responding to
the Peer's request to change the FS KDF is the
only valid situation where such duplication may occur.</t>
<t>When the Peer receives the new EAP-Request/AKA'-Challenge message,
it <bcp14>MUST</bcp14> check that the requested change, and only the
requested change, occurred in the list of AT_KDF_FS attributes. If so,
it continues. If not, it behaves as if AT_MAC were incorrect and
fails the authentication. If the Peer receives multiple
EAP-Request/AKA'-Challenge messages with differing AT_KDF_FS
attributes without having requested negotiation, the Peer
<bcp14>MUST</bcp14> behave as if AT_MAC were incorrect and fail
the authentication.</t>
</section>
<section anchor="kdf2" numbered="true" toc="default">
<name>Forward Secrecy Key Derivation Functions</name>
<t>Two new FS KDF types are defined for "EAP-AKA'
with ECDHE and X25519", represented by value 1, and "EAP-AKA' with
ECDHE and P-256", represented by value 2. These values represent a parti
cular
choice of KDF and, at the same time, select an
ECDHE group to be used.</t>
<t>The FS KDF type value is only used in the
AT_KDF_FS attribute. When the FS extension is used, the
AT_KDF_FS attribute determines how to derive the MK_ECDHE key, K_re key,
Master Session Key (MSK), and Extended Master Session Key (EMSK). The
AT_KDF_FS attribute should not be confused with the different range of
KDFs that can be represented in the AT_KDF
attribute as defined in <xref target="RFC9048"
format="default"/>. When the FS extension is used, the
AT_KDF attribute only specifies how to derive the Master Key (MK), the K
_encr key, and the
K_aut key.</t>
<t>Key derivation in this extension produces exactly the same keys for
internal use within one authentication run as EAP-AKA' <xref
target="RFC9048" format="default"/> does. For instance, the 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 the re-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 usable even when this extension is in
use.</t>
<t>When the FS KDF field in the AT_KDF_FS
attribute is set to 1 or 2 and the KDF field
in the AT_KDF attribute is set to 1, the MK and
accompanying keys are derived as follows:
</t>
<figure> <artwork align="center" name="" type="" alt=""><![CDATA[
<artwork align="center">
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]
</artwork> ]]></artwork>
</figure></t>
<t>Requirements for how to securely generate, validate, and process the
ephemeral public keys depend on the elliptic curve.</t>
<t>For P-256 the SHARED_SECRET is the shared
secret computed as specified in Section 5.7.1.2 of <xref target="SP-800-5
6A"/>.
Public key validation requirements are defined in Section 5 of <xref targ
et="SP-800-56A"/>.
At least partial public-key validation MUST be done for the ephemeral pub
lic keys. The uncompressed y-coordinate can be
computed as described in Section 2.3.4 of <xref target="SEC1"/>.</t>
<t>For X25519 the SHARED_SECRET is the shared secret computed as specifie
d in
Section 6.1 of <xref target="RFC7748"/>. Both the peer and the server
MAY check for zero-value shared secret as specified in Section 6.1 of
<xref target="RFC7748"/>.</t>
<t><list style="empty">
<t>Note: The way that shared secret is tested for zero can,
if performed inappropriately, provide an ability for
attackers to listen to CPU power usage side channels. Refer
to <xref target="RFC7748"/> for a description of how to
perform this check in a way that it does not become a
problem.</t>
</list></t>
<t>If validation of the other party's ephemeral public key or the shared <t>An explanation of the notation used above is copied here:</t>
secret fails, <ul>
a party MUST behave as if the current EAP-AKA' authentication <li>[n..m] denotes the substring from bit n to m.</li>
process starts again from the beginning.</t> <li>PRF' is a new pseudorandom function specified in <xref target="RFC9048"/>.
</li>
<li>K_encr is the encryption key (128 bits).</li>
<li>K_aut is the authentication key (256 bits).</li>
<li>K_re is the re-authentication key (256 bits).</li>
<li>MSK is the Master Session Key (512 bits).</li>
<li>EMSK is the Extended Master Session Key (512 bits).</li>
</ul>
<t>The rest of computation proceeds as defined in Section 3.3 of <xref <t>Note: MSK and EMSK are outputs from a successful EAP method run
target="RFC9048"/>.</t> <xref target="RFC3748" format="default"/>.</t>
<t>The CK and IK are produced by the AKA algorithm. The IK' and CK' are
derived as specified in <xref target="RFC9048" format="default"/> from
the IK and CK.</t>
<t>For readability, an explanation of the notation used above <t>The value "EAP-AKA'" is an ASCII string that is 8 characters long. I
is copied here: [n..m] denotes the substring from bit n to m. t
PRF' is a new pseudo-random function specified in <xref is used as is, without any trailing NUL characters. Similarly,
target="RFC9048"/>. K_encr is the encryption key, 128 bits, "EAP-AKA' FS" is an ASCII string that is 11 characters long, also used a
K_aut is the authentication key, 256 bits, K_re is the s
re-authentication key, 256 bits, MSK is the Master Session is.</t>
Key, 512 bits, and EMSK is the Extended Master Session Key,
512 bits. MSK and EMSK are outputs from a successful EAP
method run <xref target="RFC3748"/>.</t>
<t>CK and IK are produced by the AKA algorithm. IK' and CK' <t>Requirements for how to securely generate, validate, and process the
are derived as specified in <xref target="RFC9048"/> from IK ephemeral public keys depend on the elliptic curve.</t>
and CK.</t> <t>For P-256, the SHARED_SECRET is the shared secret computed as
specified in Section 5.7.1.2 of <xref target="SP-800-56A"
format="default"/>. Public key validation requirements are defined in
Section 5 of <xref target="SP-800-56A" format="default"/>. At least
partial public key validation <bcp14>MUST</bcp14> be done for the
ephemeral public keys. The uncompressed y-coordinate can be computed
as described in Section 2.3.4 of <xref target="SEC1"
format="default"/>.</t>
<t>For X25519, the SHARED_SECRET is the shared secret computed as specif
ied in
<xref target="RFC7748" sectionFormat="of" section="6.1"/>. Both the Peer
and the Server
<bcp14>MAY</bcp14> check for the zero-value shared secret as specified in
<xref target="RFC7748" sectionFormat="of" section="6.1"/>.</t>
<t>The value "EAP-AKA'" is an eight-characters-long ASCII string. It i <aside><t>Note: If performed inappropriately, the way that the shared
s secret is tested for zero can provide an ability for attackers to
used as is, without any trailing NUL characters. Similarly, listen to CPU power usage side channels. Refer to <xref
"EAP-AKA' FS" is an eleven-characters-long ASCII string, also target="RFC7748" format="default"/> for a description of how to
used as is.</t> perform this check in a way that it does not become a
problem.</t></aside>
<t>Identity is the peer identity as specified in Section 7 of <xref tar <t>If validation of the other party's ephemeral public key or the shared
get="RFC4187"/>. secret fails,
A privacy-friendly identifier <xref target="RFC9048"/> SHALL be used.</t a party <bcp14>MUST</bcp14> behave as if the current EAP-AKA' process sta
> rts again from the beginning.</t>
<t>The rest of the computation proceeds as defined in <xref
target="RFC9048" sectionFormat="of" section="3.3"/>.</t>
</section> </section>
<section anchor="groups" title="ECDHE Groups"> <section anchor="groups" numbered="true" toc="default">
<t>The selection of suitable groups for the elliptic curve <name>ECDHE Groups</name>
<t>The selection of suitable groups for the elliptic curve
computation is necessary. The choice of a group is made at computation is necessary. The choice of a group is made at
the same time as deciding to use of particular key derivation the same time as the decision to use a particular KDF in the AT_KDF_FS
function in AT_KDF_FS.</t> attribute.</t>
<t>For "EAP-AKA' with ECDHE and
<t>For "EAP-AKA' with ECDHE and X25519", the group is the Curve25519 group specified in
X25519" the group is the Curve25519 group specified in <xref target="RFC7748" format="default"/>. The support for this group i
<xref target="RFC7748"/>. The support for this group is REQUIRED.</t> s <bcp14>REQUIRED</bcp14>.</t>
<t>For "EAP-AKA' with ECDHE and P-256", the group is the NIST P-256
<t>For "EAP-AKA' with ECDHE and P-256" the group is the NIST group (SEC group secp256r1), specified in Section 3.2.1.3 of <xref
P-256 group (SEC group secp256r1), specified in Section 3.2.1.3 of target="SP-800-186" format="default"/> or alternatively, Section 2.4.2
<xref target="SP-800-186"/> or alternatively Section 2.4.2 of <xref targ of <xref target="SEC2" format="default"/>. The support for this group
et="SEC2"/>. is <bcp14>REQUIRED</bcp14>.</t>
The support for this group is REQUIRED.</t> <t>The term "support" here means that the group <bcp14>MUST</bcp14> be i
mplemented.</t>
<t>The term "support" here means that the group MUST be implemented.</t> </section>
<section anchor="secMessageProc" numbered="true" toc="default">
</section> <name>Message Processing</name>
<t>This section specifies the changes related to message processing
<section title="Message Processing" anchor="secMessageProc">
<t>This section specifies the changes related to message processing
when this extension is used in EAP-AKA'. It specifies when a when this extension is used in EAP-AKA'. It specifies when a
message may be transmitted or accepted, which attributes are message may be transmitted or accepted, which attributes are
allowed in a message, which attributes are required in a message, allowed in a message, which attributes are required in a message,
and other message-specific details, where those details are and other message-specific details, where those details are
different for this extension than the base EAP-AKA' or EAP-AKA different for this extension than the base EAP-AKA' or EAP-AKA
protocol. Unless otherwise specified here, the rules from <xref protocol. Unless otherwise specified here, the rules from <xref target="RFC9
target="RFC9048"/> or <xref target="RFC4187"/> apply.</t> 048" format="default"/> or <xref target="RFC4187" format="default"/> apply.</t>
<section numbered="true" toc="default">
<section title="EAP-Request/AKA'-Identity">
<t>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 a received message MUST be ignored.</t>
</section>
<section title="EAP-Response/AKA'-Identity">
<t>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 a
received message
MUST be ignored. The peer identifier SHALL comply
with the privacy-friendly requirements of
<xref target="RFC9190"/>. An example of a compliant way of constructing
a privacy-friendly peer identifier is using a non-NULL SUCI <xref target="
TS.33.501"/>.
</t>
</section>
<section anchor="procakachall" title="EAP-Request/AKA'-Challenge">
<t>The server sends the EAP-Request/AKA'-Challenge on full authentication
as specified by <xref target="RFC4187"/> and <xref target="RFC9048"/>.
The attributes AT_RAND, AT_AUTN, and AT_MAC MUST be included and
checked on reception as specified
in <xref target="RFC4187"/>. They are also necessary
for backwards compatibility.</t>
<t>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 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 or AT_PUB_ECDHE is missing on reception, the peer
MUST treat it as if neither one was sent, and the assume that
the extension defined in this document is not in use.</t>
<t>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
included as specified in Section 9.3 of <xref
target="RFC4187"/>.</t>
<t>When processing this message, the peer MUST process AT_RAND,
AT_AUTN, AT_KDF_FS, AT_PUB_ECDHE before processing other attributes.
Only if 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 extension specified in this document,
it proceeds as defined in <xref target="RFC9048"/>. Finally, if
there is an error error, see Section 6.3.1. of <xref target="RFC4187"/>.</
t>
</section>
<section anchor="procakachallresp" title="EAP-Response/AKA'-Challenge"> <name>EAP-Request/AKA'-Identity</name>
<t>There are no changes for the EAP-Request/AKA'-Identity, except
that the AT_KDF_FS or AT_PUB_ECDHE attributes <bcp14>MUST
NOT</bcp14> be added to this message. The appearance of these
attributes in a received message <bcp14>MUST</bcp14> be ignored.</t>
</section>
<section numbered="true" toc="default">
<name>EAP-Response/AKA'-Identity</name>
<t>There are no changes for the EAP-Response/AKA'-Identity, except
that the AT_KDF_FS or AT_PUB_ECDHE attributes <bcp14>MUST
NOT</bcp14> be added to this message. The appearance of these
attributes in a received message <bcp14>MUST</bcp14> be ignored. The
Peer identifier <bcp14>SHALL</bcp14> comply with the
privacy-friendly requirements of <xref target="RFC9190"
format="default"/>. An example of a compliant way of constructing a
privacy-friendly Peer identifier is using a non-null SUCI <xref
target="TS.33.501" format="default"/>.
</t>
</section>
<section anchor="procakachall" numbered="true" toc="default">
<name>EAP-Request/AKA'-Challenge</name>
<t>The Server sends the EAP-Request/AKA'-Challenge on full
authentication as specified by <xref target="RFC4187"
format="default"/> and <xref target="RFC9048" format="default"/>.
The attributes AT_RAND, AT_AUTN, and AT_MAC <bcp14>MUST</bcp14> be
included and checked on reception as specified in <xref
target="RFC4187" format="default"/>. They are also necessary for
backwards compatibility.</t>
<t>In the EAP-Request/AKA'-Challenge, there is no message-specific dat
a
covered by the MAC for the AT_MAC attribute. The AT_KDF_FS and
AT_PUB_ECDHE attributes <bcp14>MUST</bcp14> be included. The
AT_PUB_ECDHE attribute carries the Server's public Diffie-Hellman
key. If either AT_KDF_FS or AT_PUB_ECDHE is missing on reception,
the Peer <bcp14>MUST</bcp14> treat it as if neither one was sent
and assume that the extension defined in this document is not in
use.</t>
<t>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
included as specified in <xref target="RFC4187" sectionFormat="of"
section="9.3"/>.</t>
<t>The peer sends EAP-Response/AKA'-Challenge in response to a <t>When processing this message, the Peer <bcp14>MUST</bcp14>
valid EAP-Request/AKA'-Challenge message, as specified by <xref process AT_RAND, AT_AUTN, AT_KDF_FS, and AT_PUB_ECDHE before
target="RFC4187"/> and <xref target="RFC9048"/>. processing other attributes. The Peer derives keys and verifies
If the peer supports and is willing to perform the extension AT_MAC only if these attributes are verified to be valid. If the
specified in this protocol, and the server had made a valid Peer is unable or unwilling to perform the extension specified in
request involving the attributes specified in <xref this document, it proceeds as defined in <xref target="RFC9048"
target="procakachall"/>, the peer responds per the rules format="default"/>. Finally, if there is an error, see <xref
specified below. Otherwise, the peer responds as specified in target="RFC4187" sectionFormat="of" section="6.3.1"/>.</t>
<xref target="RFC4187"/> and <xref </section>
target="RFC9048"/> and ignores the attributes <section anchor="procakachallresp" numbered="true" toc="default">
related to this extension. If the peer has not received <name>EAP-Response/AKA'-Challenge</name>
<t>The Peer sends an EAP-Response/AKA'-Challenge in response to a
valid EAP-Request/AKA'-Challenge message, as specified by <xref target="RF
C4187" format="default"/> and <xref target="RFC9048" format="default"/>.
If the Peer supports and is willing to perform the extension
specified in this protocol, and the Server had made a valid
request involving the attributes specified in <xref target="procakachall"
format="default"/>, the Peer responds per the rules
specified below. Otherwise, the Peer responds as specified in
<xref target="RFC4187" format="default"/> and <xref target="RFC9048" forma
t="default"/> and ignores the attributes
related to this extension. If the Peer has not received
attributes related to this extension from the Server, and has a attributes related to this extension from the Server, and has a
policy that requires it to always use this extension, it behaves policy that requires it to always use this extension, it behaves
as if AUTN had been incorrect and fails the authentication.</t> as if the AUTN were incorrect and fails the authentication.</t>
<t>The AT_MAC attribute <bcp14>MUST</bcp14> be included and checked as
<t>The AT_MAC attribute MUST be included and checked as specified in <xref target="RFC9048" format="default"/>. In the
specified in <xref target="RFC9048"/>. In
EAP-Response/AKA'-Challenge, there is no message-specific data EAP-Response/AKA'-Challenge, there is no message-specific data
covered by the MAC. The AT_PUB_ECDHE attribute MUST be included, covered by the MAC. The AT_PUB_ECDHE attribute <bcp14>MUST</bcp14> be incl
and carries the peer's public Diffie-Hellman key.</t> uded
and carries the Peer's public Diffie-Hellman key.</t>
<t>The AT_RES attribute MUST be included and checked as <t>The AT_RES attribute <bcp14>MUST</bcp14> be included and checked as
specified in <xref target="RFC4187"/>. When processing this specified in <xref target="RFC4187" format="default"/>. When processing t
message, the Server MUST process AT_RES before processing other his
message, the Server <bcp14>MUST</bcp14> process AT_RES before processing o
ther
attributes. The Server derives keys and verifies AT_MAC only attributes. The Server derives keys and verifies AT_MAC only
when this attribute is verified to be valid.</t> when this attribute is verified to be valid.</t>
<t>If the Server has proposed the use of the extension specified
<t>If the Server has proposed the use of the extension specified in this protocol, but the Peer ignores and continues the basic
in this protocol, but the peer ignores and continues the basic EAP-AKA' authentication, the Server makes a policy decision of
EAP-AKA' authentication, the Server makes policy decision of
whether this is allowed. If this is allowed, it continues the whether this is allowed. If this is allowed, it continues the
EAP-AKA' authentication to completion. If it is not allowed, the EAP-AKA' authentication to completion. If it is not allowed, the
Server MUST behave as if authentication failed.</t> Server <bcp14>MUST</bcp14> behave as if authentication failed.</t>
<t>The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA, and other
<t>The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA and other attributes may be included as specified in <xref target="RFC4187" sectionF
attributes may be included as specified in Section 9.4 of <xref target="RF ormat="of" section="9.4"/>.</t>
C4187"/>.</t> </section>
</section>
<section anchor="reauth" title="EAP-Request/AKA'-Reauthentication"> <section anchor="reauth" numbered="true" toc="default">
<t>No changes, but note that the re-authentication process <name>EAP-Request/AKA'-Reauthentication</name>
<t>There are no changes for the EAP-Request/AKA'-Reauthentication, but
note that the re-authentication process
uses the keys generated in the original EAP-AKA' authentication, uses the keys generated in the original EAP-AKA' authentication,
which, if the extension specified in this document is in use, which employs key material from the Diffie-Hellman procedure if the extens
employs key material from the Diffie-Hellman procedure.</t> ion specified in this document is in use.</t>
</section> </section>
<section title="EAP-Response/AKA'-Reauthentication">
<t>No changes, but as discussed in <xref target="reauth"/>,
re-authentication is based on the key material generated by
EAP-AKA' and the extension defined in this document.</t>
</section>
<section title="EAP-Response/AKA'-Synchronization-Failure">
<t>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 a received message MUST be ignored.<
/t>
</section>
<section title="EAP-Response/AKA'-Authentication-Reject"> <section numbered="true" toc="default">
<t>No changes, except that the AT_KDF_FS or AT_PUB_ECDHE <name>EAP-Response/AKA'-Reauthentication</name>
attributes MUST NOT be added to this message. <t>There are no changes for the EAP-Response/AKA'-Reauthentication,
The appearance of these attributes in a received message MUST be ignored.< but as discussed in <xref target="reauth" format="default"/>,
/t> re-authentication is based on the key material generated by EAP-AKA'
</section> and the extension defined in this document.</t>
</section>
<section title="EAP-Response/AKA'-Client-Error"> <section numbered="true" toc="default">
<t>No changes, except that the AT_KDF_FS or AT_PUB_ECDHE <name>EAP-Response/AKA'-Synchronization-Failure</name>
attributes MUST NOT be added to this message. <t>There are no changes for the
The appearance of these attributes in a received message MUST be ignored.< EAP-Response/AKA'-Synchronization-Failure, except that the AT_KDF_FS
/t> or AT_PUB_ECDHE attributes <bcp14>MUST NOT</bcp14> be added to this
</section> message. The appearance of these attributes in a received message
<bcp14>MUST</bcp14> be ignored.</t>
</section>
<section title="EAP-Request/AKA'-Notification"> <section numbered="true" toc="default">
<t>No changes.</t> <name>EAP-Response/AKA'-Authentication-Reject</name>
</section> <t>There are no changes for the
EAP-Response/AKA'-Authentication-Reject, except that the AT_KDF_FS
or AT_PUB_ECDHE attributes <bcp14>MUST NOT</bcp14> be added to this
message. The appearance of these attributes in a received message
<bcp14>MUST</bcp14> be ignored.</t>
</section>
<section title="EAP-Response/AKA'-Notification"> <section numbered="true" toc="default">
<t>No changes.</t> <name>EAP-Response/AKA'-Client-Error</name>
<t> changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes
<bcp14>MUST NOT</bcp14> be added to this message. The appearance of
these attributes in a received message <bcp14>MUST</bcp14> be
ignored.</t>
</section>
<section numbered="true" toc="default">
<name>EAP-Request/AKA'-Notification</name>
<t>There are no changes for the EAP-Request/AKA'-Notification.</t>
</section>
<section numbered="true" toc="default">
<name>EAP-Response/AKA'-Notification</name>
<t>There are no changes for the EAP-Request/AKA'-Notification.</t>
</section>
</section>
</section> </section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
</section> <t>This section deals only with changes to security considerations for
</section> EAP-AKA' or new information that has been gathered since the publication
of <xref target="RFC9048" format="default"/>.</t>
<section title="Security Considerations"> <t>As discussed in <xref target="sec_intro" format="default"/>, FS is an i
mportant countermeasure against adversaries who gain
<t>This section deals only with the changes to security considerations access to long-term keys. The long-term keys can be best protected
as they differ from EAP-AKA', or as new information has been gathered with good processes, e.g., restricting access to the key material within
since the publication of <xref target="RFC9048"/>.</t> a factory or among personnel, etc. Even so, not all attacks can be
entirely ruled out. For instance, well-resourced adversaries may be able
<t>As discussed in <xref target="sec:intro"/>, to coerce insiders to collaborate, despite any technical protection
forward secrecy is an important countermeasure against adversaries measures. The zero trust principles suggest that we assume that
who gain access to the long-term keys. breaches are inevitable or have potentially already occurred and that
The long-term keys can be best protected with good processes, we need to minimize the impact of these breaches (see <xref target="NSA-ZT
e.g., restricting access to the key material within a factory or "
among personnel, etc. format="default"/> and <xref target="NIST-ZT" format="default"/>). One typ
Even so, not all attacks can e
be entirely ruled out. For instance, well-resourced adversaries of breach is key compromise or key exfiltration.</t>
may be able to coerce insiders to collaborate, despite any
technical protection measures.
The zero trust principles suggest that we assume that breaches are
inevitable or have potentially already occurred, and that we need to
minimize the impact of these breaches
<xref target="NSA-ZT"/> <xref target="NIST-ZT"/>.
One type of breach is key compromise or key exfiltration.</t>
<t>If a mechanism without ephemeral key exchange such as (5G-AKA, <t>If a mechanism without ephemeral key exchange (such as 5G-AKA or
EAP-AKA') is used the effects of key compromise are devastating. EAP-AKA') is used, the effects of key compromise are devastating. There
There are serious consequences of not properly providing forward secrecy are serious consequences to not properly providing FS for
for the key establishment. For both control and user plane, and both direct the key establishment, for the control plane and the user plane, and for
ions: both directions:
<list style="numbers"> </t>
<t>An attacker can decrypt 5G communication that they <ol spacing="normal" type="1"><li>
<t>An attacker can decrypt 5G communication that they
previously recorded.</t> previously recorded.</t>
<t>A passive attacker can eavesdrop (decrypt) all </li>
<li>
<t>A passive attacker can eavesdrop (decrypt) all
future 5G communication.</t> future 5G communication.</t>
<t>An active attacker can impersonate the UE or the </li>
Network and inject messages in an ongoing 5G connection between <li>
<t>An active attacker can impersonate the User Equipment (UE) or the
network and inject messages in an ongoing 5G connection between
the real UE and the real network.</t> the real UE and the real network.</t>
</list> </li>
</t> </ol>
<t>At the time of writing, best practice security is to mandate FS (as is
<t>Best practice security today is to mandate forward secrecy (as done in Wi-Fi Protected Access 3 (WPA3), EAP-TLS 1.3, EAP-TTLS 1.3,
is done in WPA3, EAP-TLS 1.3, EAP-TTLS 1.3, IKEv2, SSH, QUIC, Internet Key Exchange Protocol Version 2 (IKEv2), Secure Shell (SSH),
WireGuard, Signal, etc.). It is recommended that in deployments, QUIC, WireGuard, Signal, etc.). In deployments, it is recommended that
EAP-AKA methods without forward secrecy be phased out in the long EAP-AKA methods without FS be phased out in the long
term.</t> term.</t>
<t>This extension provide assistance against passive attacks from
attackers that have compromised the key material on USIM cards.
Passive attacks are attractive for attackers performing large
scale pervasive monitoring as they require much less resources
and are much harder to detect. The extension also
provides protection against active attacks as the attacker is forced to
be on path during the AKA run and subsequent
communication between the parties. Without forward secrecy an
active attacker that has compromised the long-term key can
inject messages in an connection between the real Peer and the
real server without being on path. This extension is most
useful when used in a context where the MSK/EMSK are used in
protocols not providing forward secrecy. For
instance, if used with IKEv2 <xref target="RFC7296"/>, the
session keys produced by IKEv2 have this property, so better
characteristics of the MSK and EMSK is not that useful. However,
typical
link layer usage of EAP does not involve running another, forward secure,
key exchange. Therefore, using EAP to authenticate access to a network is on
e situation
where the extension defined in this document can be helpful.</t>
<t>This extension generates keying material using the ECDHE <t>The FS extension provides assistance against passive attacks from
attackers that have compromised the key material on USIM cards. Passive
attacks are attractive for attackers performing large-scale pervasive
monitoring as they require far fewer resources and are much harder to
detect. The extension also provides protection against active attacks as
the attacker is forced to be on-path during the AKA run and subsequent
communication between the parties. Without FS, an active attacker that
has compromised the long-term key can inject messages in a connection
between the real Peer and the real Server without being on-path. This
extension is most useful when implemented in a context where the MSK or
EMSK are used in protocols not providing FS. For instance, if used with
IKEv2 <xref target="RFC7296" format="default"/>, the session keys
produced by IKEv2 will in any case have this property, so the
improvements from the use of EAP-AKA' FS are not that useful. However,
typical link-layer usage of EAP does not involve running another key excha
nge with forward secrecy. Therefore, using EAP to authenticate
access to a network is one situation where the extension defined in this
document can be helpful.</t>
<t>The FS extension generates key material using the ECDHE
exchange in order to gain the FS property. This means that once exchange in order to gain the FS property. This means that once
an EAP-AKA' authentication run ends, the session that it was used an EAP-AKA' authentication run ends, the session that it was used
to protect is closed, and the corresponding keys are destroyed, to protect is closed, and the corresponding keys are destroyed. Even someone
even someone who has recorded all of the data from the who has recorded all of the data from the
authentication run and session and gets access to all of the AKA authentication run and session and gets access to all of the AKA
long-term keys cannot reconstruct the keys used to protect the long-term keys cannot reconstruct the keys used to protect the
session or any previous session, without doing a brute force session or any previous session, without doing a brute-force
search of the session key space.</t> search of the session key space.</t>
<t>Even if a compromise of the long-term keys has occurred, FS is
<t>Even if a compromise of the long-term keys has occurred, FS is
still provided for all future sessions, as long as the attacker still provided for all future sessions, as long as the attacker
does not become an active attacker.</t> does not become an active attacker.</t>
<t>The extension does not provide protection against active attackers that
mount an on-path attack on future EAP-AKA' runs and have access to the
long-term key. They 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.</t>
<t>The extension does not provide protection against active attackers with a <t>Using EAP-AKA' FS once provides FS. FS limits the effect of key leakage
ccess to the long-term key that mount in one direction (compromise of a key at time T2 does not compromise some
an on-path attack on future EAP-AKA' runs will be able to eavesdrop on the key at time T1 where T1 &lt; T2). Protection in the other direction
traffic protected by the resulting session key(s). Still, past sessions (compromise at time T1 does not compromise keys at time T2) can be
where FS was in use remain protected.</t> achieved by rerunning ECDHE frequently. If a long-term authentication key
has been compromised, rerunning EAP-AKA' FS gives protection against
<t>Using EAP-AKA' FS once provides forward secrecy. Forward secrecy limits t passive attackers. Using the terms in <xref target="RFC7624"
he format="default"/>, FS without rerunning ECDHE does not stop an attacker
effect of key leakage in one direction (compromise of a key at time T2 do from doing static key exfiltration. Frequently rerunning EC(DHE) forces an
es attacker to do dynamic key exfiltration (or content exfiltration).</t>
not compromise some key at time T1 where T1 &lt; T2). Protection in the o
ther
direction (compromise at time T1 does not compromise keys at time T2) can
be achieved by rerunning ECDHE frequently. If a long-term authentication
key
has been compromised, rerunning EAP-AKA' FS gives protection against pass
ive
attackers. Using the terms in <xref target="RFC7624"/>, forward secrecy w
ithout rerunning
ECDHE does not stop an attacker from doing static key exfiltration. Frequ
ently
rerunning EC(DHE) forces an attacker to do dynamic key exfiltration
(or content exfiltration).</t>
<section title="Deployment Considerations">
<t>Achieving FS requires that when a connection is closed, each <section numbered="true" toc="default">
endpoint MUST destroy not only the ephemeral keys used by the <name>Deployment Considerations</name>
<t>Achieving FS requires that, when a connection is closed, each
endpoint <bcp14>MUST</bcp14> destroy not only the ephemeral keys used by the
connection but also any information that could be used to connection but also any information that could be used to
recompute those keys.</t> recompute those keys.</t>
<t>Similarly, other parts of the system matter. For instance, when the k
<t>Similarly, other parts of the system matter. For instance, when the keys eys generated by EAP are transported to a
generated by EAP are transported to a pass-through authenticator, such transport must also provide forward se
pass-through authenticator, such transport must also provide forward cure encryption with respect to the long-term keys used to establish
secure encryption with respect to the long-term keys used to establish
its security. Otherwise, an adversary may attack the transport connecti on its security. Otherwise, an adversary may attack the transport connecti on
used to carry keys from EAP, and use this method to gain access to curre nt and past used to carry keys from EAP, and use this method to gain access to curre nt and past
keys from EAP, which in turn would lead to the compromise of anything pro keys from EAP, which, in turn, would lead to the compromise of anything p
tected by those EAP keys.</t> rotected by those EAP keys.</t>
<t>Of course, these considerations
<t>Of course, these considerations
apply to any EAP method, not only this one.</t> apply to any EAP method, not only this one.</t>
</section>
<section numbered="true" toc="default">
<name>Security Properties</name>
<t>The following security properties of
EAP-AKA' are impacted through this extension:</t>
</section> <dl newline="true" spacing="normal">
<dt>Protected ciphersuite negotiation:</dt>
<section title="Security Properties"> <dd>
<t>EAP-AKA' has a negotiation mechanism for selecting the KDFs, and
<t>The following security properties of this mechanism has been extended by the
EAP-AKA' are impacted through this extension: extension specified in this document. The resulting mechanism
continues to be secure against bidding-down attacks.</t>
<list style="hanging"> <t>There are two specific needs in the negotiation mechanism:</t>
<dl newline="true" spacing="normal">
<t hangText="Protected ciphersuite negotiation"><vspace blankLines="1"/> <dt>Negotiating KDFs within the extension:</dt>
<dd>
EAP-AKA' has a negotiation mechanism for selecting the key The negotiation mechanism allows changing the offered KDF, but the chang
derivation functions, and this mechanism has been extended by e is visible in the final
the extension specified in this document. The resulting EAP-Request/AKA'-Challenge message that the Server sends to the Peer.
mechanism continues to be secure against bidding down This message is authenticated via the AT_MAC attribute, and carries
attacks. both the chosen alternative and the initially offered list. The Peer
<vspace blankLines="1"/> refuses to accept a change it did not initiate. As a result, both
parties are aware that a change is being made and what the original
There are two specific needs in the negotiation mechanism: offer was.</dd>
<list style="hanging"> <dt>Negotiating the use of this extension:</dt>
<dd>
<t hangText="Negotiating key derivation function within the extension">< <t> This extension is offered by the Server through presenting
vspace blankLines="1"/> the AT_KDF_FS and AT_PUB_ECDHE attributes in the
The negotiation mechanism allows changing the offered key EAP-Request/AKA'-Challenge message. These attributes are
derivation function, but the change is visible in the final EAP- protected by AT_MAC, so attempts to change or omit them by an
Request/AKA'-Challenge message that the server sends to the peer. adversary will be detected.</t>
This message is authenticated via the AT_MAC attribute, and
carries both the chosen alternative and the initially offered
list. The peer refuses to accept a change it did not initiate.
As a result, both parties are aware that a change is being made
and what the original offer was.</t>
<t hangText="Negotiating the use of this extension"><vspace
blankLines="1"/> This extension is offered by the server
through presenting the AT_KDF_FS and AT_PUB_ECDHE attributes in
the EAP-Request/AKA'-Challenge message. These attributes are
protected by AT_MAC, so attempts to change or omit them by an
adversary will be detected.<vspace blankLines="1"/>
Except of course, if the adversary holds the long-term key
and is willing to engage in an active attack. Such an
attack can, for instance, forge the negotiation process so
that no FS will be provided. However, as noted above, an
attacker with these capabilities will in any case be able to
impersonate any party in the protocol and perform on-path
attacks. That is not a situation that can be improved by a
technical solution. However, as discussed in the introduction,
even an attacker with access to the long-term keys is required
to be on path on each AKA run and subsequent communication,
which makes mass surveillance more laborious.
<vspace blankLines="1"/>
The security properties of the extension also depend on a
policy choice. As discussed in <xref
target="procakachallresp"/>, both the peer and the server make
a policy decision of what to do when it was willing to perform
the extension specified in this protocol, but the other side
does not wish to use the extension. Allowing this has the
benefit of allowing backwards compatibility to equipment that
did not yet support the extension. When the extension is not
supported or negotiated by the parties, no FS can obviously be
provided.
<vspace blankLines="1"/>
If turning off the extension specified in this protocol is not
allowed by policy, the use of legacy equipment that does not
support this protocol is no longer possible. This may be
appropriate when, for instance, support for the extension is
sufficiently widespread, or required in a particular version
of a mobile network.</t>
</list></t>
<t hangText="Key derivation"><vspace blankLines="1"/>
This extension provides forward secrecy. As described in several
places in this specification, this can be roughly summarized as
that an attacker with access
to long-term keys is unable to obtain session keys of ended past
sessions, assuming these sessions deleted all relevant session key materia
l.
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 key as the
original authentication.</t>
</list></t>
</section>
<section title="Denial-of-Service">
<t>In addition, it is worthwhile to discuss Denial-of-Service
attacks and their impact on this protocol. The calculations involved
in public key cryptography require computing power, which could be
used in an attack to overpower either the peer or the server. While
some forms of Denial-of-Service attacks are always possible, the
following factors help mitigate the concerns relating to public key
cryptography and EAP-AKA' FS.
<list style="symbols">
<t>In 5G context, other parts of the connection setup involve <t>These attempts will be detected, except of course, if the
public key cryptography, so while performing additional operations adversary holds the long-term key and is willing to engage in
in EAP-AKA' is an additional concern, it does not change the an active attack. For instance, such an attack can forge the neg
overall situation. As a result, the relevant system components otiation
need to be dimensioned appropriately, and detection and management process so that no FS will be provided. However, as noted
mechanisms to reduce the effect of attacks need to be in above, an attacker with these capabilities will, in any case,
place.</t> be able to impersonate any party in the protocol and perform
on-path attacks. That is not a situation that can be improved
by a technical solution. However, as discussed in the
Introduction, even an attacker with access to the long-term
keys is required to be on-path on each AKA run and subsequent
communication, which makes mass surveillance more laborious.
</t>
<t>
The security properties of the extension also depend on a
policy choice. As discussed in <xref
target="procakachallresp" format="default"/>, both the Peer
and the Server make a policy decision of what to do when it
was willing to perform the extension specified in this
protocol, but the other side does not wish to use the
extension. Allowing this has the benefit of allowing
backwards compatibility to equipment that did not yet
support the extension. When the extension is not supported
or negotiated by the parties, no FS can obviously be
provided.
</t>
<t>
If turning off the extension specified in this protocol is
not allowed by policy, the use of legacy equipment that does
not support this protocol is no longer possible. This may be
appropriate when, for instance, support for the extension is
sufficiently widespread or required in a particular version
of a mobile network.
</t>
</dd>
</dl>
</dd>
<dt>Key derivation:</dt>
<dd>This extension provides FS. As described in several places in
this specification, this can be roughly summarized as follows: an
attacker with access to long-term keys is unable to obtain session
keys of ended past sessions, assuming these sessions deleted all
relevant session key material. 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;
hence, they continue to be equally safe against exposure of the
long-term key as the original authentication.</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>Denial of Service</name>
<t>It is worthwhile to discuss Denial-of-Service (DoS) attacks and
their impact on this protocol. The calculations involved in public key
cryptography require computing power, which could be used in an attack
to overpower either the Peer or the Server. While some forms of DoS
attacks are always possible, the following factors help mitigate the
concerns relating to public key cryptography and EAP-AKA' FS.
<t>This specification is constructed so that a separation </t>
between the USIM and Peer on client side and the Server and AD on <ul spacing="normal">
network side is possible. This ensures that the most sensitive (or <li>
legacy) system components cannot be the target of the attack. For <t>In a 5G context, other parts of the connection setup involve
instance, EAP-AKA' and public key cryptography takes place in the public key cryptography, so while performing additional operations
phone and not the low-power USIM card.</t> in EAP-AKA' is an additional concern, it does not change the
overall situation. As a result, the relevant system components
need to be dimensioned appropriately, and detection and management
mechanisms to reduce the effect of attacks need to be in
place.</t>
</li>
<t>EAP-AKA' has been designed so that the first actual message in <li>
<t>This specification is constructed so that it is possible to
have a separation between the USIM and Peer on the client side and
between the Server and AD on the network side. This ensures that
the most sensitive (or legacy) system components cannot be the
target of the attack. For instance, EAP-AKA' and public key
cryptography both take place in the phone and not the low-power
USIM card.</t>
</li>
<li>
<t>EAP-AKA' has been designed so that the first actual message in
the authentication process comes from the Server, and that this the authentication process comes from the Server, and that this
message will not be sent unless the user has been identified as message will not be sent unless the user has been identified as
an active subscriber of the operator in question. While the initial identity an active subscriber of the operator in question. While the initial identity
can be spoofed before authentication has succeeded, this reduces the efficie ncy of can be spoofed before authentication has succeeded, this reduces the efficie ncy of
an attack.</t> an attack.</t>
</li>
<t>Finally, this memo specifies an order in which computations and <li>
checks must occur. When processing the EAP-Request/AKA'-Challenge <t>Finally, this memo specifies an order in which computations and
message, for instance, the AKA authentication must be checked and checks must occur. For instance, when processing the EAP-Request/AKA'-Challe
succeed before the peer proceeds to calculating or processing the nge
FS related parameters (see <xref message, the AKA authentication must be checked and
target="procakachallresp"/>). The same is true of succeed before the Peer proceeds to calculating or processing the
EAP-Response/AKA'-Challenge (see <xref FS-related parameters (see <xref target="procakachallresp" format="default"/
target="procakachallresp"/>). This ensures that the parties need to >). The same is true of an
EAP-Response/AKA'-Challenge (see <xref target="procakachallresp" format="def
ault"/>). This ensures that the parties need to
show possession of the long-term key in some way, and only then show possession of the long-term key in some way, and only then
will the FS calculations become active. This limits the will the FS calculations become active. This limits the
Denial-of-Service to specific, identified subscribers. While DoS to specific, identified subscribers. While
botnets and other forms of malicious parties could take advantage botnets and other forms of malicious parties could take advantage
of actual subscribers and their key material, at least such of actual subscribers and their key material, at least such
attacks are (a) limited in terms of subscribers they control, and attacks are:</t>
(b) identifiable for the purposes of blocking the affected <ol type="a"><li>limited in terms of subscribers they control, and</li>
subscribers.</t> <li>identifiable for the purposes of blocking the affected
subscribers.</li></ol>
</list></t> </li>
</ul>
</section> </section>
<section title="Identity Privacy"> <section numbered="true" toc="default">
<t>As specified in <xref target="secMessageProc"/>, the peer identity sent <name>Identity Privacy</name>
<t>As specified in <xref target="secMessageProc" format="default"/>, the
Peer identity sent
in the Identity Response message needs in the Identity Response message needs
to follow the privacy-friendly requirements in <xref target="RFC9190"/>.< to follow the privacy-friendly requirements in <xref target="RFC9190" for
/t> mat="default"/>.</t>
</section> </section>
<section anchor="unp" numbered="true" toc="default">
<section anchor="unp" title="Unprotected Data and Privacy"> <name>Unprotected Data and Privacy</name>
<t>Unprotected data and metadata can reveal sensitive information and need to <t>Unprotected data and metadata can reveal sensitive information and ne
be selected with care. ed to be selected with care.
In particular, this applies to In particular, this applies to
AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF_FS, and AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF_FS, and
AT_PUB_ECDHE reveal the used cryptographic algorithms, if these depend on the AT_PUB_ECDHE reveal the used cryptographic algorithms; if these depend on the
peer identity they leak information about the peer. AT_KDF_INPUT reveals the Peer identity, they leak information about the Peer. AT_KDF_INPUT reveals the
network name, although that is done on purpose to bind the authentication to a particular context.</t> network name, although that is done on purpose to bind the authentication to a particular context.</t>
<t>An attacker observing network traffic may use the above types of info
<t>An attacker observing network traffic may use the above types of informati rmation
on
for traffic flow analysis or to track an endpoint.</t> for traffic flow analysis or to track an endpoint.</t>
</section> </section>
<section numbered="true" toc="default">
<section title="Forward Secrecy within AT_ENCR"> <name>Forward Secrecy within AT_ENCR</name>
<t>The keys K_encr and K_aut are calculated and used before the shared s
<t>They keys K_encr and K_aut are calculated and used before the shared sec ecret from the ephemeral
ret from the ephemeral
key exchange is available.</t> key exchange is available.</t>
<t>K_encr and K_aut are used to encrypt and MAC data in the EAP-Req/AKA'-Ch <t>K_encr and K_aut are used to encrypt and calculate a MAC in the
allenge message, EAP-Req/AKA'-Challenge message, especially the DH g<sup>x</sup>
especially the DH g^x ephemeral pub key. At that point the server does not ephemeral pub key. At that point, the Server does not yet have the
yet have the corresponding g<sup>y</sup> from the Peer and cannot compute the
corresponding g^y from the peer and cannot compute the shared secret. K_aut shared secret. K_aut is then used as the authentication key for the
is shared secret.</t>
then used as the authentication key for the shared secret.</t>
<t>For K_encr though, none of the encrypted data sent in the
EAP-Req/AKA'-Challenge message in the AT_ENCR attribute will be forward sec
ret. 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 E
AP-AKA'
authentication. No such linking would be possible across different full aut
hentaction
runs. If the pseudonum linkage risk is not acceptable, one way to avoid the
linkage is
to always require full EAP-AKA' authentication.</t>
</section>
<section title="Post-Quantum Considerations">
<t>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.</t>
<t>This would not affect the ability of EAP-AKA' - with or without <t>However, for K_encr, none of the encrypted data sent in the
this extension - EAP-Req/AKA'-Challenge message in the AT_ENCR attribute will be a
to authenticate properly, however. As symmetric key cryptography is safe even forward secret. That data may include re-authentication pseudonyms, so
if CRQCs are built, an adversary still will not be able to disrupt authentica an adversary compromising the long-term key would be able to link
tion re-authentication protocol runs when pseudonyms are used, within a
as it requires computing a correct AT_MAC value. This computation requires th sequence of runs followed after a full EAP-AKA' authentication. No
e K_aut key such linking would be possible across different full authentication
which is based on MK and, ultimately, CK' and IK', but not SHARED_SECRET.</t> runs. If the pseudonym linkage risk is not acceptable, one way to
avoid the linkage is to always require full EAP-AKA'
authentication.</t>
</section>
<section numbered="true" toc="default">
<name>Post-Quantum Considerations</name>
<t>As of the publication of this document, it is unclear when or even
if a quantum computer of sufficient size and power to exploit ECC will e
xist. Deployments that need to consider
risks decades into the future should transition to Post-Quantum Cryptogr
aphy (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 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.</t>
<t>Other output keys do include SHARED_SECRET via MK_ECDHE, but still include <t>However, this would not affect the ability of EAP-AKA', with or
also without this extension, to authenticate properly. As symmetric key
CK' and IK' which are entirely based on symmetric cryptography. As a result, cryptography is safe even if CRQCs are built, an adversary still will
an adversary with a quantum computer still cannot compute the other output ke not be able to disrupt authentication as it requires computing a
ys either.</t> correct AT_MAC value. This computation requires the K_aut key, which is
based on the MK, CK', and IK', but not SHARED_SECRET.</t>
<t>Other output keys do include SHARED_SECRET via MK_ECDHE, but they sti
ll include the CK' and IK', which are entirely based on symmetric cryptography.
As a result,
an adversary with a quantum computer still cannot compute the other outpu
t keys either.</t>
<t>However, if the adversary has also obtained knowledge of the long-term key <t>However, if the adversary has also obtained knowledge of the long-ter
, they m key, they
could then compute CK', IK', and SHARED_SECRET, and any derived output keys. could then compute the CK', IK', SHARED_SECRET, and any derived output keys.
This means that This means that
the introduction of a powerful enough quantum computer would disable the introduction of a powerful enough quantum computer would disable
this protocol extension's ability to provide the forward security this protocol extension's ability to provide the forward secrecy
capability. This would capability. This would
make it necessary to update the current ECC algorithms in this document to PQ C algorithms. This make it necessary to update the current ECC algorithms in this document to PQ C algorithms. This
document does not add such algorithms, but a future update can do that. document does not add such algorithms, but a future update can do that.
</t> </t>
<t>Symmetric algorithms used in EAP-AKA' FS, such as HMAC-SHA-256 and
<t>Symmetric algorithms used in EAP-AKA' FS such as HMAC-SHA-256 the algorithms used to generate AT_AUTN and AT_RES, are practically
and the algorithms use to generate AT_AUTN and AT_RES are secure against even large, robust quantum computers. EAP-AKA' FS is
practically secure against even large robust quantum currently only specified for use with ECDHE key exchange algorithms,
computers. EAP-AKA' FS is currently only specified for use but use of any Key Encapsulation Method (KEM), including PQC KEMs, can
with ECDHE key exchange algorithms, but use of any Key be specified in the future. While the key exchange is specified with
Encapsulation Method (KEM), including Post-Quantum Cryptography terms of the Diffie-Hellman protocol, the key exchange adheres to a
(PQC) KEMs, can be specified in the future. While the key exchange is KEM interface. AT_PUB_ECDHE would then contain either the ephemeral
specified with terms of the Diffie-Hellman protocol, the key exchange public key of the Server or the SHARED_SECRET encapsulated with the
adheres to a KEM interface. AT_PUB_ECDHE would then contain Server's public key. Note that the use of a KEM might require other
either the ephemeral public key of the server or the SHARED_SECRET changes, such as including the ephemeral public key of the Server in
encapsulated with the server's public key. Note that the use of a the key derivation to retain the property that both parties contribute
KEM might require other changes such as including the ephemeral randomness to the session key.
public key of the server in the key derivation to retain the property </t>
that both parties contribute randomness to the session key. </section>
</t> </section>
</section> <section numbered="true" toc="default">
<name>IANA Considerations</name>
</section> <t>This extension of EAP-AKA' shares its attribute space and subtypes
with the following:</t>
<ul>
<li>"Extensible Authentication Protocol Method for Global System for
Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)" <xref
target="RFC4186" format="default"/>,</li>
<li>"Extensible Authentication Protocol
Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)"
<xref target="RFC4187" format="default"/>, and</li>
<li>"Improved Extensible
Authentication Protocol Method for 3GPP Mobile Network Authentication
and Key Agreement (EAP-AKA')" <xref target="RFC9048"
format="default"/>.</li></ul>
<section title="IANA Considerations"> <t>IANA has assigned two new values in the "Attribute Types (Skippable
Attributes 128-255)" registry under the "EAP-AKA and EAP-SIM Parameters"
group as follows:</t>
<t>This extension of EAP-AKA' shares its attribute space and subtypes with <dl>
Extensible Authentication Protocol Method for Global System for Mobile Communi <dt>152:</dt><dd>AT_PUB_ECDHE (<xref target="at_pub_dh"
cations (GSM) format="default"/>)</dd>
Subscriber Identity Modules (EAP-SIM) <dt>153:</dt><dd>AT_KDF_FS (<xref target="at_kdf_dh" format="default"/>)</dd>
<xref target="RFC4186"/>, EAP-AKA <xref target="RFC4187"/>, and </dl>
EAP-AKA' <xref target="RFC9048"/>.</t>
<t>Two new values (TBA1, TBA2) in the skippable <t>IANA has also created the "EAP-AKA' AT_KDF_FS
range need to be assigned for AT_PUB_ECDHE (<xref target="at_pub_dh"/>) Key Derivation Function Values" registry to represent FS KDF
and AT_KDF_FS (<xref target="at_kdf_dh"/>) types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA' with ECDHE and
in the "Attribute Types" registry under the "EAP-AKA and EAP-SIM Parameters" g P-256" types (1 and 2, see <xref target="kdf2" format="default"/>) have be
roup.</t> en assigned, along with one reserved value. The initial contents of
this registry are illustrated in <xref target="iana-fs-values"
format="default"/>; new values can be created through the Specification
Required policy <xref target="RFC8126" format="default"/>. Expert
reviewers should ensure that the referenced specification is clearly
identified and stable and that the proposed addition is reasonable for
the given category of allocation.
</t>
<table anchor="iana-fs-values">
<name>EAP-AKA' AT_KDF_FS Key Derivation Function Values Registry Initial
Contents</name>
<thead>
<tr>
<th align="left">Value</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="left">Reserved</td>
<td align="left">RFC 9678</td>
</tr>
<tr>
<td align="left">1</td>
<td align="left">EAP-AKA' with ECDHE and X25519</td>
<td align="left">RFC 9678</td>
</tr>
<tr>
<td align="left">2</td>
<td align="left">EAP-AKA' with ECDHE and P-256</td>
<td align="left">RFC 9678</td>
</tr>
<tr>
<td align="left">3-65535</td>
<td align="left">Unassigned</td>
<td align="left">RFC 9678</td>
</tr>
</tbody>
</table>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
748.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
187.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
448.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
624.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
748.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
048.xml"/>
<t>Also, IANA is requested to create a new registry "EAP-AKA' AT_KDF_FS Key De <reference anchor="SP-800-186" target="https://doi.org/10.6028/NIST.SP.8
rivation Function Values" 00-186">
to represent <front>
FS Key Derivation Function types. The "EAP-AKA' with <title>Recommendations for Discrete Logarithm-based Cryptography: El
ECDHE and X25519" and "EAP-AKA' with ECDHE and P-256" liptic Curve Domain Parameters</title>
types (1 and 2, see <xref target="kdf2"/>) need to be assigned, <author initials="L." surname="Chen">
along with one reserved value. The initial contents of this <organization>National Institute of Standards and Technology</orga
registry is illustrated in <xref target="iana-fs-values"/>; new values can be nization>
created through </author>
the Specification Required policy <xref target="RFC8126"/>. <author initials="D." surname="Moody"/>
Expert reviewers should ensure that the referenced specification is <author initials="K." surname="Randall"/>
clearly identified and stable, and that the proposed addition is <author initials="A." surname="Regenscheid"/>
reasonable for the given category of allocation. <author initials="A." surname="Robinson"/>
</t> <date month="February" year="2023"/>
</front>
<seriesInfo name="NIST" value="SP 800-186"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-186"/>
</reference>
<table anchor="iana-fs-values"> <reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf">
<name>Initial Content of the EAP-AKA' AT_KDF_FS Key Derivation Functio <front>
n Values Registry</name> <title>SEC 1: Elliptic Curve Cryptography</title>
<thead> <author>
<tr> <organization>Standards for Efficient Cryptography</organization>
<th align="left">Value</th> </author>
<th align="left">Description</th> <date month="May" year="2009"/>
<th align="left">Reference</th> </front>
</tr> <refcontent>Version 2.0</refcontent>
</thead> </reference>
<tbody>
<tr>
<td align="left">0</td>
<td align="left">Reserved</td>
<td align="left">[TBD BY IANA: THIS RFC]</td>
</tr>
<tr>
<td align="left">1</td>
<td align="left">EAP-AKA' with ECDHE and X25519</td>
<td align="left">[TBD BY IANA: THIS RFC]</td>
</tr>
<tr>
<td align="left">2</td>
<td align="left">EAP-AKA' with ECDHE and P-256</td>
<td align="left">[TBD BY IANA: THIS RFC]</td>
</tr>
<tr>
<td align="left">3-65535</td>
<td align="left">Unassigned</td>
<td align="left">[TBD BY IANA: THIS RFC]</td>
</tr>
</tbody>
</table>
</section> <reference anchor="SEC2" target="https://www.secg.org/sec2-v2.pdf">
<front>
<title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
<author>
<organization>Standards for Efficient Cryptography</organization>
</author>
<date month="January" year="2010"/>
</front>
<refcontent>Version 2.0</refcontent>
</reference>
</middle> <reference anchor="SP-800-56A" target="https://doi.org/10.6028/NIST.SP.8
<back> 00-56Ar3">
<front>
<title>Recommendation for Pair-Wise Key-Establishment Schemes Using
Discrete Logarithm Cryptography</title>
<author initials="E." surname="Barker">
<organization>National Institute of Standards and Technology</orga
nization>
</author>
<author initials="L." surname="Chen">
<organization/>
</author>
<author initials="A." surname="Roginsky">
<organization/>
</author>
<author initials="A." surname="Vassilev">
<organization/>
</author>
<author initials="R." surname="Davis">
<organization/>
</author>
<date year="2018" month="April"/>
</front>
<seriesInfo name="NIST" value="SP 800-56A"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
</reference>
<references title="Normative References"> </references>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.3748.xml"?>
<?rfc include="reference.RFC.4187.xml"?>
<?rfc include="reference.RFC.5448.xml"?>
<?rfc include="reference.RFC.7624.xml"?>
<?rfc include="reference.RFC.7748.xml"?>
<?rfc include="reference.RFC.8126.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.RFC.9048.xml"?>
<reference anchor="SP-800-186">
<front>
<title>Recommendations for Discrete Logarithm-based Cryptography: Ellipt
ic Curve Domain Parameters</title>
<author>
<organization>NIST</organization>
</author>
<date month="February" year='2023'/>
</front>
<seriesInfo name="NIST" value="Special Publication 800-186"/>
<format type='HTML' target='https://doi.org/10.6028/NIST.SP.800-186'/>
</reference>
<reference anchor="SEC1">
<front>
<title>SEC 1: Elliptic Curve Cryptography</title>
<author>
<organization>Certicom Research</organization>
</author>
<date month="May" year='2009'/>
</front>
<seriesInfo name="Standards for Efficient Cryptography 1 (SEC 1)" value=
"Version 2.0" />
<format type='HTML' target='https://www.secg.org/sec1-v2.pdf'/>
</reference>
<reference anchor="SEC2">
<front>
<title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
<author>
<organization>Certicom Research</organization>
</author>
<date month="January" year='2010'/>
</front>
<seriesInfo name="Standards for Efficient Cryptography 2 (SEC 2)" value=
"Version 2.0" />
<format type='HTML' target='https://www.secg.org/sec2-v2.pdf'/>
</reference>
<reference anchor="SP-800-56A" target="https://doi.org/10.6028/NIST.SP.800-56Ar3
">
<front>
<title>Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete
Logarithm Cryptography</title>
<author initials="E." surname="Barker">
<organization></organization>
</author>
<author initials="L." surname="Chen">
<organization></organization>
</author>
<author initials="A." surname="Roginsky">
<organization></organization>
</author>
<author initials="A." surname="Vassilev">
<organization></organization>
</author>
<author initials="R." surname="Davis">
<organization></organization>
</author>
<date year="2018" month="April"/>
</front>
<seriesInfo name="NIST" value="Special Publication 800-56A Revision 3"/>
</reference>
</references>
<references title="Informative References"> <references>
<?rfc include="reference.RFC.4186.xml"?> <name>Informative References</name>
<?rfc include="reference.RFC.5216.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
<?rfc include="reference.RFC.7258.xml"?> 186.xml"/>
<?rfc include="reference.RFC.7296.xml"?> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<?rfc include="reference.RFC.9190.xml"?> 216.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
258.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
190.xml"/>
<reference anchor="TrustCom2015"> <reference anchor="TrustCom2015" target="https://doi.org/10.1109/Trustco
<front> m.2015.506">
<title>A USIM compatible 5G AKA protocol with perfect forward secrecy</tit <front>
le> <title>A USIM Compatible 5G AKA Protocol with Perfect Forward Secrec
<author initials="J." surname="Arkko"></author> y</title>
<author initials="K." surname="Norrman"></author> <author initials="J." surname="Arkko"/>
<author initials="M." surname="Näslund"></author> <author initials="K." surname="Norrman"/>
<author initials="B." surname="Sahlin"></author> <author initials="M." surname="Näslund"/>
<date month='August' year='2015'/> <author initials="B." surname="Sahlin"/>
</front> <date month="August" year="2015"/>
<seriesInfo name="Proceedings of IEEE International Conference on Trust, Sec </front>
urity and Privacy in Computing and Communications (TrustCom)" value="2015" /> <refcontent>IEEE International Conference on Trust, Security and
<format type='HTML' target='https://doi.org/10.1109/Trustcom.2015.506'/> Privacy in Computing and Communications (TrustCom)</refcontent>
</reference> <seriesInfo name="DOI" value="10.1109/Trustcom.2015.506"/>
</reference>
<reference anchor="Heist2015"> <reference anchor="Heist2015" target="https://theintercept.com/2015/02/1
<front> 9/great-sim-heist/">
<title>The Great SIM Heist</title> <front>
<author initials="J." surname="Scahill"></author> <title>The Great SIM Heist</title>
<author initials="J." surname="Begley"></author> <author initials="J." surname="Scahill"/>
<date month="February" year="2015"/> <author initials="J." surname="Begley"/>
</front> <date month="February" year="2015"/>
<format type='HTML' target='https://theintercept.com/2015/02/19/great-sim-he </front>
ist/'/> </reference>
</reference>
<reference anchor="DOW1992"> <reference anchor="DOW1992" target="https://doi.org/10.1007/BF00124891">
<front> <front>
<title>Authentication and Authenticated Key Exchanges</title> <title>Authentication and authenticated key exchanges</title>
<author initials="W." surname="Diffie"></author> <author initials="W." surname="Diffie"/>
<author initials="P." surname="Van Oorschot"></author> <author initials="P. C." surname="Van Oorschot"/>
<author initials="M." surname="Wiener"></author> <author initials="M. J." surname="Wiener"/>
<date month="June" year="1992"/> <date month="June" year="1992"/>
</front> </front>
<seriesInfo name="Designs, Codes and Cryptography 2" value="pp. 107-125" /> <refcontent>Designs, Codes and Cryptography, vol. 2, pp. 107-125</refc
<format type='HTML' target='https://doi.org/10.1007/BF00124891'/> ontent>
</reference> <seriesInfo name="DOI" value="10.1007/BF00124891"/>
</reference>
<reference anchor="TS.33.501"> <reference anchor="TS.33.501">
<front> <front>
<title>Security architecture and procedures for 5G System</title> <title>Security architecture and procedures for 5G System</title>
<author> <author>
<organization>3GPP</organization> <organization>3GPP</organization>
</author> </author>
<date month="March" year="2023" /> <date month="March" year="2023"/>
</front> </front>
<seriesInfo name="3GPP TS" value="33.501 18.1.0" /> <seriesInfo name="3GPP TS" value="33.501"/>
</reference> <refcontent>Version 18.1.0</refcontent>
</reference>
<reference anchor="NIST-ZT" target="https://www.nccoe.nist.gov/sites/def ault/files/2022-12/zta-nist-sp-1800-35b-preliminary-draft-2.pdf"> <reference anchor="NIST-ZT" target="https://www.nccoe.nist.gov/sites/def ault/files/2024-07/zta-nist-sp-1800-35-preliminary-draft-4.pdf">
<front> <front>
<title>Implementing a Zero Trust Architecture</title> <title>Implementing a Zero Trust Architecture</title>
<author initials="" surname="National Institute of Standards and Tec <author>
hnology"> <organization>National Institute of Standards and Technology</orga
<organization/> nization>
</author> </author>
<date year="2022" month="December"/> <date year="2024" month="July"/>
</front> </front>
<seriesInfo name="NIST" value="SP 1800-35"/>
</reference> </reference>
<reference anchor="NSA-ZT" target="https://media.defense.gov/2021/Feb/25 /2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF"> <reference anchor="NSA-ZT" target="https://media.defense.gov/2021/Feb/25 /2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF">
<front> <front>
<title>Embracing a Zero Trust Security Model</title> <title>Embracing a Zero Trust Security Model</title>
<author initials="" surname="National Security Agency"> <author>
<organization/> <organization>National Security Agency</organization>
</author> </author>
<date year="2021" month="February"/> <date year="2021" month="February"/>
</front> </front>
</reference> </reference>
</references> </references>
</references>
<section title="Change Log">
<t>RFC Editor: Please remove this appendix.</t>
<t>The -12 version of the WG draft has the following changes, most
due to IESG review comments in January 2023:
<list style="symbols">
<t>Update the draft track to Standards Track.</t>
<t>Clarified the calculation of the Length field in the AT_ECDHE
attribute, along with padding requirements.</t>
<t>Avoided the use of keywords in operational recommendations,
e.g., about deployment.</t>
<t>Changed the definition of what "supported" means to focus on feature bein
g implemented, but not require that it is usable during a protocol run, because
configuration, new security information, etc. might imply that a particular feat
ure is implemented but disabled for policy reasons.</t>
<t>Changed the MITM terminology to be on-path attacks.</t>
<t>Corrected a reference typo in the IANA considerations
section.</t>
<t>Shortened the abstract and introduction to the key aspects and removed du
plication.</t>
<t>Several editorial changes.</t>
</list></t>
<t>The -11 version of the WG draft has the following changes:
<list style="symbols">
<t>Addressed IETF Last Call comments from directorates, Security AD, Meiling
Cheng, and a detailed review from the author Karl. In particular:</t>
<t>Replaced the reference to the deprecated FIPS 186-4 with SP 800-186.</t>
<t>Changed HSS (Home Subscriber Server) to Authentication Database (AD) as H
SS is a 4G term.</t>
<t>Explained difference between EAP-AKA and EAP-AKA'</t>
<t>Explained that the emphemeral key exhange provide more that forward secre
cy and how this is important to mitigate pervasive monitoring.</t>
<t>Included links for the zero trust principles.</t>
<t>Explained why K_encr and K_auth not being protected by the ECDHE addition
.</t>
<t>Added that a future introduction of KEM might require additional changes.
</t>
<t>Explained how ephemeral key exchange is linked to pervasive monitoring.</
t>
<t>Changed SIM to USIM everywhere. A USIM is required for AKA.</t>
<t>Changed to long-term key instead of long-term secret or long-term shared
secret.</t>
<t>Reference updates.</t>
<t>Various editorial improvements.</t>
</list></t>
<t>The -10 version of the WG draft has the following changes:
<list style="symbols">
<t>Various nits found by Peter Yee.</t>
</list></t>
<t>The -09 version of the WG draft has the following changes:
<list style="symbols">
<t>Scalable Vector Graphics (SVG) versions for all figures has been added
and the figures has been slightly modified to render nicely with aasvg.</t>
<t>A reference has been added to the Section in SEC1 describing how
to do decompression.</t>
<t>The strengthened identity protection requirements are now mentioned in th
e
introduction.</t>
<t>Corrections and clarifications were made in the IANA considerations. The
table in the IANA section has been made into a proper xml table.</t>
<t>Reference updates.</t>
<t>Various editorial improvements.</t>
</list></t>
<t>The -08 version of the WG draft has the following changes:
<list style="symbols">
<t>Further clarification of key calculation in <xref
target="kdf2"/>.</t>
<t>Support for the NIST P-256 group has been made mandatory in
<xref target="groups"/>, in
order to align the requirements with 3GPP SUCI encryption
requirements.</t>
<t>The interaction between AT_KDF and AT_KDF_FS has been specified more
clearly, including specifying how future specifications need to specify
the treatment of new combinations.</t>
<t>Addition of a discussion about the impacts of potential future quantum
computing attacks with specific impacts to this extension.</t>
<t>Addition of a discussion about metadata/unprotected data in
<xref target="unp"/>.</t>
<t>Reference updates.</t>
<t>Various editorial improvements.</t>
</list></t>
<t>The -07 version of the WG draft has the following changes:
<list style="symbols">
<t>The impact of forward secrecy explanation has been improved in
the abstract and security considerations.</t>
<t>The draft now more forcefully explains why the authors believe
it is important to migrate existing systems to use forward
secrecy, and makes a recommendation for this migration.</t>
<t>The draft does no longer refer to issues within the smart cards but
rather the smart card supply chain.</t>
<t>The rationale for chosen algorithms is explained.</t>
<t>Also, the authors have checked the language relating to the
public value encoding, and believe it is exactly according to the
references (<xref target="RFC7748"/> Section 6.1 and <xref
target="SEC2"/> Section 2.7.1)</t>
</list></t>
<t>The -06 version of the WG draft is a refresh and a
reference update. However, the
following should be noted:
<list style="symbols">
<t>The draft now uses "forward secrecy" terminology and references
RFC 7624 per recommendations on mailing list discussion.</t>
<t>There's been mailing list discussion about the encoding of the
public values; the current text requires confirmation from the
working group that it is sufficient.</t>
</list>
</t>
<t>The -05 version of the WG draft takes into account feedback from
the working group list, about the number of bytes needed to encode
P-256 values.</t>
<t>The -04 version of the WG draft takes into account feedback from
the May 2020 WG interim meeting, correcting the reference to the
NIST P-256 specification.</t>
<t>The -03 version of the WG draft is first of all a refresh; there
are no issues that we think need addressing, beyond the one for
which there is a suggestion in -03: The document now suggests
an alternate group/curve as an optional one besides X25519. The
specific choice of particular groups and algorithms is still up to the
working group.</t>
<t>The -02 version of the WG draft took into account additional
reviews, and changed the document to update RFC 5448 (or rather, its
successor, <xref target="RFC9048"/>), changed the
wording of the recommendation with regards to the use of this
extension, clarified the references to the definition of X25519 and
Curve25519, clarified the distinction to ECDH methods that use
partially static keys, and simplified the use of AKA and USIM card
terminology. Some editorial changes were also made.</t>
<t>The -00 and -01 versions of the WG draft made no major
changes, only updates to some references.</t>
<t>The -05 version is merely a refresh while the draft was waiting
for WG adoption.</t>
<t>The -04 version of this draft made only editorial changes.</t>
<t>The -03 version of this draft changed the naming of various
protocol components, values, and notation to match with the use of
ECDH in ephemeral mode. The AT_KDF_FS negotiation process was
clarified in that exactly one key is ever sent in
AT_KDF_ECDHE. The option of checking for zero key values IN ECDHE
was added. The format of the actual key in AT_PUB_ECDHE was
specified. Denial-of-service considerations for the FS process
have been updated. Bidding down attacks against this extension
itself are discussed extensively. This version also addressed
comments from reviewers, including the August review from Mohit
Sethi, and comments made during IETF-102 discussion.</t>
</section>
<section numbered="no" title="Acknowledgments">
<t>The authors would like to note that the technical solution in
this document came out of the TrustCom paper <xref
target="TrustCom2015"/>, whose authors were <contact fullname="J. Arkko"/>,
<contact fullname="K. Norrman"/>,
<contact fullname="M. Näslund"/>,
and <contact fullname="B. Sahlin"/>. This document
uses also a lot of material from <xref target="RFC4187"/> by
<contact fullname="J. Arkko"/> and
<contact fullname="H. Haverinen"/> as well
as <xref target="RFC5448"/> by
<contact fullname="J. Arkko"/>,
<contact fullname="V. Lehtovirta"/>,
and <contact fullname="P. Eronen"/>.</t>
<t>The authors would also like to thank <section numbered="false" toc="default">
<contact fullname="Ben Campbell"/>, <name>Acknowledgments</name>
<contact fullname="Meiling Chen"/>, <t>The authors would like to note that the technical solution in this
<contact fullname="Roman Danyliw"/>, document came out of the TrustCom paper <xref target="TrustCom2015"
<contact fullname="Linda Dunbar"/>, format="default"/>, whose authors were <contact fullname="J. Arkko"/>,
<contact fullname="Tim Evans"/>, <contact fullname="K. Norrman"/>, <contact fullname="M. Näslund"/>, and
<contact fullname="Zhang Fu"/>, <contact fullname="B. Sahlin"/>. This document also uses a lot of
<contact fullname="Russ Housley"/>, material from <xref target="RFC4187" format="default"/> by <contact
<contact fullname="Tero Kivinen"/>, fullname="J. Arkko"/> and <contact fullname="H. Haverinen"/>, as well as
<contact fullname="Murray Kucherawy"/>, <xref target="RFC5448" format="default"/> by <contact
<contact fullname="Warren Kumari"/>, fullname="J. Arkko"/>, <contact fullname="V. Lehtovirta"/>, and <contact
<contact fullname="Eliot Lear"/>, fullname="P. Eronen"/>.</t>
<contact fullname="Vesa Lehtovirta"/>,
<contact fullname="Kathleen Moriarty"/>,
<contact fullname="Prajwol Kumar Nakarmi"/>,
<contact fullname="Francesca Palombini"/>,
<contact fullname="Anand R. Prasad"/>,
<contact fullname="Michael Richardson"/>,
<contact fullname="Göran Rune"/>,
<contact fullname="Bengt Sahlin"/>,
<contact fullname="Joseph Salowey"/>,
<contact fullname="Mohit Sethi"/>,
<contact fullname="Orie Steele"/>,
<contact fullname="Rene Struik"/>,
<contact fullname="Vesa Torvinen"/>,
<contact fullname="Sean Turner"/>,
<contact fullname="Helena Vahidi Mazinani"/>,
<contact fullname="Robert Wilton"/>,
<contact fullname="Paul Wouters"/>,
<contact fullname="Bo Wu"/>,
<contact fullname="Peter Yee"/>,
and many other people at the IETF, GSMA and 3GPP groups
for interesting discussions in this problem space.</t>
</section> <t>The authors would also like to thank <contact fullname="Ben
Campbell"/>, <contact fullname="Meiling Chen"/>, <contact
fullname="Roman Danyliw"/>, <contact fullname="Linda Dunbar"/>, <contact
fullname="Tim Evans"/>, <contact fullname="Zhang Fu"/>, <contact
fullname="Russ Housley"/>, <contact fullname="Tero Kivinen"/>, <contact
fullname="Murray Kucherawy"/>, <contact fullname="Warren Kumari"/>,
<contact fullname="Eliot Lear"/>, <contact fullname="Vesa Lehtovirta"/>,
<contact fullname="Kathleen Moriarty"/>, <contact fullname="Prajwol
Kumar Nakarmi"/>, <contact fullname="Francesca Palombini"/>, <contact
fullname="Anand R. Prasad"/>, <contact fullname="Michael Richardson"/>,
<contact fullname="Göran Rune"/>, <contact fullname="Bengt Sahlin"/>,
<contact fullname="Joseph Salowey"/>, <contact fullname="Mohit Sethi"/>,
<contact fullname="Orie Steele"/>, <contact fullname="Rene Struik"/>,
<contact fullname="Vesa Torvinen"/>, <contact fullname="Sean Turner"/>,
<contact fullname="Helena Vahidi Mazinani"/>, <contact fullname="Robert
Wilton"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Bo
Wu"/>, <contact fullname="Peter Yee"/>, and many other people at the
IETF, GSMA, and 3GPP groups for interesting discussions in this problem
space.</t>
</section>
</back>
</back>
</rfc> </rfc>
 End of changes. 162 change blocks. 
1816 lines changed or deleted 1550 lines changed or added

This html diff was produced by rfcdiff 1.48.