<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<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" symRefs="true" sortRefs="true" version="3">
<front>
<title abbrev="EAP-AKA' FS">Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)</title>
<seriesInfo name="RFC" value="9678"/>
<author initials="J." surname="Arkko" fullname="Jari Arkko">
<organization>Ericsson</organization>
<address>
<postal>
<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>
<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>
<date month="January" year="2025"/>
<area>SEC</area>
<workgroup>emu</workgroup>
<keyword>EAP</keyword>
<keyword>AKA</keyword>
<keyword>AKA'</keyword>
<keyword>EAP-AKA'</keyword>
<keyword>EAP-AKA' FS</keyword>
<keyword>3GPP</keyword>
<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
providing 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. 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
involved compromising the Universal Subscriber Identity Module (USIM)
card supply chain. Attacks revealing the AKA long-term key may occur,
for instance:</t>
<ul>
<li>during the manufacturing process of USIM cards,</li>
<li>during the transfer of the cards and associated information to
the operator, and</li>
<li>when the system is running.</li>
</ul>
<t>Since the publication of reports about such attacks (see <xref
target="Heist2015" format="default"/>), manufacturing and provisioning
processes have gained much scrutiny and have improved.</t>
<t>However, the danger of resourceful attackers attempting to gain
information about long-term keys is still a concern because these keys
are high-value targets. Note that the attacks are largely independent
of the used authentication technology; the issue is not vulnerabilities
in algorithms or protocols, but rather the possibility of someone
gaining unauthorized access to key material. Furthermore, an explicit
goal of the IETF is to ensure that we understand the surveillance
concerns related to IETF protocols and take appropriate countermeasures
<xref target="RFC7258" format="default"/>.</t>
<t>While strong protection of manufacturing and other processes is
essential in mitigating surveillance and other risks associated with
AKA long-term keys, there are also protocol mechanisms that can
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>The extension, when
negotiated, provides Forward Secrecy (FS) <xref target="DOW1992" format="default"/> for the session key
generated as a part of the authentication run in EAP-AKA'. This
prevents an attacker who has gained access to the long-term
key in a USIM card from getting access to past session
keys. In addition to FS, the included Diffie-Hellman exchange forces
attackers to be active if they want access to future session keys, even
if they have access to the long-term key. This is beneficial because
active attacks demand many more resources to launch and are easier to
detect. As
with other protocols, an active attacker with access to the
long-term key material will, of course, be able to attack all future
communications, but risks detection, particularly if done at
scale.</t>
<t>It should also be noted that 5G network architecture <xref target="TS.33.501" format="default"/>
includes the
use of the EAP framework for authentication. While any methods can
be run, the default authentication method within that context will
be EAP-AKA'. As a result, improvements in EAP-AKA' security have the
potential to improve security for many users.</t>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t>
</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
rationale that this will make the construction more easily adopted.
In particular, the construction keeps the interface between the
USIM and the mobile
terminal intact. As a consequence, there is no need to roll out new
credentials to existing subscribers. The work is based on an earlier
paper (see <xref target="TrustCom2015" format="default"/>) and uses much of the same
material but is applied to EAP rather than the underlying AKA
method.</t>
<t>It has been a goal to implement this change as an extension
of the widely supported EAP-AKA' method, rather than implement a completely new
authentication method. The extension is implemented as a set of
new, optional attributes that are provided alongside the
base attributes in EAP-AKA'. Old implementations can ignore
these attributes, but their presence will nevertheless be verified
as part of the base EAP-AKA' integrity verification process, helping
protect against bidding down attacks. This extension does
not increase the number of rounds necessary to complete the
protocol.</t>
<t>The use of this extension is at the discretion of the
authenticating parties. It should be noted that FS and defenses
against passive attacks do not solve all problems, but they can
provide a partial defense that increases the cost and risk
associated with pervasive surveillance.</t>
<t>While adding FS to the existing mobile
network infrastructure can be done in multiple different ways, this
document specifies a solution that is relatively easy to deploy. In particular:
</t>
<ul spacing="normal">
<li>As noted above, no new credentials are needed; there is no change
to USIM cards.</li>
<li>FS property can be incorporated into any current or future system
that supports EAP, without changing any network functions beyond the
EAP endpoints.</li>
<li>Key generation happens at the endpoints, enabling the highest grade
key material to be used both by the endpoints and the intermediate
systems (such as access points that are given access to specific
keys).</li>
<li>While EAP-AKA' is just one EAP method, for practical purposes,
FS being available for both EAP-TLS <xref
target="RFC5216" format="default"/> <xref target="RFC9190"
format="default"/> and EAP-AKA' ensures that, for many practical
systems, FS can be enabled for either all or a significant
fraction of users.</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Background</name>
<t>The reader is assumed to
have a basic understanding of the EAP framework <xref target="RFC3748" format="default"/>.</t>
<section numbered="true" toc="default">
<name>AKA</name>
<t>We use the term "Authentication and Key Agreement" (or "AKA") for the
main authentication and key agreement protocol used by 3GPP mobile
networks from the third generation (3G) and onward. Later
generations add new features to AKA, but the core remains the
same. It is based on challenge-response mechanisms and symmetric
cryptography. In contrast to its earlier GSM counterparts, AKA
provides long key lengths and mutual authentication. The phone
typically executes AKA in a USIM. A USIM is technically just an
application that can reside on a removable Universal
Integrated Circuit Card (UICC), an embedded UICC, or integrated in a
Trusted Execution Environment (TEE). In this document, we use the
term "USIM card" to refer to any Subscriber Identity Module (SIM)
capable of running AKA.</t>
<t>The goals of AKA are to mutually authenticate the USIM and the
so-called home environment, which is the authentication Server in the
subscriber's home operator's network, and to establish key material
between the two.</t>
<t>AKA works in the following manner:</t>
<ul spacing="normal">
<li>The USIM and the home environment have agreed on a long-term
symmetric key beforehand.</li>
<li>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 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
behavior, along with the definition of the attributes AT_RAND,
AT_AUTN, AT_MAC, and AT_RES can be found in <xref target="RFC9048" format="default"/> and <xref target="RFC4187" format="default"/>.
Note the use of EAP terminology from hereon. That is, the 3GPP
serving network takes on the role of an EAP access network.
</t>
<figure anchor="figaka">
<name>EAP-AKA' Authentication Process</name>
<artset>
<artwork type="ascii-art" name="" align="left" alt=""><![CDATA[
Peer Server
| |
| EAP-Request/Identity |
|<-----------------------------------------------------------+
| |
| EAP-Response/Identity |
| (Includes user's Network Access Identifier (NAI)) |
+----------------------------------------------------------->|
| +-------------------------------------------------------+--+
| | The Server determines the network name and ensures that |
| | the given access network is authorized to use the |
| | claimed name. The Server then runs the EAP-AKA' |
| | algorithms generating RAND and AUTN, and derives session |
| | keys from CK' and IK'. RAND and AUTN are sent as |
| | AT_RAND and AT_AUTN attributes, whereas the network name |
| | is transported in the AT_KDF_INPUT attribute. AT_KDF |
| | signals the used key derivation function. The session |
| | keys are used to create the AT_MAC attribute. |
| +-------------------------------------------------------+--+
| |
| EAP-Request/AKA'-Challenge |
| (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) |
|<-----------------------------------------------------------+
+--+------------------------------------------------------+ |
| The Peer determines what the network name should be, | |
| based on, e.g., what access technology it is using. | |
| The Peer also retrieves the network name sent by the | |
| network from the AT_KDF_INPUT attribute. The two names | |
| are compared for discrepancies, and if they do not | |
| match, the authentication is aborted. Otherwise, the | |
| network name from the AT_KDF_INPUT attribute is used | |
| in running the EAP-AKA' algorithms, verifying AUTN from | |
| AT_AUTN and Message Authentication Code (MAC) from the | |
| AT_MAC attributes. The Peer then generates RES. The | |
| Peer also derives session keys from CK'/IK. The AT_RES | |
| and AT_MAC attributes are constructed. | |
+--+------------------------------------------------------+ |
| |
| EAP-Response/AKA'-Challenge |
| (AT_RES, AT_MAC) |
+----------------------------------------------------------->|
| +-----------------------------------------------------+--+
| | The Server checks the RES and MAC values received in |
| | AT_RES and AT_MAC, respectively. Success requires |
| | both compared values match, respectively. |
| +-----------------------------------------------------+--+
| |
| EAP-Success |
|<-----------------------------------------------------------+
| |
]]></artwork>
<artwork type="svg" name="" align="left" alt=""><svg align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="832" height="848" width="552" viewBox="0 0 552 832" 848" 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 72,160 L 88,320" 72,320" fill="none" stroke="black"/>
<path d="M 88,688 L 88,752" fill="none" stroke="black"/>
<path d="M 464,400 472,400 L 464,608" 472,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 72,160 L 544,160" fill="none" stroke="black"/>
<path d="M 88,320 72,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" 472,400" fill="none" stroke="black"/>
<path d="M 8,608 L 464,608" 472,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" 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="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" x="340" y="132">Identifier</text>
<text x="412" y="132">(NAI))</text>
<text x="124" x="96" y="180">The</text>
<text x="140" y="180">Server</text>
<text x="196" x="212" y="180">determines</text>
<text x="256" x="272" y="180">the</text>
<text x="304" x="320" y="180">network</text>
<text x="356" x="372" y="180">name</text>
<text x="392" x="408" y="180">and</text>
<text x="440" x="456" y="180">ensures</text>
<text x="492" x="508" y="180">that</text>
<text x="112" x="96" y="196">the</text>
<text x="152" x="136" y="196">given</text>
<text x="204" x="188" y="196">access</text>
<text x="264" x="248" y="196">network</text>
<text x="308" x="292" y="196">is</text>
<text x="364" x="348" y="196">authorized</text>
<text x="420" x="404" y="196">to</text>
<text x="448" x="432" y="196">use</text>
<text x="480" x="464" y="196">the</text>
<text x="128" x="112" y="212">claimed</text>
<text x="184" x="168" y="212">name.</text>
<text x="224" x="216" y="212">The</text>
<text x="268" x="260" y="212">Server</text>
<text x="316" x="308" y="212">then</text>
<text x="356" x="348" y="212">runs</text>
<text x="392" x="384" y="212">the</text>
<text x="428" y="212">AKA'</text> x="436" y="212">EAP-AKA'</text>
<text x="492" y="212">algorithms</text> x="124" y="228">algorithms</text>
<text x="140" x="212" y="228">generating</text>
<text x="204" x="276" y="228">RAND</text>
<text x="240" x="312" y="228">and</text>
<text x="280" x="352" y="228">AUTN,</text>
<text x="336" x="392" y="228">and</text>
<text x="440" y="228">derives</text>
<text x="400" x="504" y="228">session</text>
<text x="452" y="228">keys</text> x="100" y="244">keys</text>
<text x="492" y="228">from</text> x="140" y="244">from</text>
<text x="112" x="176" y="244">CK'</text>
<text x="144" x="208" y="244">and</text>
<text x="180" x="244" y="244">IK'.</text>
<text x="220" x="292" y="244">RAND</text>
<text x="256" x="328" y="244">and</text>
<text x="292" x="364" y="244">AUTN</text>
<text x="328" x="400" y="244">are</text>
<text x="364" x="436" y="244">sent</text>
<text x="396" x="468" y="244">as</text>
<text x="440" y="244">AT_RAND</text> x="112" y="260">AT_RAND</text>
<text x="488" y="244">and</text> x="160" y="260">and</text>
<text x="128" x="208" y="260">AT_AUTN</text>
<text x="208" x="288" y="260">attributes,</text>
<text x="288" x="368" y="260">whereas</text>
<text x="336" x="416" y="260">the</text>
<text x="384" x="464" y="260">network</text>
<text x="436" x="516" y="260">name</text>
<text x="468" y="260">is</text> x="92" y="276">is</text>
<text x="144" x="152" y="276">transported</text>
<text x="204" x="212" y="276">in</text>
<text x="232" x="240" y="276">the</text>
<text x="300" x="308" y="276">AT_KDF_INPUT</text>
<text x="396" x="404" y="276">attribute.</text>
<text x="468" x="484" y="276">AT_KDF</text>
<text x="128" x="112" y="292">signals</text>
<text x="176" x="160" y="292">the</text>
<text x="212" x="196" y="292">used</text>
<text x="248" x="232" y="292">key</text>
<text x="308" x="292" y="292">derivation</text>
<text x="392" x="376" y="292">function.</text>
<text x="448" x="440" y="292">The</text>
<text x="496" x="488" y="292">session</text>
<text x="116" x="100" y="308">keys</text>
<text x="152" x="136" y="308">are</text>
<text x="188" x="172" y="308">used</text>
<text x="220" x="204" y="308">to</text>
<text x="260" x="244" y="308">create</text>
<text x="304" x="288" y="308">the</text>
<text x="348" x="332" y="308">AT_MAC</text>
<text x="420" x="404" 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" x="368" y="468">The</text>
<text x="392" x="400" y="468">two</text>
<text x="432" x="440" 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" x="372" y="500">Otherwise,</text>
<text x="424" x="432" 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" x="176" y="516">the</text>
<text x="244" y="516">AT_KDF_INPUT</text>
<text x="304" x="336" y="516">attribute</text>
<text x="356" x="388" y="516">is</text>
<text x="388" x="420" y="516">used</text>
<text x="420" y="516">in</text> x="28" y="532">in</text>
<text x="48" x="72" y="532">running</text>
<text x="96" x="120" y="532">the</text>
<text x="132" y="532">AKA'</text> x="172" y="532">EAP-AKA'</text>
<text x="200" x="256" y="532">algorithms,</text>
<text x="288" x="344" y="532">verifying</text>
<text x="348" x="404" y="532">AUTN</text>
<text x="388" x="444" 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> x="144" y="548">Message</text>
<text x="164" x="236" y="548">Authentication</text>
<text x="316" y="548">Code</text>
<text x="360" y="548">(MAC)</text>
<text x="404" y="548">from</text>
<text x="212" y="548">AT_MAC</text> x="440" y="548">the</text>
<text x="288" y="548">attributes.</text> x="44" y="564">AT_MAC</text>
<text x="352" y="548">The</text> x="120" y="564">attributes.</text>
<text x="388" y="548">Peer</text> x="192" y="564">The</text>
<text x="428" y="548">then</text> x="228" y="564">Peer</text>
<text x="56" x="268" y="564">then</text>
<text x="328" y="564">generates</text>
<text x="116" x="388" y="564">RES.</text>
<text x="152" x="432" y="564">The</text>
<text x="188" y="564">Peer</text> x="36" y="580">Peer</text>
<text x="228" y="564">also</text> x="76" y="580">also</text>
<text x="280" y="564">derives</text> x="128" y="580">derives</text>
<text x="344" y="564">session</text> x="192" y="580">session</text>
<text x="396" y="564">keys</text> x="244" y="580">keys</text>
<text x="436" y="564">from</text> x="284" y="580">from</text>
<text x="52" y="580">CK'/IK'.</text> x="336" y="580">CK'/IK.</text>
<text x="104" x="392" y="580">The</text>
<text x="148" x="436" y="580">AT_RES</text>
<text x="192" y="580">and</text> x="32" y="596">and</text>
<text x="236" y="580">AT_MAC</text> x="76" y="596">AT_MAC</text>
<text x="308" y="580">attributes</text> x="148" y="596">attributes</text>
<text x="368" y="580">are</text> x="208" y="596">are</text>
<text x="68" x="276" 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" x="112" y="708">The</text>
<text x="156" y="708">Server</text>
<text x="180" x="212" y="708">checks</text>
<text x="224" x="256" y="708">the</text>
<text x="256" x="288" y="708">RES</text>
<text x="288" x="320" y="708">and</text>
<text x="320" x="352" y="708">MAC</text>
<text x="364" x="396" y="708">values</text>
<text x="428" x="460" y="708">received</text>
<text x="476" x="508" 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" x="400" y="724">Success</text>
<text x="460" x="468" y="724">requires</text>
<text x="516" y="724">both</text> x="116" y="740">both</text>
<text x="132" x="172" y="740">compared</text>
<text x="196" x="236" y="740">values</text>
<text x="252" x="292" y="740">match,</text>
<text x="336" x="376" 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
EAP-AKA'. The intent is to implement the enhancement as optional
attributes that legacy implementations ignore.</t>
<t>The purpose of the protocol is to achieve mutual authentication
between the EAP Server and Peer and to establish key material
for secure communication between the two. This document specifies
the calculation of key material, providing new properties that are
not present in key material provided by EAP-AKA' in its original
form.</t>
<t><xref target="figakafs" format="default"/> describes the overall
process. Since the goal 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
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
| | | |
| | EAP-Req/Identity | |
| |<---------------------------+ |
| | | |
| | EAP-Resp/Identity | |
| | (Privacy-Friendly) | |
| +--------------------------->| |
| +-------+----------------------------+----------------+----+
| | The Server now has an identity for the Peer. The Server |
| | then asks the help of the AD to run EAP-AKA algorithms, |
| | generating RAND, AUTN, XRES, CK, and IK. Typically, the |
| | AD performs the first part of derivations so that the |
| | authentication Server gets the CK' and IK' keys already |
| | tied to a particular network name. |
| +-------+----------------------------+----------------+----+
| | | |
| | | ID, key deriv. |
| | | function, |
| | | network name |
| | +--------------->|
| | | |
| | | RAND, AUTN, |
| | | XRES, CK', IK' |
| | |<---------------+
| +-------+----------------------------+----------------+----+
| | The Server now has the needed authentication vector. It |
| | generates an ephemeral key pair, and sends the public |
| | key of that key pair and the first EAP method message to |
| | the Peer. In the message the AT_PUB_ECDHE attribute |
| | carries the public key and the AT_KDF_FS attribute |
| | carries other FS-related parameters. Both of these are |
| | skippable attributes that can be ignored if the Peer |
| | does not support this extension. |
| +-------+----------------------------+----------------+----+
| | | |
| | EAP-Req/AKA'-Challenge | |
| | AT_RAND, AT_AUTN, AT_KDF, | |
| | AT_KDF_FS, AT_KDF_INPUT, | |
| | AT_PUB_ECDHE, AT_MAC | |
| |<---------------------------+ |
+--+--------------+----------------------------+---------+ |
| The Peer checks if it wants to do the FS extension. | |
| If yes, it will eventually respond with AT_PUB_ECDHE | |
| and AT_MAC. If not, it will ignore AT_PUB_ECDHE and | |
| AT_KDF_FS and base all calculations on basic EAP-AKA' | |
| attributes, continuing just as in EAP-AKA' per RFC | |
| 9048 rules. In any case, the Peer needs to query the | |
| auth parameters from the USIM card. | |
+--+--------------+----------------------------+---------+ |
| | | |
| RAND, AUTN | | |
|<-------------+ | |
| | | |
| CK, IK, RES | | |
+------------->| | |
+--+--------------+----------------------------+---------+ |
| The Peer now has everything to respond. If it wants | |
| to participate in the FS extension, it will then | |
| generate its key pair, calculate a shared key based on | |
| its key pair and the Server's public key. Finally, it | |
| proceeds to derive all EAP-AKA' key values and | |
| constructs a full response. | |
+--+--------------+----------------------------+---------+ |
| | | |
| | EAP-Resp/AKA'-Challenge | |
| | AT_RES, AT_PUB_ECDHE, | |
| | AT_MAC | |
| +--------------------------->| |
| +-------+----------------------------+----------------+--+
| | The Server now has all the necessary values. It |
| | generates the ECDHE shared secret and checks the RES |
| | and MAC values received in AT_RES and AT_MAC, |
| | respectively. Success requires both to be found |
| | correct. Note that when this document is used, |
| | the keys generated from EAP-AKA' are based on CK, IK, |
| | and the ECDHE value. Even if there was an attacker |
| | who held the long-term key, only an active attacker |
| | could have determined the generated session keys; in |
| | basic EAP-AKA' the generated keys are only based on CK |
| | and IK. |
| +-------+----------------------------+----------------+--+
| | | |
| | EAP-Success | |
| |<---------------------------+ |
| | | |
]]></artwork>
<artwork type="svg" name="" align="left" alt=""><svg align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="1200" width="875" height="1424" width="568" viewBox="0 0 552 1408" 568 1424" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
<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 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,1040 L 32,1392" 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,1136 L 88,1328" fill="none" stroke="black"/>
<path d="M 152,48 L 152,160" fill="none" stroke="black"/>
<path d="M 152,272 152,256 L 152,432" fill="none" stroke="black"/>
<path d="M 152,576 L 152,688" fill="none" stroke="black"/>
<path d="M 152,816 L 152,928" fill="none" stroke="black"/>
<path d="M 152,1040 L 152,1136" fill="none" stroke="black"/>
<path d="M 152,1328 152,1312 L 152,1392" fill="none" stroke="black"/>
<path d="M 384,48 L 384,160" fill="none" stroke="black"/>
<path d="M 384,272 L 384,432" fill="none" stroke="black"/>
<path d="M 384,576 L 384,688" fill="none" stroke="black"/>
<path d="M 384,816 L 384,928" fill="none" stroke="black"/>
<path d="M 384,1040 L 384,1136" fill="none" stroke="black"/>
<path d="M 384,1328 L 384,1392" fill="none" stroke="black"/>
<path d="M 464,688 L 464,816" fill="none" stroke="black"/>
<path d="M 464,928 L 464,1040" fill="none" stroke="black"/>
<path d="M 520,48 L 520,160" fill="none" stroke="black"/>
<path d="M 520,272 L 520,432" fill="none" stroke="black"/>
<path d="M 520,576 L 520,1136" fill="none" stroke="black"/>
<path d="M 520,1328 L 520,1392" fill="none" stroke="black"/>
<path d="M 544,160 544,1136 L 544,272" 544,1328" fill="none" stroke="black"/>
<path d="M 544,432 560,160 L 544,576" 560,272" fill="none" stroke="black"/>
<path d="M 544,1136 560,432 L 544,1328" 560,576" fill="none" stroke="black"/>
<path d="M 160,80 L 384,80" fill="none" stroke="black"/>
<path d="M 152,144 L 376,144" fill="none" stroke="black"/>
<path d="M 88,160 L 544,160" 560,160" fill="none" stroke="black"/>
<path d="M 88,272 L 544,272" 560,272" fill="none" stroke="black"/>
<path d="M 384,352 L 512,352" fill="none" stroke="black"/>
<path d="M 392,416 L 520,416" fill="none" stroke="black"/>
<path d="M 88,432 L 544,432" 560,432" fill="none" stroke="black"/>
<path d="M 88,576 L 544,576" 560,576" fill="none" stroke="black"/>
<path d="M 160,672 L 384,672" fill="none" stroke="black"/>
<path d="M 8,688 L 464,688" fill="none" stroke="black"/>
<path d="M 8,816 L 464,816" fill="none" stroke="black"/>
<path d="M 40,864 L 152,864" fill="none" stroke="black"/>
<path d="M 32,912 L 144,912" fill="none" stroke="black"/>
<path d="M 8,928 L 464,928" fill="none" stroke="black"/>
<path d="M 8,1040 L 464,1040" fill="none" stroke="black"/>
<path d="M 152,1120 L 376,1120" fill="none" stroke="black"/>
<path d="M 88,1136 L 544,1136" fill="none" stroke="black"/>
<path d="M 88,1328 L 544,1328" fill="none" stroke="black"/>
<path d="M 160,1376 L 384,1376" fill="none" stroke="black"/>
<polygon class="arrowhead" points="520,352 508,346.4 508,357.6" fill="black" transform="rotate(0,512,352)"/>
<polygon class="arrowhead" points="400,416 388,410.4 388,421.6" fill="black" transform="rotate(180,392,416)"/>
<polygon class="arrowhead" points="384,1120 372,1114.4 372,1125.6" fill="black" transform="rotate(0,376,1120)"/>
<polygon class="arrowhead" points="384,144 372,138.4 372,149.6" fill="black" transform="rotate(0,376,144)"/>
<polygon class="arrowhead" points="168,1376 156,1370.4 156,1381.6" fill="black" transform="rotate(180,160,1376)"/>
<polygon class="arrowhead" points="168,672 156,666.4 156,677.6" fill="black" transform="rotate(180,160,672)"/>
<polygon class="arrowhead" points="168,80 156,74.4 156,85.6" fill="black" transform="rotate(180,160,80)"/>
<polygon class="arrowhead" points="152,912 140,906.4 140,917.6" fill="black" transform="rotate(0,144,912)"/>
<polygon class="arrowhead" points="48,864 36,858.4 36,869.6" fill="black" transform="rotate(180,40,864)"/>
<circle cx="152" cy="256" r="6" class="opendot" fill="white" stroke="black"/>
<g class="text">
<text x="28" y="36">USIM</text>
<text x="148" y="36">Peer</text>
<text x="380" y="36">Server</text>
<text x="524" y="36">AD</text>
<text x="308" y="68">EAP-Req/Identity</text>
<text x="232" y="116">EAP-Resp/Identity</text>
<text x="236" y="132">(Privacy-Friendly)</text>
<text x="124" x="112" y="180">The</text>
<text x="156" y="180">Server</text>
<text x="168" x="200" y="180">now</text>
<text x="200" x="232" y="180">has</text>
<text x="228" x="260" y="180">an</text>
<text x="276" x="308" y="180">identity</text>
<text x="328" x="360" y="180">for</text>
<text x="360" x="392" y="180">the</text>
<text x="400" x="432" y="180">Peer.</text>
<text x="440" x="480" y="180">The</text>
<text x="484" x="524" y="180">Server</text>
<text x="116" y="196">then</text>
<text x="156" y="196">asks</text>
<text x="192" y="196">the</text>
<text x="228" y="196">help</text>
<text x="260" y="196">of</text>
<text x="284" x="288" y="196">the</text>
<text x="316" y="196">AD</text>
<text x="308" x="340" y="196">to</text>
<text x="336" x="368" y="196">run</text>
<text x="368" y="196">AKA</text> x="416" y="196">EAP-AKA</text>
<text x="432" x="496" y="196">algorithms,</text>
<text x="140" y="212">generating</text>
<text x="208" y="212">RAND,</text>
<text x="256" y="212">AUTN,</text>
<text x="304" y="212">XRES,</text>
<text x="344" y="212">CK,</text>
<text x="376" y="212">and</text>
<text x="408" y="212">IK.</text>
<text x="436" x="476" y="212">Typically,</text>
<text x="496" x="536" y="212">the</text>
<text x="108" y="228">AD</text>
<text x="156" y="228">performs</text>
<text x="208" y="228">the</text>
<text x="248" y="228">first</text>
<text x="292" y="228">part</text>
<text x="324" y="228">of</text>
<text x="352" y="228">key</text>
<text x="416" x="384" y="228">derivations</text>
<text x="476" x="444" y="228">so</text>
<text x="508" x="476" y="228">that</text>
<text x="112" y="244">the</text> x="512" y="228">the</text>
<text x="188" x="156" y="244">authentication</text>
<text x="276" x="244" y="244">Server</text>
<text x="324" x="292" y="244">gets</text>
<text x="360" x="328" y="244">the</text>
<text x="392" x="360" y="244">CK'</text>
<text x="424" x="392" y="244">and</text>
<text x="456" x="424" y="244">IK'</text>
<text x="492" x="460" y="244">keys</text>
<text x="128" y="260">already</text> x="512" y="244">already</text>
<text x="180" x="116" y="260">tied</text>
<text x="212" y="260">to</text> x="144" y="260">t</text>
<text x="232" x="168" y="260">a</text>
<text x="284" x="220" y="260">particular</text>
<text x="360" x="296" y="260">network</text>
<text x="416" x="352" y="260">name.</text>
<text x="408" y="308">ID,</text>
<text x="440" y="308">key</text>
<text x="484" y="308">deriv.</text>
<text x="432" y="324">function,</text>
<text x="424" y="340">network</text>
<text x="476" y="340">name</text>
<text x="440" y="388">RAND,</text>
<text x="488" y="388">AUTN,</text>
<text x="416" y="404">XRES,</text>
<text x="460" y="404">CK',</text>
<text x="496" y="404">IK'</text>
<text x="124" x="112" y="452">The</text>
<text x="156" y="452">Server</text>
<text x="168" x="200" y="452">now</text>
<text x="200" x="232" y="452">has</text>
<text x="232" x="264" y="452">the</text>
<text x="276" x="308" y="452">needed</text>
<text x="364" x="396" y="452">authentication</text>
<text x="456" x="488" y="452">vector.</text>
<text x="500" x="540" y="452">It</text>
<text x="136" y="468">generates</text>
<text x="188" y="468">an</text>
<text x="240" y="468">ephemeral</text>
<text x="296" y="468">key</text>
<text x="336" y="468">pair,</text>
<text x="384" x="376" y="468">and</text>
<text x="416" y="468">sends</text>
<text x="424" x="456" y="468">the</text>
<text x="468" x="500" y="468">public</text>
<text x="512" y="468">key</text> x="112" y="484">key</text>
<text x="108" x="140" y="484">of</text>
<text x="140" x="172" y="484">that</text>
<text x="176" x="208" y="484">key</text>
<text x="212" x="244" y="484">pair</text>
<text x="248" x="280" y="484">and</text>
<text x="280" x="312" y="484">the</text>
<text x="320" x="352" y="484">first</text>
<text x="360" x="392" y="484">EAP</text>
<text x="404" x="436" y="484">method</text>
<text x="464" x="496" y="484">message</text>
<text x="508" x="540" y="484">to</text>
<text x="112" y="500">the</text>
<text x="152" y="500">Peer.</text>
<text x="188" y="500">In</text>
<text x="216" y="500">the</text>
<text x="264" y="500">message</text>
<text x="312" y="500">the</text>
<text x="380" y="500">AT_PUB_ECDHE</text>
<text x="472" y="500">attribute</text>
<text x="128" y="516">carries</text>
<text x="176" y="516">the</text>
<text x="220" y="516">public</text>
<text x="264" y="516">key</text>
<text x="296" y="516">and</text>
<text x="328" y="516">the</text>
<text x="384" y="516">AT_KDF_FS</text>
<text x="464" y="516">attribute</text>
<text x="128" y="532">carries</text>
<text x="184" y="532">other</text>
<text x="252" y="532">FS-related</text>
<text x="344" y="532">parameters.</text>
<text x="412" y="532">Both</text>
<text x="444" y="532">of</text>
<text x="480" y="532">these</text>
<text x="520" y="532">are</text>
<text x="136" y="548">skippable</text>
<text x="220" y="548">attributes</text>
<text x="284" y="548">that</text>
<text x="320" y="548">can</text>
<text x="348" y="548">be</text>
<text x="392" y="548">ignored</text>
<text x="436" y="548">if</text>
<text x="464" y="548">the</text>
<text x="500" y="548">Peer</text>
<text x="116" y="564">does</text>
<text x="152" y="564">not</text>
<text x="200" y="564">support</text>
<text x="252" y="564">this</text>
<text x="316" y="564">extension.</text>
<text x="284" y="612">EAP-Req/AKA'-Challenge</text>
<text x="204" y="628">AT_RAND,</text>
<text x="276" y="628">AT_AUTN,</text>
<text x="344" y="628">AT_KDF,</text>
<text x="220" y="644">AT_KDF_FS,</text>
<text x="320" y="644">AT_KDF_INPUT,</text>
<text x="264" y="660">AT_PUB_ECDHE,</text>
<text x="348" y="660">AT_MAC</text>
<text x="32" y="708">The</text>
<text x="68" y="708">Peer</text>
<text x="116" y="708">checks</text>
<text x="156" y="708">if</text>
<text x="180" y="708">it</text>
<text x="216" y="708">wants</text>
<text x="252" y="708">to</text>
<text x="276" y="708">do</text>
<text x="304" y="708">the</text>
<text x="332" y="708">FS</text>
<text x="388" y="708">extension.</text>
<text x="444" y="708">If</text> x="28" y="724">If</text>
<text x="36" x="60" y="724">yes,</text>
<text x="68" x="92" y="724">it</text>
<text x="100" x="124" y="724">will</text>
<text x="164" x="188" y="724">eventually</text>
<text x="240" x="264" y="724">respond</text>
<text x="292" x="316" y="724">with</text>
<text x="364" x="388" y="724">AT_PUB_ECDHE</text>
<text x="432" y="724">and</text> x="32" y="740">and</text>
<text x="48" x="80" y="740">AT_MAC.</text>
<text x="92" x="132" y="740">If</text>
<text x="124" x="164" y="740">not,</text>
<text x="156" x="196" y="740">it</text>
<text x="188" x="228" y="740">will</text>
<text x="236" x="276" y="740">ignore</text>
<text x="316" x="356" y="740">AT_PUB_ECDHE</text>
<text x="384" x="424" y="740">and</text>
<text x="56" y="756">AT_KDF_FS</text>
<text x="112" y="756">and</text>
<text x="148" y="756">base</text>
<text x="184" y="756">all</text>
<text x="252" y="756">calculations</text>
<text x="316" y="756">on</text>
<text x="352" y="756">basic</text>
<text x="412" y="756">EAP-AKA'</text>
<text x="64" y="772">attributes,</text>
<text x="156" y="772">continuing</text>
<text x="220" y="772">just</text>
<text x="252" y="772">as</text>
<text x="276" y="772">in</text>
<text x="324" y="772">EAP-AKA'</text>
<text x="376" y="772">per</text>
<text x="408" y="772">RFC</text>
<text x="36" y="788">9048</text>
<text x="84" y="788">rules.</text>
<text x="124" x="132" y="788">In</text>
<text x="152" x="160" y="788">any</text>
<text x="192" x="200" y="788">case,</text>
<text x="232" x="240" y="788">the</text>
<text x="268" x="276" y="788">Peer</text>
<text x="312" x="320" y="788">needs</text>
<text x="348" x="356" y="788">to</text>
<text x="384" x="392" y="788">query</text>
<text x="424" x="432" y="788">the</text>
<text x="36" y="804">auth</text>
<text x="100" y="804">parameters</text>
<text x="164" y="804">from</text>
<text x="200" y="804">the</text>
<text x="236" y="804">USIM</text>
<text x="280" y="804">card.</text>
<text x="80" y="852">RAND,</text>
<text x="124" y="852">AUTN</text>
<text x="56" y="900">CK,</text>
<text x="88" y="900">IK,</text>
<text x="120" y="900">RES</text>
<text x="32" y="948">The</text>
<text x="68" y="948">Peer</text>
<text x="104" y="948">now</text>
<text x="136" y="948">has</text>
<text x="196" y="948">everything</text>
<text x="252" y="948">to</text>
<text x="300" y="948">respond.</text>
<text x="348" x="356" y="948">If</text>
<text x="372" x="380" y="948">it</text>
<text x="408" x="416" y="948">wants</text>
<text x="444" y="948">to</text> x="28" y="964">to</text>
<text x="64" x="88" y="964">participate</text>
<text x="124" x="148" y="964">in</text>
<text x="152" x="176" y="964">the</text>
<text x="180" x="204" y="964">FS</text>
<text x="236" x="260" y="964">extension,</text>
<text x="292" x="316" y="964">it</text>
<text x="324" x="348" y="964">will</text>
<text x="364" x="388" y="964">then</text>
<text x="420" y="964">generate</text> x="52" y="980">generate</text>
<text x="32" x="104" y="980">its</text>
<text x="64" x="136" y="980">key</text>
<text x="104" x="176" y="980">pair,</text>
<text x="168" x="240" y="980">calculate</text>
<text x="216" x="288" y="980">a</text>
<text x="252" x="324" y="980">shared</text>
<text x="296" x="368" y="980">key</text>
<text x="336" x="408" y="980">based</text>
<text x="372" x="444" y="980">on</text>
<text x="400" y="980">its</text> x="32" y="996">its</text>
<text x="432" y="980">key</text> x="64" y="996">key</text>
<text x="36" x="100" y="996">pair</text>
<text x="72" x="136" y="996">and</text>
<text x="104" x="168" y="996">the</text>
<text x="156" x="220" y="996">Server's</text>
<text x="220" x="284" y="996">public</text>
<text x="268" x="332" y="996">key.</text>
<text x="324" x="396" y="996">Finally,</text>
<text x="372" x="444" y="996">it</text>
<text x="420" y="996">proceeds</text> x="52" y="1012">proceeds</text>
<text x="28" x="100" y="1012">to</text>
<text x="68" x="140" y="1012">derive</text>
<text x="112" x="184" y="1012">all</text>
<text x="164" x="236" y="1012">EAP-AKA'</text>
<text x="216" x="288" y="1012">key</text>
<text x="260" x="332" y="1012">values</text>
<text x="304" x="376" y="1012">and</text>
<text x="364" y="1012">constructs</text> x="60" y="1028">constructs</text>
<text x="416" y="1012">a</text> x="112" y="1028">a</text>
<text x="36" x="140" y="1028">full</text>
<text x="96" x="200" y="1028">response.</text>
<text x="256" y="1076">EAP-Resp/AKA'-Challenge</text>
<text x="192" y="1092">AT_RES,</text>
<text x="280" y="1092">AT_PUB_ECDHE,</text>
<text x="188" y="1108">AT_MAC</text>
<text x="112" y="1156">The</text>
<text x="156" y="1156">Server</text>
<text x="200" y="1156">now</text>
<text x="232" y="1156">has</text>
<text x="264" y="1156">all</text>
<text x="296" y="1156">the</text>
<text x="352" y="1156">necessary</text>
<text x="424" y="1156">values.</text>
<text x="468" x="476" y="1156">It</text>
<text x="136" y="1172">generates</text>
<text x="192" y="1172">the</text>
<text x="232" y="1172">ECDHE</text>
<text x="284" y="1172">shared</text>
<text x="340" y="1172">secret</text>
<text x="384" y="1172">and</text>
<text x="428" y="1172">checks</text>
<text x="472" y="1172">the</text>
<text x="504" y="1172">RES</text>
<text x="112" y="1188">and</text>
<text x="144" y="1188">MAC</text>
<text x="188" y="1188">values</text>
<text x="252" y="1188">received</text>
<text x="300" y="1188">in</text>
<text x="340" y="1188">AT_RES</text>
<text x="384" y="1188">and</text>
<text x="432" y="1188">AT_MAC,</text>
<text x="152" y="1204">respectively.</text>
<text x="240" x="248" y="1204">Success</text>
<text x="308" x="316" y="1204">requires</text>
<text x="364" x="372" y="1204">both</text>
<text x="396" x="404" y="1204">to</text>
<text x="420" x="428" y="1204">be</text>
<text x="456" x="464" y="1204">found</text>
<text x="132" y="1220">correct.</text>
<text x="188" x="196" y="1220">Note</text>
<text x="228" x="236" y="1220">that</text>
<text x="268" x="276" y="1220">when</text>
<text x="308" x="316" y="1220">this</text>
<text x="364" x="372" y="1220">document</text>
<text x="412" x="420" y="1220">is</text>
<text x="448" x="456" y="1220">used,</text>
<text x="112" y="1236">the</text>
<text x="148" y="1236">keys</text>
<text x="208" y="1236">generated</text>
<text x="268" y="1236">from</text>
<text x="324" y="1236">EAP-AKA'</text>
<text x="376" y="1236">are</text>
<text x="416" y="1236">based</text>
<text x="452" y="1236">on</text>
<text x="480" y="1236">CK,</text>
<text x="512" y="1236">IK,</text>
<text x="112" y="1252">and</text>
<text x="144" y="1252">the</text>
<text x="184" y="1252">ECDHE</text>
<text x="236" y="1252">value.</text>
<text x="284" x="292" y="1252">Even</text>
<text x="316" x="324" y="1252">if</text>
<text x="352" x="360" y="1252">there</text>
<text x="392" x="400" y="1252">was</text>
<text x="420" x="428" y="1252">an</text>
<text x="468" x="476" y="1252">attacker</text>
<text x="520" y="1252">who</text> x="112" y="1268">who</text>
<text x="116" x="148" y="1268">held</text>
<text x="152" x="184" y="1268">the</text>
<text x="208" x="240" y="1268">long-term</text>
<text x="268" x="300" y="1268">key,</text>
<text x="308" x="340" y="1268">only</text>
<text x="340" x="372" y="1268">an</text>
<text x="380" x="412" y="1268">active</text>
<text x="444" x="476" y="1268">attacker</text>
<text x="504" y="1268">could</text> x="120" y="1284">could</text>
<text x="116" x="164" y="1284">have</text>
<text x="180" x="228" y="1284">determined</text>
<text x="240" x="288" y="1284">the</text>
<text x="296" x="344" y="1284">generated</text>
<text x="368" x="416" y="1284">session</text>
<text x="424" x="472" y="1284">keys;</text>
<text x="460" x="508" y="1284">in</text>
<text x="496" y="1284">basic</text> x="120" y="1300">basic</text>
<text x="132" x="180" y="1300">EAP-AKA'</text>
<text x="184" x="232" y="1300">the</text>
<text x="240" x="288" y="1300">generated</text>
<text x="300" x="348" y="1300">keys</text>
<text x="336" x="384" y="1300">are</text>
<text x="372" x="420" y="1300">only</text>
<text x="416" x="464" y="1300">based</text>
<text x="452" x="500" y="1300">on</text>
<text x="476" x="524" y="1300">CK</text>
<text x="504" y="1300">and</text>
<text x="112" y="1316">IK.</text> y="1316">and</text>
<text x="140" y="1316">IK</text>
<text x="328" y="1364">EAP-Success</text>
</g>
</svg>
</artwork>
</artset>
</figure>
</section>
<section numbered="true" toc="default">
<name>Extensions to EAP-AKA'</name>
<section anchor="at_pub_dh" numbered="true" toc="default">
<name>AT_PUB_ECDHE</name>
<t>The AT_PUB_ECDHE attribute carries an ECDHE value.</t>
<t>The format of the AT_PUB_ECDHE attribute is shown below.</t>
<artset>
<artwork type="ascii-art" align="center" name="" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_PUB_ECDHE | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="112" width="528" viewBox="0 0 528 112" class="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 136,64 L 136,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 8,64 L 520,64" fill="none" stroke="black"/>
<path d="M 8,96 L 520,96" fill="none" stroke="black"/>
<g class="text">
<text x="16" y="36">0</text>
<text x="176" y="36">1</text>
<text x="336" y="36">2</text>
<text x="496" y="36">3</text>
<text x="16" y="52">0</text>
<text x="32" y="52">1</text>
<text x="48" y="52">2</text>
<text x="64" y="52">3</text>
<text x="80" y="52">4</text>
<text x="96" y="52">5</text>
<text x="112" y="52">6</text>
<text x="128" y="52">7</text>
<text x="144" y="52">8</text>
<text x="160" y="52">9</text>
<text x="176" y="52">0</text>
<text x="192" y="52">1</text>
<text x="208" y="52">2</text>
<text x="224" y="52">3</text>
<text x="240" y="52">4</text>
<text x="256" y="52">5</text>
<text x="272" y="52">6</text>
<text x="288" y="52">7</text>
<text x="304" y="52">8</text>
<text x="320" y="52">9</text>
<text x="336" y="52">0</text>
<text x="352" y="52">1</text>
<text x="368" y="52">2</text>
<text x="384" y="52">3</text>
<text x="400" y="52">4</text>
<text x="416" y="52">5</text>
<text x="432" y="52">6</text>
<text x="448" y="52">7</text>
<text x="464" y="52">8</text>
<text x="480" y="52">9</text>
<text x="496" y="52">0</text>
<text x="512" y="52">1</text>
<text x="68" y="84">AT_PUB_ECDHE</text>
<text x="172" y="84">Length</text>
<text x="296" y="84">Value</text>
</g>
</svg>
</artwork>
</artset>
<t>The fields are as follows:</t>
<dl newline="true" spacing="normal">
<dt>AT_PUB_ECDHE:</dt>
<dd>This is set to 152.</dd>
<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>
<dt>Value:</dt>
<dd>
<t>This value is
the sender's ECDHE public key. The value depends on the AT_KDF_FS attribute 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>
<section anchor="at_kdf_dh" numbered="true" toc="default">
<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
used or desired ECDHE group. A new attribute is needed to
carry this information, as AT_KDF carries the basic KDF
value that is still used together with the FS KDF
value. The basic KDF value is also used by those EAP Peers
that cannot or do not want to use this extension.</t>
<t>This document only specifies the behavior relating to the following
combinations of basic KDF values and FS KDF values:</t>
<ul>
<li>the
basic KDF value in AT_KDF is 1, as specified in <xref target="RFC5448"
format="default"/> and <xref target="RFC9048" format="default"/> and</li>
<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 KDFs or new FS KDF values need to specify
how they are treated and what combinations are allowed. This requirement is an update to how
<xref target="RFC5448" format="default"/> and <xref target="RFC9048" format="default"/> may be extended in the future.</t>
<t>The format of the AT_KDF_FS attribute is shown below.</t>
<artset>
<artwork type="ascii-art" align="center" name="" alt=""><![CDATA[
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF_FS | Length | FS Key Derivation Function |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
<artwork type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="112" width="528" viewBox="0 0 528 112" class="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 136,64 L 136,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 8,64 L 520,64" fill="none" stroke="black"/>
<path d="M 8,96 L 520,96" fill="none" stroke="black"/>
<g class="text">
<text x="16" y="36">0</text>
<text x="176" y="36">1</text>
<text x="336" y="36">2</text>
<text x="496" y="36">3</text>
<text x="16" y="52">0</text>
<text x="32" y="52">1</text>
<text x="48" y="52">2</text>
<text x="64" y="52">3</text>
<text x="80" y="52">4</text>
<text x="96" y="52">5</text>
<text x="112" y="52">6</text>
<text x="128" y="52">7</text>
<text x="144" y="52">8</text>
<text x="160" y="52">9</text>
<text x="176" y="52">0</text>
<text x="192" y="52">1</text>
<text x="208" y="52">2</text>
<text x="224" y="52">3</text>
<text x="240" y="52">4</text>
<text x="256" y="52">5</text>
<text x="272" y="52">6</text>
<text x="288" y="52">7</text>
<text x="304" y="52">8</text>
<text x="320" y="52">9</text>
<text x="336" y="52">0</text>
<text x="352" y="52">1</text>
<text x="368" y="52">2</text>
<text x="384" y="52">3</text>
<text x="400" y="52">4</text>
<text x="416" y="52">5</text>
<text x="432" y="52">6</text>
<text x="448" y="52">7</text>
<text x="464" y="52">8</text>
<text x="480" y="52">9</text>
<text x="496" y="52">0</text>
<text x="512" y="52">1</text>
<text x="56" y="84">AT_KDF_FS</text>
<text x="172" y="84">Length</text>
<text x="284" y="84">FS</text>
<text x="312" y="84">Key</text>
<text x="372" y="84">Derivation</text>
<text x="452" y="84">Function</text>
</g>
</svg>
</artwork>
</artset>
<t>The fields are as follows:</t>
<dl newline="true" spacing="normal">
<dt>AT_KDF_FS:</dt>
<dd>This is set to 153.</dd>
<dt>Length:</dt>
<dd>This is the length of the attribute; it <bcp14>MUST</bcp14> be set to 1.</dd>
<dt>FS Key Derivation Function:</dt>
<dd>This is an enumerated value representing the FS Key Derivation Function (KDF) that the Server (or Peer) wishes to use. See
<xref target="kdf2" format="default"/> for the functions specified
in this document. Note: this field has a different name space than
the similar field in the AT_KDF attribute KDF
defined in <xref target="RFC9048" format="default"/>.</dd>
</dl>
<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>
<t>Upon receiving a set of these attributes:</t>
<ul spacing="normal">
<li>If the Peer supports and is willing to use the FS KDF indicated
by the first AT_KDF_FS attribute, and is willing and able to use the
extension defined in this document, the function will be used
without any further negotiation.</li>
<li>If the Peer does not support this function or is unwilling to
use it, it responds to the Server with an indication that a
different function is needed. Similarly, with the negotiation process
defined in <xref target="RFC9048" format="default"/> for AT_KDF, the
Peer sends an 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 alternative, the Peer has a choice
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>
<li>If the Peer does not recognize the extension defined in this
document or is unwilling to use it, it ignores the AT_KDF_FS
attribute.</li>
</ul>
<t>Upon receiving an EAP-Response/AKA'-Challenge message with an AT_KDF_FS attribute
from the Peer, the Server checks that the suggested AT_KDF_FS value
was one of the alternatives in its offer. The first AT_KDF_FS value in
the 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 particular
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>
<artwork align="center" name="" type="" alt=""><![CDATA[
MK = PRF'(IK'|CK',"EAP-AKA'"|Identity)
MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)
K_encr = MK[0..127]
K_aut = MK[128..383]
K_re = MK_ECDHE[0..255]
MSK = MK_ECDHE[256..767]
EMSK = MK_ECDHE[768..1279]
]]></artwork>
<t>An explanation of the notation used above is copied here:</t>
<ul>
<li>[n..m] denotes the substring from bit n to m.</li>
<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>Note: MSK and EMSK are outputs from a successful EAP method run
<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>The value "EAP-AKA'" is an ASCII string that is 8 characters long. It
is used as is, without any trailing NUL characters. Similarly,
"EAP-AKA' FS" is an ASCII string that is 11 characters long, also used as
is.</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-56A"
format="default"/>. Requirements are defined in Section 5 of
<xref target="SP-800-56A"/>, in particular, Sections 5.6.2.3.4, 5.6.3.1, and
and 5.6.3.3. 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 specified 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>
<aside><t>Note: If performed inappropriately, the way that the shared
secret is tested for zero can provide an ability for attackers to
listen to CPU power usage side channels. Refer to <xref
target="RFC7748" format="default"/> for a description of how to
perform this check in a way that it does not become a
problem.</t></aside>
<t>If validation of the other party's ephemeral public key or the shared secret fails,
a party <bcp14>MUST</bcp14> behave as if the current EAP-AKA' process starts 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 anchor="groups" numbered="true" toc="default">
<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
the same time as the decision to use a particular KDF in the AT_KDF_FS attribute.</t>
<t>For "EAP-AKA' with ECDHE and
X25519", the group is the Curve25519 group specified in
<xref target="RFC7748" format="default"/>. The support for this group is <bcp14>REQUIRED</bcp14>.</t>
<t>For "EAP-AKA' with ECDHE and P-256", the group is the NIST P-256
group (SEC group secp256r1), specified in Section 3.2.1.3 of <xref
target="SP-800-186" format="default"/> or alternatively, Section 2.4.2
of <xref target="SEC2" format="default"/>. The support for this group
is <bcp14>REQUIRED</bcp14>.</t>
<t>The term "support" here means that the group <bcp14>MUST</bcp14> be implemented.</t>
</section>
<section anchor="secMessageProc" numbered="true" toc="default">
<name>Message Processing</name>
<t>This section specifies the changes related to message processing
when this extension is used in EAP-AKA'. It specifies when a message
may be transmitted or accepted, which attributes are allowed in a
message, which attributes are required in a message, and other
message-specific details, where those details are different for this
extension than the base EAP-AKA' or EAP-AKA protocol. Unless otherwise
specified here, the rules from <xref target="RFC9048"
format="default"/> or <xref target="RFC4187" format="default"/>
apply.</t>
<section numbered="true" toc="default">
<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 data
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>When processing this message, the Peer <bcp14>MUST</bcp14>
process AT_RAND, AT_AUTN, AT_KDF_FS, and AT_PUB_ECDHE before
processing other attributes. The Peer derives keys and verifies
AT_MAC only if these attributes are verified to be valid. If the
Peer is unable or unwilling to perform the extension specified in
this document, it proceeds as defined in <xref target="RFC9048"
format="default"/>. Finally, if there is an error, see <xref
target="RFC4187" sectionFormat="of" section="6.3.1"/>.</t>
</section>
<section anchor="procakachallresp" numbered="true" toc="default">
<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="RFC4187" 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" format="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
policy that requires it to always use this extension, it behaves
as if the AUTN were incorrect and fails the authentication.</t>
<t>The AT_MAC attribute <bcp14>MUST</bcp14> be included and checked as
specified in <xref target="RFC9048" format="default"/>. In the
EAP-Response/AKA'-Challenge, there is no message-specific data
covered by the MAC. The AT_PUB_ECDHE attribute <bcp14>MUST</bcp14> be included
and carries the Peer's public Diffie-Hellman key.</t>
<t>The AT_RES attribute <bcp14>MUST</bcp14> be included and checked as
specified in <xref target="RFC4187" format="default"/>. When processing this
message, the Server <bcp14>MUST</bcp14> process AT_RES before processing other
attributes. The Server derives keys and verifies AT_MAC only
when this attribute is verified to be valid.</t>
<t>If the Server has proposed the use of the extension specified
in this protocol, but the Peer ignores and continues the basic
EAP-AKA' authentication, the Server makes a policy decision of
whether this is allowed. If this is allowed, it continues the
EAP-AKA' authentication to completion. If it is not allowed, the
Server <bcp14>MUST</bcp14> behave as if authentication failed.</t>
<t>The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA, and other
attributes may be included as specified in <xref target="RFC4187" sectionFormat="of" section="9.4"/>.</t>
</section>
<section anchor="reauth" numbered="true" toc="default">
<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,
which employs key material from the Diffie-Hellman procedure if the extension specified in this document is in use.</t>
</section>
<section numbered="true" toc="default">
<name>EAP-Response/AKA'-Reauthentication</name>
<t>There are no changes for the EAP-Response/AKA'-Reauthentication,
but as discussed in <xref target="reauth" format="default"/>,
re-authentication is based on the key material generated by EAP-AKA'
and the extension defined in this document.</t>
</section>
<section numbered="true" toc="default">
<name>EAP-Response/AKA'-Synchronization-Failure</name>
<t>There are no changes for the
EAP-Response/AKA'-Synchronization-Failure, 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'-Authentication-Reject</name>
<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 numbered="true" toc="default">
<name>EAP-Response/AKA'-Client-Error</name>
<t>There are no changes for the EAP-Response/AKA'-Client-Error,
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-Response/AKA'-Notification.</t>
</section>
</section>
</section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<t>This section deals only with changes to security considerations for
EAP-AKA' or new information that has been gathered since the publication
of <xref target="RFC9048" format="default"/>.</t>
<t>As discussed in <xref target="sec_intro" format="default"/>, FS is an important countermeasure against adversaries who gain
access to long-term keys. The long-term keys can be best protected
with good processes, e.g., restricting access to the key material within
a factory or among personnel, etc. Even so, not all attacks can be
entirely ruled out. For instance, well-resourced adversaries 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 (see <xref target="NSA-ZT"
format="default"/> and <xref target="NIST-ZT" format="default"/>). One type
of breach is key compromise or key exfiltration.</t>
<t>If a mechanism without ephemeral key exchange (such as 5G-AKA or
EAP-AKA') is used, the effects of key compromise are devastating. There
are serious consequences to not properly providing FS for
the key establishment, for the control plane and the user plane, and for
both directions:
</t>
<ol spacing="normal" type="1"><li>
<t>An attacker can decrypt 5G communication that they
previously recorded.</t>
</li>
<li>
<t>A passive attacker can eavesdrop (decrypt) all
future 5G communication.</t>
</li>
<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>
</li>
</ol>
<t>At the time of writing, best practice security is to mandate FS (as is
done in Wi-Fi Protected Access 3 (WPA3), EAP-TLS 1.3, EAP-TTLS 1.3,
Internet Key Exchange Protocol Version 2 (IKEv2), Secure Shell (SSH),
QUIC, WireGuard, Signal, etc.). In deployments, it is recommended that
EAP-AKA methods without FS be phased out in the long
term.</t>
<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 exchange 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
an EAP-AKA' authentication run ends, the session that it was used
to protect is closed, and the corresponding keys are destroyed. Even someone who has recorded all of the data from the
authentication run and session and gets access to all of the AKA
long-term keys cannot reconstruct the keys used to protect the
session or any previous session, without doing a brute-force
search of the session key space.</t>
<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
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>Using EAP-AKA' FS once provides FS. FS limits the effect of key leakage
in one direction (compromise of a key at time T2 does not compromise some
key at time T1 where T1 < T2). Protection in the other 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
passive attackers. Using the terms in <xref target="RFC7624"
format="default"/>, FS without rerunning ECDHE does not stop an attacker
from doing static key exfiltration. Frequently rerunning EC(DHE) forces an
attacker to do dynamic key exfiltration (or content exfiltration).</t>
<section numbered="true" toc="default">
<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
recompute those keys.</t>
<t>Similarly, other parts of the system matter. For instance, when the keys generated by EAP are transported to a
pass-through authenticator, such transport must also provide forward secure encryption with respect to the long-term keys used to establish
its security. Otherwise, an adversary may attack the transport connection
used to carry keys from EAP, and use this method to gain access to current and past
keys from EAP, which, in turn, would lead to the compromise of anything protected by those EAP keys.</t>
<t>Of course, these considerations
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>
<dl newline="true" spacing="normal">
<dt>Protected ciphersuite negotiation:</dt>
<dd>
<t>EAP-AKA' has a negotiation mechanism for selecting the KDFs, and this mechanism has been extended by the
extension specified in this document. The resulting mechanism
continues to be secure against bidding-down attacks.</t>
<t>There are two specific needs in the negotiation mechanism:</t>
<dl newline="true" spacing="normal">
<dt>Negotiating KDFs within the extension:</dt>
<dd>
The negotiation mechanism allows changing the offered KDF, but the change is visible in the final
EAP-Request/AKA'-Challenge message that the Server sends to the Peer.
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.</dd>
<dt>Negotiating the use of this extension:</dt>
<dd>
<t> 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.</t>
<t>These attempts will be detected, except of course, if the
adversary holds the long-term key and is willing to engage in
an active attack. For instance, such an attack can 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.
</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>
<ul spacing="normal">
<li>
<t>In a 5G context, other parts of the connection setup involve
public key cryptography, so while performing additional operations
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>
<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
message will not be sent unless the user has been identified as
an active subscriber of the operator in question. While the initial identity
can be spoofed before authentication has succeeded, this reduces the efficiency of
an attack.</t>
</li>
<li>
<t>Finally, this memo specifies an order in which computations and
checks must occur. For instance, when processing the EAP-Request/AKA'-Challenge
message, the AKA authentication must be checked and
succeed before the Peer proceeds to calculating or processing the
FS-related parameters (see <xref target="procakachallresp" format="default"/>). The same is true of an
EAP-Response/AKA'-Challenge (see <xref target="procakachallresp" format="default"/>). This ensures that the parties need to
show possession of the long-term key in some way, and only then
will the FS calculations become active. This limits the
DoS to specific, identified subscribers. While
botnets and other forms of malicious parties could take advantage
of actual subscribers and their key material, at least such
attacks are:</t>
<ol type="a"><li>limited in terms of subscribers they control, and</li>
<li>identifiable for the purposes of blocking the affected
subscribers.</li></ol>
</li>
</ul>
</section>
<section numbered="true" toc="default">
<name>Identity Privacy</name>
<t>As specified in <xref target="secMessageProc" format="default"/>, the Peer identity sent
in the Identity Response message needs
to follow the privacy-friendly requirements in <xref target="RFC9190" format="default"/>.</t>
</section>
<section anchor="unp" numbered="true" toc="default">
<name>Unprotected Data and Privacy</name>
<t>Unprotected data and metadata can reveal sensitive information and need to be selected with care.
In particular, this applies to
AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF_FS, and
AT_PUB_ECDHE reveal the used cryptographic algorithms; if these depend on the
Peer identity, they leak information about the Peer. AT_KDF_INPUT reveals the
network name, although that is done on purpose to bind the authentication to a particular context.</t>
<t>An attacker observing network traffic may use the above types of information
for traffic flow analysis or to track an endpoint.</t>
</section>
<section numbered="true" toc="default">
<name>Forward Secrecy within AT_ENCR</name>
<t>The keys K_encr and K_aut are calculated and used before the shared secret from the ephemeral
key exchange is available.</t>
<t>K_encr and K_aut are used to encrypt and calculate a MAC in the
EAP-Req/AKA'-Challenge message, especially the DH g<sup>x</sup>
ephemeral pub key. At that point, the Server does not yet have the
corresponding g<sup>y</sup> from the Peer and cannot compute the
shared secret. K_aut is then used as the authentication key for the
shared secret.</t>
<t>However, for K_encr, none of the encrypted data sent in the
EAP-Req/AKA'-Challenge message in the AT_ENCR attribute will be a
forward secret. That data may include re-authentication pseudonyms, so
an adversary compromising the long-term key would be able to link
re-authentication protocol runs when pseudonyms are used, within a
sequence of runs followed after a full EAP-AKA' authentication. No
such linking would be possible across different full authentication
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 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 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>However, this would not affect the ability of EAP-AKA', with or
without this extension, to authenticate properly. As symmetric key
cryptography is safe even if CRQCs are built, an adversary still will
not be able to disrupt authentication as it requires computing a
correct AT_MAC value. This computation requires the K_aut key, which is
based on the MK, CK', and IK', but not SHARED_SECRET.</t>
<t>Other output keys do include SHARED_SECRET via MK_ECDHE, but they still 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 output keys either.</t>
<t>However, if the adversary has also obtained knowledge of the long-term key, they
could then compute the CK', IK', SHARED_SECRET, and any derived output keys. This means that
the introduction of a powerful enough quantum computer would disable
this protocol extension's ability to provide the forward secrecy
capability. This would
make it necessary to update the current ECC algorithms in this document to PQC algorithms. This
document does not add such algorithms, but a future update can do that.
</t>
<t>Symmetric algorithms used in EAP-AKA' FS, such as HMAC-SHA-256 and
the algorithms used to generate AT_AUTN and AT_RES, are practically
secure against even large, robust quantum computers. EAP-AKA' FS is
currently only specified for use with ECDHE key exchange algorithms,
but use of any Key Encapsulation Method (KEM), including PQC KEMs, can
be specified in the future. While the key exchange is specified with
terms of the Diffie-Hellman protocol, the key exchange adheres to a
KEM interface. AT_PUB_ECDHE would then contain either the ephemeral
public key of the Server or the SHARED_SECRET encapsulated with the
Server's public key. Note that the use of a KEM might require other
changes, such as including the ephemeral public key of the Server in
the key derivation to retain the property that both parties contribute
randomness to the session key.
</t>
</section>
</section>
<section numbered="true" toc="default">
<name>IANA Considerations</name>
<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>
<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>
<dl>
<dt>152:</dt><dd>AT_PUB_ECDHE (<xref target="at_pub_dh"
format="default"/>)</dd>
<dt>153:</dt><dd>AT_KDF_FS (<xref target="at_kdf_dh" format="default"/>)</dd>
</dl>
<t>IANA has also created the "EAP-AKA' AT_KDF_FS
Key Derivation Function Values" registry to represent FS KDF
types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA' with ECDHE and
P-256" types (1 and 2, see <xref target="kdf2" format="default"/>) have been 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.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4187.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5448.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7624.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9048.xml"/>
<reference anchor="SP-800-186" target="https://doi.org/10.6028/NIST.SP.800-186">
<front>
<title>Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters</title>
<author initials="L." surname="Chen">
<organization>National Institute of Standards and Technology</organization>
</author>
<author initials="D." surname="Moody"/>
<author initials="K." surname="Randall"/>
<author initials="A." surname="Regenscheid"/>
<author initials="A." surname="Robinson"/>
<date month="February" year="2023"/>
</front>
<seriesInfo name="NIST" value="SP 800-186"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-186"/>
</reference>
<reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf">
<front>
<title>SEC 1: Elliptic Curve Cryptography</title>
<author>
<organization>Standards for Efficient Cryptography</organization>
</author>
<date month="May" year="2009"/>
</front>
<refcontent>Version 2.0</refcontent>
</reference>
<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>
<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>National Institute of Standards and Technology</organization>
</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>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4186.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5216.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9190.xml"/>
<reference anchor="TrustCom2015" target="https://doi.org/10.1109/Trustcom.2015.506">
<front>
<title>A USIM Compatible 5G AKA Protocol with Perfect Forward Secrecy</title>
<author initials="J." surname="Arkko"/>
<author initials="K." surname="Norrman"/>
<author initials="M." surname="Näslund"/>
<author initials="B." surname="Sahlin"/>
<date month="August" year="2015"/>
</front>
<refcontent>IEEE International Conference on Trust, Security and
Privacy in Computing and Communications (TrustCom)</refcontent>
<seriesInfo name="DOI" value="10.1109/Trustcom.2015.506"/>
</reference>
<reference anchor="Heist2015" target="https://theintercept.com/2015/02/19/great-sim-heist/">
<front>
<title>The Great SIM Heist</title>
<author initials="J." surname="Scahill"/>
<author initials="J." surname="Begley"/>
<date month="February" year="2015"/>
</front>
</reference>
<reference anchor="DOW1992" target="https://doi.org/10.1007/BF00124891">
<front>
<title>Authentication and authenticated key exchanges</title>
<author initials="W." surname="Diffie"/>
<author initials="P. C." surname="Van Oorschot"/>
<author initials="M. J." surname="Wiener"/>
<date month="June" year="1992"/>
</front>
<refcontent>Designs, Codes and Cryptography, vol. 2, pp. 107-125</refcontent>
<seriesInfo name="DOI" value="10.1007/BF00124891"/>
</reference>
<reference anchor="TS.33.501">
<front>
<title>Security architecture and procedures for 5G System</title>
<author>
<organization>3GPP</organization>
</author>
<date month="September" year="2024"/>
</front>
<seriesInfo name="3GPP TS" value="33.501"/>
<refcontent>Version 19.0.0</refcontent>
</reference>
<reference anchor="NIST-ZT" target="https://www.nccoe.nist.gov/sites/default/files/2024-07/zta-nist-sp-1800-35-preliminary-draft-4.pdf">
<front>
<title>Implementing a Zero Trust Architecture</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date year="2024" month="July"/>
</front>
<seriesInfo name="NIST" value="SP 1800-35"/>
</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">
<front>
<title>Embracing a Zero Trust Security Model</title>
<author>
<organization>National Security Agency</organization>
</author>
<date year="2021" month="February"/>
</front>
</reference>
</references>
</references>
<section numbered="false" toc="default">
<name>Acknowledgments</name>
<t>The authors would like to note that the technical solution in this
document came out of the TrustCom paper <xref target="TrustCom2015"
format="default"/>, whose authors were <contact fullname="J. Arkko"/>,
<contact fullname="K. Norrman"/>, <contact fullname="M. Näslund"/>, and
<contact fullname="B. Sahlin"/>. This document also uses a lot of
material from <xref target="RFC4187" format="default"/> by <contact
fullname="J. Arkko"/> and <contact fullname="H. Haverinen"/>, as well as
<xref target="RFC5448" format="default"/> by <contact
fullname="J. Arkko"/>, <contact fullname="V. Lehtovirta"/>, and <contact
fullname="P. Eronen"/>.</t>
<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>
</rfc>