<?xml version="1.0" encoding="utf-8" ?> version='1.0' encoding='UTF-8'?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<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">
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc autobreaks="yes"?>
<?rfc tocindent="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> consensus="true" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="EAP-AKA' FS">Forward Secrecy for 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" initials="J." surname="Arkko" fullname="Jari Arkko">
      <organization>Ericsson</organization>
      <address>
        <postal>
<street/>
          <city>Jorvas</city>
          <code>02420</code>
          <country>Finland</country>
        </postal>
        <email>jari.arkko@piuha.net</email>
      </address>
    </author>
    <author initials="K" initials="K." surname="Norrman" fullname="Karl Norrman">
      <organization>Ericsson</organization>
      <address>
        <postal>
<street/>
          <city>Stockholm</city>
          <code>16483</code>
          <country>Sweden</country>
        </postal>
        <email>karl.norrman@ericsson.com</email>
      </address>
    </author>
    <author initials="J" initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
      <organization>Ericsson</organization>
      <address>
        <postal>
<street/>
          <city>Kista</city>
          <code>164 40</code>
          <country>Sweden</country>
        </postal>
        <email>john.mattsson@ericsson.com</email>
      </address>
    </author>

    <date month="December" year="2024"/>

    <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, the improved "Improved Extensible Authentication
      Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'),
      (EAP-AKA')", and its predecessor RFC 5448 with an optional extension providing ephemeral key
      exchange.
  Similarly, this document also updates the earlier version
  of the EAP-AKA' specification in RFC 5448. The extension EAP-AKA' Forward
      Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the
      session keys generated as a part of the authentication run in
      EAP-AKA'. This prevents an attacker who has gained access to the
      long-term key from obtaining session keys established in the past,
      assuming these have been properly deleted. In addition, EAP-AKA' FS
      mitigates passive attacks (e.g., large scale large-scale pervasive monitoring)
      against future sessions. This forces attackers to use active attacks
      instead.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="sec:intro" title="Introduction"> 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 occur, for
  instance, during
      instance:</t>
      <ul><li>during the manufacturing process of USIM cards, during cards,</li>
      <li>during the transfer of the cards and associated information to
      the operator, and when and</li>
      <li>when a system is running. Since running.</li></ul>
      <t>Since
  the publication of reports about such attacks
  (see <xref target="Heist2015"/>, 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"/>.</t> 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"/>, the Improved target="RFC9048" format="default"/>,
      "Improved Extensible Authentication Protocol Method for 3GPP Mobile
      Network Authentication and Key Agreement (EAP-AKA') method, (EAP-AKA')", with an optional
      extension providing ephemeral key exchange
  minimizing 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"/> 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, exchange forces
  attackers to be active if they want access to future session keys keys, even
  if they have access to the long-term key. This is beneficial, beneficial because
  active attacks demand much many more resources to launch, launch and are easier to
  detect. As
  with other protocols, an active attacker with access to the
  long-term key material will will, of course 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"/> 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 a the
  potential to improve security for many users.</t>
    </section>
    <section title="Requirements Language">

  <t>The numbered="true" toc="default">
      <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<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
  "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP
  14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>
    </section>
    <section title="Protocol numbered="true" toc="default">
      <name>Protocol Design and Deployment Objectives"> Objectives</name>
      <t>The extension specified here re-uses 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"/>, target="TrustCom2015" format="default"/>) and uses much of the same
  material,
  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, 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 forward secrecy FS to the existing mobile
  network infrastructure can be done in multiple different ways, this
  document specifies a solution that is relatively easily
  deployable. easy to deploy. In particular:
  <list style="symbols">

    <t>As
      </t>
      <ul spacing="normal">
        <li>As noted above, no new credentials are needed; there is no change
        to USIM cards.</t>

    <t>FS 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.</t>

    <t>Key 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).</t>

    <t>While
        keys).</li>
        <li>While EAP-AKA' is just one EAP method, for practical purposes
    forward secrecy purposes,
        FS being available for both EAP-TLS <xref
    target="RFC5216"/>
        target="RFC5216" format="default"/> <xref target="RFC9190"/> target="RFC9190"
        format="default"/> and EAP-AKA' ensures that that, for many practical systems forward
    secrecy
        systems, FS can be enabled for either all or a significant
        fraction of
    users.</t>

  </list></t> users.</li>
      </ul>
    </section>
    <section title="Background"> numbered="true" toc="default">
      <name>Background</name>
      <t>The reader is assumed to
    have a basic understanding of the EAP framework <xref target="RFC3748"/>.</t> target="RFC3748" format="default"/>.</t>
      <section title="AKA"> numbered="true" toc="default">
        <name>AKA</name>
        <t>We use the term Authentication "Authentication and Key Agreement (AKA) 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 adds 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 UICC (Universal Universal
    Integrated Circuit Card), Card (UICC), an embedded UICC, or integrated in a
    Trusted Execution Environment (TEE). In this document document, we use the
    term "USIM card" to refer to any Subscriber Identity Module (SIM)
    capable of running AKA.</t>

        <t>The goal of AKA is to mutually authenticate the USIM and the
        so-called home environment, which is the authentication server Server in the subscribers
        subscriber's home operator's network.</t>

        <t>AKA works in the following manner:
    <list style="symbols">

   <t>The manner:</t>
        <ul spacing="normal">
          <li>The USIM and the home environment have agreed on a long-term
          symmetric key beforehand.</t>
   <t>The 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.</t>
   <t>The CK.</li>
          <li>The authentication vector is passed to the serving network,
          which uses it to authenticate the device.</t>
   <t>The device.</li>
          <li>The RAND and the AUTN are delivered to the USIM.</t>
   <t>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.</t>
   <t>The 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.</t>
    </list></t>
          environment.</li>
        </ul>
      </section>
      <section title="EAP-AKA' Protocol"> 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 Authentication
    Database (AD) generates authentication vectors. The 3GPP authentication
    server
    Server takes the role of EAP server. Server. The USIM combined with
    the mobile phone takes the role of the client.
    The difference between EAP-AKA <xref target="RFC4187"/> target="RFC4187" format="default"/> and
    EAP-AKA' <xref target="RFC9048"/> target="RFC9048" format="default"/> is that EAP-AKA'
    binds the derived keys to the name of the access network.
    <xref target="figaka"/> 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"/> target="RFC9048" format="default"/> and <xref target="RFC4187"/>. target="RFC4187" format="default"/>.
    Note the use of EAP-terminology EAP terminology from hereon.  That is, the 3GPP
    serving network takes on the role of an EAP access network.
</t>
        <figure title="EAP-AKA' Authentication Process" anchor="figaka">
          <name>EAP-AKA' Authentication Process</name>
          <artset>
            <artwork type="ascii-art"><![CDATA[ type="ascii-art" name="" align="left" alt=""><![CDATA[
 Peer                                                        Server
   |                                                            |
   |                                       EAP-Request/Identity |
   |<-----------------------------------------------------------+
   |                                                            |
   | EAP-Response/Identity                                      |
   | (Includes user's Network Access Identifier, NAI) Identifier (NAI))          |
   +----------------------------------------------------------->|
   |      +-----------------------------------------------------+--+    +-------------------------------------------------------+--+
   |    | The Server determines the network name and ensures that  |
   |    | the given access network is authorized to use the        |
   |    | claimed name.  The server Server then runs the AKA' algorithms EAP-AKA'         |
   |    | algorithms generating RAND and AUTN, and derives session keys from |
   |    | keys from CK' and IK'.  RAND and AUTN are sent as AT_RAND and        |
   |    | AT_RAND and AT_AUTN attributes, whereas the network name is |
   |    | 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 Peer determines what the network name should be,    |     |
| based on, e.g., what access technology it is using.     |     |
| The peer 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    |     |
| in running the AKA' EAP-AKA' algorithms, verifying AUTN from |     |
| AT_AUTN and MAC Message Authentication Code (MAC) from the  |     |
| AT_MAC attributes.  The peer Peer then  |      |
| generates RES.  The peer   |     |
| Peer also derives session keys from CK'/IK.  The AT_RES |     |
| 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     |
   |      | both compared values match, respectively.              |
   |      +-----------------------------------------------------+--+
   |                                                            |
   |                                                EAP-Success |
   |<-----------------------------------------------------------+
   |                                                            |
]]></artwork>

<artwork type="svg"><svg type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="832" width="552" viewBox="0 0 552 832" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">

                <path d="M 8,400 L 8,608" fill="none" stroke="black"/>
                <path d="M 32,48 L 32,400" fill="none" stroke="black"/>
                <path d="M 32,608 L 32,816" fill="none" stroke="black"/>
                <path d="M 88,160 L 88,320" fill="none" stroke="black"/>
                <path d="M 88,688 L 88,752" fill="none" stroke="black"/>
                <path d="M 464,400 L 464,608" fill="none" stroke="black"/>
                <path d="M 520,48 L 520,160" fill="none" stroke="black"/>
                <path d="M 520,320 L 520,688" fill="none" stroke="black"/>
                <path d="M 520,752 L 520,816" fill="none" stroke="black"/>
                <path d="M 544,160 L 544,320" fill="none" stroke="black"/>
                <path d="M 544,688 L 544,752" fill="none" stroke="black"/>
                <path d="M 40,80 L 520,80" fill="none" stroke="black"/>
                <path d="M 32,144 L 512,144" fill="none" stroke="black"/>
                <path d="M 88,160 L 544,160" fill="none" stroke="black"/>
                <path d="M 88,320 L 544,320" fill="none" stroke="black"/>
                <path d="M 40,384 L 520,384" fill="none" stroke="black"/>
                <path d="M 8,400 L 464,400" fill="none" stroke="black"/>
                <path d="M 8,608 L 464,608" fill="none" stroke="black"/>
                <path d="M 32,672 L 512,672" fill="none" stroke="black"/>
                <path d="M 88,688 L 544,688" fill="none" stroke="black"/>
                <path d="M 88,752 L 544,752" fill="none" stroke="black"/>
                <path d="M 40,800 L 520,800" fill="none" stroke="black"/>
                <path d="M 144,640 L 144,640" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="520,672 508,666.4 508,677.6" 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" y="132">Identifier,</text> y="132">Identifier</text>
                  <text x="412" y="132">NAI)</text> y="132">(NAI))</text>
                  <text x="124" y="180">Server</text>
                  <text x="196" y="180">determines</text>
                  <text x="256" y="180">the</text>
                  <text x="304" y="180">network</text>
                  <text x="356" y="180">name</text>
                  <text x="392" y="180">and</text>
                  <text x="440" y="180">ensures</text>
                  <text x="492" y="180">that</text>
                  <text x="112" y="196">the</text>
                  <text x="152" y="196">given</text>
                  <text x="204" y="196">access</text>
                  <text x="264" y="196">network</text>
                  <text x="308" y="196">is</text>
                  <text x="364" y="196">authorized</text>
                  <text x="420" y="196">to</text>
                  <text x="448" y="196">use</text>
                  <text x="480" y="196">the</text>
                  <text x="128" y="212">claimed</text>
                  <text x="184" y="212">name.</text>
                  <text x="224" y="212">The</text>
                  <text x="268" y="212">server</text> y="212">Server</text>
                  <text x="316" y="212">then</text>
                  <text x="356" y="212">runs</text>
                  <text x="392" y="212">the</text>
                  <text x="428" y="212">AKA'</text>
                  <text x="492" y="212">algorithms</text>
                  <text x="140" y="228">generating</text>
                  <text x="204" y="228">RAND</text>
                  <text x="240" y="228">and</text>
                  <text x="280" y="228">AUTN,</text>
                  <text x="336" y="228">derives</text>
                  <text x="400" y="228">session</text>
                  <text x="452" y="228">keys</text>
                  <text x="492" y="228">from</text>
                  <text x="112" y="244">CK'</text>
                  <text x="144" y="244">and</text>
                  <text x="180" y="244">IK'.</text>
                  <text x="220" y="244">RAND</text>
                  <text x="256" y="244">and</text>
                  <text x="292" y="244">AUTN</text>
                  <text x="328" y="244">are</text>
                  <text x="364" y="244">sent</text>
                  <text x="396" y="244">as</text>
                  <text x="440" y="244">AT_RAND</text>
                  <text x="488" y="244">and</text>
                  <text x="128" y="260">AT_AUTN</text>
                  <text x="208" y="260">attributes,</text>
                  <text x="288" y="260">whereas</text>
                  <text x="336" y="260">the</text>
                  <text x="384" y="260">network</text>
                  <text x="436" y="260">name</text>
                  <text x="468" y="260">is</text>
                  <text x="144" y="276">transported</text>
                  <text x="204" y="276">in</text>
                  <text x="232" y="276">the</text>
                  <text x="300" y="276">AT_KDF_INPUT</text>
                  <text x="396" y="276">attribute.</text>
                  <text x="468" y="276">AT_KDF</text>
                  <text x="128" y="292">signals</text>
                  <text x="176" y="292">the</text>
                  <text x="212" y="292">used</text>
                  <text x="248" y="292">key</text>
                  <text x="308" y="292">derivation</text>
                  <text x="392" y="292">function.</text>
                  <text x="448" y="292">The</text>
                  <text x="496" y="292">session</text>
                  <text x="116" y="308">keys</text>
                  <text x="152" y="308">are</text>
                  <text x="188" y="308">used</text>
                  <text x="220" y="308">to</text>
                  <text x="260" y="308">create</text>
                  <text x="304" y="308">the</text>
                  <text x="348" y="308">AT_MAC</text>
                  <text x="420" y="308">attribute.</text>
                  <text x="404" y="356">EAP-Request/AKA'-Challenge</text>
                  <text x="160" y="372">(AT_RAND,</text>
                  <text x="236" y="372">AT_AUTN,</text>
                  <text x="304" y="372">AT_KDF,</text>
                  <text x="392" y="372">AT_KDF_INPUT,</text>
                  <text x="480" y="372">AT_MAC)</text>
                  <text x="32" y="420">The</text>
                  <text x="68" y="420">peer</text> 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> y="452">Peer</text>
                  <text x="108" y="452">also</text>
                  <text x="168" y="452">retrieves</text>
                  <text x="224" y="452">the</text>
                  <text x="272" y="452">network</text>
                  <text x="324" y="452">name</text>
                  <text x="364" y="452">sent</text>
                  <text x="396" y="452">by</text>
                  <text x="424" y="452">the</text>
                  <text x="48" y="468">network</text>
                  <text x="100" y="468">from</text>
                  <text x="136" y="468">the</text>
                  <text x="204" y="468">AT_KDF_INPUT</text>
                  <text x="300" y="468">attribute.</text>
                  <text x="360" y="468">The</text>
                  <text x="392" y="468">two</text>
                  <text x="432" y="468">names</text>
                  <text x="32" y="484">are</text>
                  <text x="84" y="484">compared</text>
                  <text x="136" y="484">for</text>
                  <text x="212" y="484">discrepancies,</text>
                  <text x="288" y="484">and</text>
                  <text x="316" y="484">if</text>
                  <text x="348" y="484">they</text>
                  <text x="380" y="484">do</text>
                  <text x="408" y="484">not</text>
                  <text x="44" y="500">match,</text>
                  <text x="88" y="500">the</text>
                  <text x="164" y="500">authentication</text>
                  <text x="236" y="500">is</text>
                  <text x="284" y="500">aborted.</text>
                  <text x="364" y="500">Otherwise,</text>
                  <text x="424" y="500">the</text>
                  <text x="48" y="516">network</text>
                  <text x="100" y="516">name</text>
                  <text x="140" y="516">from</text>
                  <text x="212" y="516">AT_KDF_INPUT</text>
                  <text x="304" y="516">attribute</text>
                  <text x="356" y="516">is</text>
                  <text x="388" y="516">used</text>
                  <text x="420" y="516">in</text>
                  <text x="48" y="532">running</text>
                  <text x="96" y="532">the</text>
                  <text x="132" y="532">AKA'</text>
                  <text x="200" y="532">algorithms,</text>
                  <text x="288" y="532">verifying</text>
                  <text x="348" y="532">AUTN</text>
                  <text x="388" y="532">from</text>
                  <text x="48" y="548">AT_AUTN</text>
                  <text x="96" y="548">and</text>
                  <text x="128" y="548">MAC</text>
                  <text x="164" y="548">from</text>
                  <text x="212" y="548">AT_MAC</text>
                  <text x="288" y="548">attributes.</text>
                  <text x="352" y="548">The</text>
                  <text x="388" y="548">peer</text> y="548">Peer</text>
                  <text x="428" y="548">then</text>
                  <text x="56" y="564">generates</text>
                  <text x="116" y="564">RES.</text>
                  <text x="152" y="564">The</text>
                  <text x="188" y="564">peer</text> y="564">Peer</text>
                  <text x="228" y="564">also</text>
                  <text x="280" y="564">derives</text>
                  <text x="344" y="564">session</text>
                  <text x="396" y="564">keys</text>
                  <text x="436" y="564">from</text>
                  <text x="52" y="580">CK'/IK'.</text>
                  <text x="104" y="580">The</text>
                  <text x="148" y="580">AT_RES</text>
                  <text x="192" y="580">and</text>
                  <text x="236" y="580">AT_MAC</text>
                  <text x="308" y="580">attributes</text>
                  <text x="368" y="580">are</text>
                  <text x="68" y="596">constructed.</text>
                  <text x="92" y="644">EAP-Response</text>
                  <text x="204" y="644">AKA'-Challenge</text>
                  <text x="76" y="660">(AT_RES,</text>
                  <text x="144" y="660">AT_MAC)</text>
                  <text x="124" y="708">Server</text>
                  <text x="180" y="708">checks</text>
                  <text x="224" y="708">the</text>
                  <text x="256" y="708">RES</text>
                  <text x="288" y="708">and</text>
                  <text x="320" y="708">MAC</text>
                  <text x="364" y="708">values</text>
                  <text x="428" y="708">received</text>
                  <text x="476" y="708">in</text>
                  <text x="124" y="724">AT_RES</text>
                  <text x="168" y="724">and</text>
                  <text x="216" y="724">AT_MAC,</text>
                  <text x="304" y="724">respectively.</text>
                  <text x="392" y="724">Success</text>
                  <text x="460" y="724">requires</text>
                  <text x="516" y="724">both</text>
                  <text x="132" y="740">compared</text>
                  <text x="196" y="740">values</text>
                  <text x="252" y="740">match,</text>
                  <text x="336" y="740">respectively.</text>
                  <text x="464" y="788">EAP-Success</text>
                </g>
              </svg>
            </artwork>
          </artset>
        </figure>
      </section>
      <section anchor="attacks" title="Attacks numbered="true" toc="default">
        <name>Attacks Against Long-Term Keys in Smart Cards"> Cards</name>
        <t>The general security properties and potential vulnerabilities of
        AKA and EAP-AKA' are discussed in <xref
    target="RFC9048"/>.</t> 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 fail, at least to some
    extent 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 to compromise 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 title="Protocol Overview"> numbered="true" toc="default">
      <name>Protocol Overview</name>
      <t>Forward secrecy Secrecy (FS) for EAP-AKA' is achieved by using an Elliptic
      Curve Diffie-Hellman (ECDH) exchange <xref target="RFC7748"/>. 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,
  e.g., ciphersuite. For example, for X25519 X25519, this is done as
      specified in <xref target="RFC7748"/>. target="RFC7748" format="default"/>.  This method is
      referred to as ECDHE, "ECDHE", where the last 'E' "E" stands for Ephemeral. "Ephemeral". The
      two initially registered elliptic curves and their wire formats are
      chosen to align with the elliptic curves and formats specified for
      Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of
      3GPP TS 33.501 <xref target="TS.33.501"/>.</t> 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 Server and peer, Peer and to establish keying 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"/> below 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 represent
      represents the 3GPP Authentication Database (AD) and server. Server.  The
      details of those interactions are outside the scope of this document, document;
      however, and the reader is referred to the 3GPP specifications. For 5G specifications (for 5G,
      this is specified in 3GPP TS 33.501 <xref target="TS.33.501"/></t> target="TS.33.501"
      format="default"/>).</t>
      <figure title="EAP-AKA' anchor="figakafs">
        <name>EAP-AKA' FS Authentication Process" anchor="figakafs"> Process</name>
        <artset>
          <artwork type="ascii-art"><![CDATA[ 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. Peer.  The server Server |
   |      | then asks the help of the AD to run AKA EAP-AKA algorithms,  |
   |      | generating RAND, AUTN, XRES, CK, and IK.  Typically, the |
   |      | AD performs the first part of key derivations so that the    |
   |      | the authentication server Server gets the CK' and IK' keys already  |
   |      | 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    |
   |      | key of that key pair and the first EAP method message to |
   |      | the peer. 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 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 Peer checks if it wants to do the FS extension. If    |      |
| If yes, it will eventually respond with AT_PUB_ECDHE and   |      |
| and AT_MAC.  If not, it will ignore AT_PUB_ECDHE and   |      |
| AT_KDF_FS and base all calculations on basic EAP-AKA'  |      |
| attributes, continuing just as in EAP-AKA' per RFC     |      |
| 9048 rules.  In any case, the peer Peer needs to query the  |      |
| auth parameters from the USIM card.                    |      |
+--+--------------+----------------------------+---------+      |
   |              |                            |                |
   |   RAND, AUTN |                            |                |
   |<-------------+                            |                |
   |              |                            |                |
   | CK, IK, RES  |                            |                |
   +------------->|                            |                |
+--+--------------+----------------------------+---------+      |
| The peer Peer now has everything to respond.  If it wants to   |      |
| to participate in the FS extension, it will then generate       |      |
| generate its key pair, calculate a shared key based on its key |      |
| its key pair and the server's Server's public key.  Finally, it proceeds |      |
| proceeds to derive all EAP-AKA' key values and constructs a         |      |
| constructs a full response.                            |      |
+--+--------------+----------------------------+---------+      |
   |              |                            |                |
   |              | EAP-Resp/AKA'-Challenge    |                |
   |              | AT_RES, AT_PUB_ECDHE,      |                |
   |              | AT_MAC                     |                |
   |              +--------------------------->|                |
   |      +-------+----------------------------+----------------+--+
   |      | The server 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    |
   |      | who held the long-term key, only an active attacker could    |
   |      | could have determined the generated session keys; in basic   |
   |      | basic EAP-AKA' the generated keys are only based on CK and |
   |      | and IK.                                                |
   |      +-------+----------------------------+----------------+--+
   |              |                            |                |
   |              |                EAP-Success |                |
   |              |<---------------------------+                |
   |              |                            |                |
]]></artwork>
<artwork type="svg"><svg type="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="1408" width="552" height="1200" width="875" viewBox="0 0 552 1408" 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 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 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 L 544,272" fill="none" stroke="black"/>
              <path d="M 544,432 L 544,576" fill="none" stroke="black"/>
              <path d="M 544,1136 L 544,1328" 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" fill="none" stroke="black"/>
              <path d="M 88,272 L 544,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" fill="none" stroke="black"/>
              <path d="M 88,576 L 544,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)"/>
              <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" y="180">Server</text>
                <text x="168" y="180">now</text>
                <text x="200" y="180">has</text>
                <text x="228" y="180">an</text>
                <text x="276" y="180">identity</text>
                <text x="328" y="180">for</text>
                <text x="360" y="180">the</text>
                <text x="400" y="180">peer.</text> y="180">Peer.</text>
                <text x="440" y="180">The</text>
                <text x="484" y="180">server</text> 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" y="196">AD</text>
                <text x="308" y="196">to</text>
                <text x="336" y="196">run</text>
                <text x="368" y="196">AKA</text>
                <text x="432" 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">IK.</text>
                <text x="436" y="212">Typically,</text>
                <text x="496" 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" y="228">derivations</text>
                <text x="476" y="228">so</text>
                <text x="508" y="228">that</text>
                <text x="112" y="244">the</text>
                <text x="188" y="244">authentication</text>
                <text x="276" y="244">server</text> y="244">Server</text>
                <text x="324" y="244">gets</text>
                <text x="360" y="244">the</text>
                <text x="392" y="244">CK'</text>
                <text x="424" y="244">and</text>
                <text x="456" y="244">IK'</text>
                <text x="492" y="244">keys</text>
                <text x="128" y="260">already</text>
                <text x="180" y="260">tied</text>
                <text x="212" y="260">to</text>
                <text x="232" y="260">a</text>
                <text x="284" y="260">particular</text>
                <text x="360" y="260">network</text>
                <text x="416" 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" y="452">Server</text>
                <text x="168" y="452">now</text>
                <text x="200" y="452">has</text>
                <text x="232" y="452">the</text>
                <text x="276" y="452">needed</text>
                <text x="364" y="452">authentication</text>
                <text x="456" y="452">vector.</text>
                <text x="500" 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" y="468">sends</text>
                <text x="424" y="468">the</text>
                <text x="468" y="468">public</text>
                <text x="512" y="468">key</text>
                <text x="108" y="484">of</text>
                <text x="140" y="484">that</text>
                <text x="176" y="484">key</text>
                <text x="212" y="484">pair</text>
                <text x="248" y="484">and</text>
                <text x="280" y="484">the</text>
                <text x="320" y="484">first</text>
                <text x="360" y="484">EAP</text>
                <text x="404" y="484">method</text>
                <text x="464" y="484">message</text>
                <text x="508" y="484">to</text>
                <text x="112" y="500">the</text>
                <text x="152" y="500">peer.</text> 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> 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> 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>
                <text x="36" y="724">yes,</text>
                <text x="68" y="724">it</text>
                <text x="100" y="724">will</text>
                <text x="164" y="724">eventually</text>
                <text x="240" y="724">respond</text>
                <text x="292" y="724">with</text>
                <text x="364" y="724">AT_PUB_ECDHE</text>
                <text x="432" y="724">and</text>
                <text x="48" y="740">AT_MAC.</text>
                <text x="92" y="740">If</text>
                <text x="124" y="740">not,</text>
                <text x="156" y="740">it</text>
                <text x="188" y="740">will</text>
                <text x="236" y="740">ignore</text>
                <text x="316" y="740">AT_PUB_ECDHE</text>
                <text x="384" 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" y="788">In</text>
                <text x="152" y="788">any</text>
                <text x="192" y="788">case,</text>
                <text x="232" y="788">the</text>
                <text x="268" y="788">peer</text> y="788">Peer</text>
                <text x="312" y="788">needs</text>
                <text x="348" y="788">to</text>
                <text x="384" y="788">query</text>
                <text x="424" 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> 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" y="948">If</text>
                <text x="372" y="948">it</text>
                <text x="408" y="948">wants</text>
                <text x="444" y="948">to</text>
                <text x="64" y="964">participate</text>
                <text x="124" y="964">in</text>
                <text x="152" y="964">the</text>
                <text x="180" y="964">FS</text>
                <text x="236" y="964">extension,</text>
                <text x="292" y="964">it</text>
                <text x="324" y="964">will</text>
                <text x="364" y="964">then</text>
                <text x="420" y="964">generate</text>
                <text x="32" y="980">its</text>
                <text x="64" y="980">key</text>
                <text x="104" y="980">pair,</text>
                <text x="168" y="980">calculate</text>
                <text x="216" y="980">a</text>
                <text x="252" y="980">shared</text>
                <text x="296" y="980">key</text>
                <text x="336" y="980">based</text>
                <text x="372" y="980">on</text>
                <text x="400" y="980">its</text>
                <text x="432" y="980">key</text>
                <text x="36" y="996">pair</text>
                <text x="72" y="996">and</text>
                <text x="104" y="996">the</text>
                <text x="156" y="996">server's</text> y="996">Server's</text>
                <text x="220" y="996">public</text>
                <text x="268" y="996">key.</text>
                <text x="324" y="996">Finally,</text>
                <text x="372" y="996">it</text>
                <text x="420" y="996">proceeds</text>
                <text x="28" y="1012">to</text>
                <text x="68" y="1012">derive</text>
                <text x="112" y="1012">all</text>
                <text x="164" y="1012">EAP-AKA'</text>
                <text x="216" y="1012">key</text>
                <text x="260" y="1012">values</text>
                <text x="304" y="1012">and</text>
                <text x="364" y="1012">constructs</text>
                <text x="416" y="1012">a</text>
                <text x="36" y="1028">full</text>
                <text x="96" 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> 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" 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" y="1204">Success</text>
                <text x="308" y="1204">requires</text>
                <text x="364" y="1204">both</text>
                <text x="396" y="1204">to</text>
                <text x="420" y="1204">be</text>
                <text x="456" y="1204">found</text>
                <text x="132" y="1220">correct.</text>
                <text x="188" y="1220">Note</text>
                <text x="228" y="1220">that</text>
                <text x="268" y="1220">when</text>
                <text x="308" y="1220">this</text>
                <text x="364" y="1220">document</text>
                <text x="412" y="1220">is</text>
                <text x="448" 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" y="1252">Even</text>
                <text x="316" y="1252">if</text>
                <text x="352" y="1252">there</text>
                <text x="392" y="1252">was</text>
                <text x="420" y="1252">an</text>
                <text x="468" y="1252">attacker</text>
                <text x="520" y="1252">who</text>
                <text x="116" y="1268">held</text>
                <text x="152" y="1268">the</text>
                <text x="208" y="1268">long-term</text>
                <text x="268" y="1268">key,</text>
                <text x="308" y="1268">only</text>
                <text x="340" y="1268">an</text>
                <text x="380" y="1268">active</text>
                <text x="444" y="1268">attacker</text>
                <text x="504" y="1268">could</text>
                <text x="116" y="1284">have</text>
                <text x="180" y="1284">determined</text>
                <text x="240" y="1284">the</text>
                <text x="296" y="1284">generated</text>
                <text x="368" y="1284">session</text>
                <text x="424" y="1284">keys;</text>
                <text x="460" y="1284">in</text>
                <text x="496" y="1284">basic</text>
                <text x="132" y="1300">EAP-AKA'</text>
                <text x="184" y="1300">the</text>
                <text x="240" y="1300">generated</text>
                <text x="300" y="1300">keys</text>
                <text x="336" y="1300">are</text>
                <text x="372" y="1300">only</text>
                <text x="416" y="1300">based</text>
                <text x="452" y="1300">on</text>
                <text x="476" y="1300">CK</text>
                <text x="504" y="1300">and</text>
                <text x="112" y="1316">IK.</text>
                <text x="328" y="1364">EAP-Success</text>
              </g>
            </svg>
          </artwork>
        </artset>
      </figure>
    </section>
    <section title="Extensions numbered="true" toc="default">
      <name>Extensions to EAP-AKA'"> EAP-AKA'</name>
      <section anchor="at_pub_dh" title="AT_PUB_ECDHE"> 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>

         <figure>
        <artset>
          <artwork type="ascii-art" align="center"> 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>
          <artwork type="svg"><svg 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>
         </figure>

        <t>The fields are as follows:</t>

         <t><list style="hanging">

           <t hangText="AT_PUB_ECDHE"><vspace blankLines="1"/>This

        <dl newline="true" spacing="normal">
          <dt>AT_PUB_ECDHE:</dt>
          <dd>This is set to TBA1 BY
           IANA.</t>

           <t hangText="Length"><vspace blankLines="1"/>The 152 by IANA.</dd>

          <dt>Length:</dt>
          <dd>This is the length of the attribute, set as other attributes in
          EAP-AKA <xref
           target="RFC4187"/>. 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).
           </t>

           <t hangText="Value"><vspace blankLines="1"/>This 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:

           <list style="symbols"> follows:</t>
            <ul spacing="normal">
              <li>
                <t>For X25519, the length of this value is 32 bytes, encoded
                as specified in <xref target="RFC7748"/> Section 5.</t> 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"/>.</t>
           </list>

           <vspace blankLines="1"/>

	   Because
                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 SHALL
            <bcp14>SHALL</bcp14> generate a fresh value for each run of the
            protocol.</t>

         </list></t>
          </dd>
        </dl>
      </section>

      <section anchor="at_kdf_dh" title="AT_KDF_FS"> numbered="true" toc="default">
        <name>AT_KDF_FS</name>
        <t>The AT_KDF_FS attribute indicates the used or desired forward secrecy FS key
         generation function, if the Forward Secrecy (FS) 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 which that is still used together with the forward secrecy FS KDF
         value. The basic KDF value is also used by those EAP peers 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 forward secrecy FS KDF values:
	 The values:</t>
	<ul>
	  <li>the
        basic KDF value in AT_KDF is 1, as specified in <xref target="RFC5448"/> target="RFC5448"
        format="default"/> and <xref target="RFC9048"/>,
	 and the forward secrecy 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"/>.</t> target="kdf2" format="default"/>.</li></ul>
        <t>Any future specifications that add either new basic KDF KDFs or new forward secrecy 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"/> target="RFC5448" format="default"/> and <xref target="RFC9048"/> target="RFC9048" format="default"/> may be extended in the future.</t>
        <t>The format of the AT_KDF_FS attribute is shown below.</t>

         <figure>
        <artset>
          <artwork type="ascii-art" align="center"> 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>
          <artwork type="svg"><svg 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>
         </figure>

        <t>The fields are as follows:</t>

         <t><list style="hanging">

           <t hangText="AT_KDF_FS"><vspace blankLines="1"/>This

        <dl newline="true" spacing="normal">
          <dt>AT_KDF_FS:</dt>
          <dd>This is set to TBA2 BY
           IANA.</t>

           <t hangText="Length"><vspace blankLines="1"/>The 153 by
           IANA.</dd>

          <dt>Length:</dt>
          <dd>This is the length of the
           attribute, MUST
           attribute; it <bcp14>MUST</bcp14> be set to 1.</t>

           <t hangText="FS 1.</dd>

          <dt>FS Key Derivation Function"><vspace blankLines="1"/>An Function:</dt>
          <dd>This is an enumerated value representing the forward secrecy key derivation function FS Key Derivation Function (KDF) that the
           server Server (or peer) Peer) wishes to use. See
          <xref target="kdf2"/> target="kdf2" format="default"/> for the functions specified
          in this document. Note: This this field has a different name space than
          the similar field in the AT_KDF attribute Key Derivation Function KDF
          defined in <xref
           target="RFC9048"/>.</t>

         </list></t> target="RFC9048" format="default"/>.</dd>
	</dl>

        <t>Servers MUST <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 Server includes a public key value for, however. So 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:
	 <list style="symbols">

	   <t>If attributes:</t>
        <ul spacing="normal">
          <li>If the peer Peer supports and is willing to use the FS Key Derivation Function KDF indicated
          by the first AT_KDF_FS attribute, and is willing and able to use the
          extension defined in this document, the function is taken into use will be used
          without any further negotiation.</t>

	   <t>If negotiation.</li>

          <li>If the peer Peer does not support this function or is unwilling to
          use it, it responds to the server Server with an indication that a
          different function is needed. Similarly Similarly, with the negotiation process
          defined in <xref
	   target="RFC9048"/> target="RFC9048" format="default"/> for AT_KDF, the peer
          Peer sends an EAP-Response/AKA'-Challenge message that contains only
          one attribute,
	   AT_KDF_FS AT_KDF_FS, with the value set to the desired
          alternative function from among the ones suggested by the server Server
          earlier. If there is no suitable alternative, the peer 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"/>).
          target="RFC4187" format="default"/>). The peer MUST 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 key derivation function; KDF; see below for
          further information).</t>

           <t>If information).</li>

          <li>If the peer Peer does not recognize the extension defined in this
          document or is unwilling to use it, it ignores the AT_KDF_FS attribute.</t>

	 </list></t>
          attribute.</li>
        </ul>

        <t>Upon receiving an EAP-Response/AKA'-Challenge message with an AT_KDF_FS attribute
        from the
         peer, Peer, the server 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 Server is not a valid alternative. If the peer Peer
        has replied with the first AT_KDF_FS value, the server 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 Server side, see Section 3 <xref target="RFC4187"
        sectionFormat="bare" section="3"/> and Figure 2 in <xref
        target="RFC4187"/>. Otherwise, the
         server 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, 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 Peer's request to change the FS Key Derivation Function KDF is the
        only valid situation where such duplication may occur.</t>
        <t>When the peer Peer receives the new EAP-Request/AKA'-Challenge message,
        it MUST <bcp14>MUST</bcp14> check that the requested change, and only the
        requested change change, occurred in the list of AT_KDF_FS attributes. If yes, so,
        it continues.  If not, it behaves as if AT_MAC had been were incorrect and
        fails the authentication. If the peer Peer receives multiple
        EAP-Request/AKA'-Challenge messages with differing AT_KDF_FS
        attributes without having requested negotiation, the peer MUST Peer
        <bcp14>MUST</bcp14> behave as if AT_MAC had been were incorrect and fail
        the authentication.</t>
      </section>
      <section anchor="kdf2" title="Forward numbered="true" toc="default">
        <name>Forward Secrecy Key Derivation Functions"> Functions</name>
        <t>Two new FS Key Derivation Function 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 key
         derivation function and KDF and, at the same time selects time, select an
        ECDHE group to be used.</t>
        <t>The FS Key Derivation Function KDF type value is only used in the
        AT_KDF_FS attribute. When the forward secrecy FS extension is used, the
        AT_KDF_FS attribute determines how to derive the
         keys MK_ECDHE, K_re, MSK, MK_ECDHE key, K_re key,
        Master Session Key (MSK), and EMSK. Extended Master Session Key (EMSK). The
        AT_KDF_FS attribute should not be confused with the different range of key derivation functions
        KDFs that can be represented in the AT_KDF
        attribute as defined in <xref target="RFC9048"/>. target="RFC9048"
        format="default"/>. When the forward secrecy FS extension is used, the
        AT_KDF attribute only specifies how to derive the
         keys MK, K_encr, Master Key (MK), the K_encr key, and K_aut.</t> 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"/>
        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 Key Derivation Function KDF field in the AT_KDF_FS
         attribute is set to 1 or 2 and the Key Derivation Function KDF field
         in the AT_KDF attribute is set to 1, the Master Key (MK) MK and
         accompanying keys are derived as follows.

         <figure> follows:
        </t>

        <artwork align="center"> 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>
         </figure></t>
]]></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 P-256, the SHARED_SECRET is the shared secret computed as
        specified in Section 5.7.1.2 of <xref target="SP-800-56A"/>. target="SP-800-56A"
        format="default"/>.  Public key validation requirements are defined in
        Section 5 of <xref target="SP-800-56A"/>. target="SP-800-56A" format="default"/>.  At least
        partial public-key public key validation MUST <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"/>.</t> target="SEC1"
        format="default"/>.</t>
        <t>For X25519 X25519, the SHARED_SECRET is the shared secret computed as specified in
	Section 6.1 of
	<xref target="RFC7748"/>. target="RFC7748" sectionFormat="of" section="6.1"/>. Both the peer Peer and the server
	MAY Server
	<bcp14>MAY</bcp14> check for the zero-value shared secret as specified in Section 6.1 of
	<xref target="RFC7748"/>.</t>

	 <t><list style="empty">

	   <t>Note: The 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,
	   if performed inappropriately, can provide an ability for attackers to
	listen to CPU power usage side channels. Refer to <xref target="RFC7748"/>
	target="RFC7748" format="default"/> for a description of how to
	perform this check in a way that it does not become a
	   problem.</t>

	 </list></t>
problem.</t></aside>

        <t>If validation of the other party's ephemeral public key or the shared secret fails,
	a party MUST <bcp14>MUST</bcp14> behave as if the current EAP-AKA' authentication process starts again from the beginning.</t>
        <t>The rest of the computation proceeds as defined in Section 3.3 of <xref
	 target="RFC9048"/>.</t>

            <t>For readability, an explanation of the notation used above
            is copied here: [n..m] denotes the substring from bit n to m.
            PRF' is a new pseudo-random function specified in <xref
            target="RFC9048"/>.  K_encr is the encryption key, 128 bits,
            K_aut is the authentication key, 256 bits, K_re is the
            re-authentication key, 256 bits, MSK is the Master Session
            Key, 512 bits, and EMSK is the Extended Master Session Key,
            512 bits. MSK and EMSK are outputs from a successful EAP
            method run <xref target="RFC3748"/>.</t>

         <t>CK and IK are produced by the AKA algorithm. IK' and CK'
         are derived as specified in <xref target="RFC9048"/> from IK
         and CK.</t>

         <t>The value "EAP-AKA'" is an eight-characters-long ASCII string.  It is
         used as is, without any trailing NUL characters. Similarly,
         "EAP-AKA' FS" is an eleven-characters-long ASCII string, also
         used as is.</t>

         <t>Identity is the peer identity as specified in Section 7 of <xref target="RFC4187"/>.
	 A privacy-friendly identifier <xref target="RFC9048"/> SHALL be used.</t>
        target="RFC9048" sectionFormat="of" section="3.3"/>.</t>

      </section>
      <section anchor="groups" title="ECDHE 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 deciding the decision to use of a particular key derivation
         function KDF in AT_KDF_FS.</t> the AT_KDF_FS attribute.</t>
        <t>For "EAP-AKA' with ECDHE and
         X25519"
         X25519", the group is the Curve25519 group specified in
         <xref target="RFC7748"/>. target="RFC7748" format="default"/>. The support for this group is REQUIRED.</t> <bcp14>REQUIRED</bcp14>.</t>
        <t>For "EAP-AKA' with ECDHE and P-256" 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"/>
        target="SP-800-186" format="default"/> or alternatively alternatively, Section 2.4.2
        of <xref target="SEC2"/>. target="SEC2" format="default"/>.  The support for this group
        is REQUIRED.</t> <bcp14>REQUIRED</bcp14>.</t>
        <t>The term "support" here means that the group MUST <bcp14>MUST</bcp14> be implemented.</t>
      </section>
      <section title="Message Processing" anchor="secMessageProc"> 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"/> target="RFC9048" format="default"/> or <xref target="RFC4187"/> target="RFC4187" format="default"/> apply.</t>
        <section title="EAP-Request/AKA'-Identity">
      <t>No changes, 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
      MUST NOT <bcp14>MUST
          NOT</bcp14> be added to this message.  The appearance of these
          attributes in a received message MUST <bcp14>MUST</bcp14> be ignored.</t>
        </section>
        <section title="EAP-Response/AKA'-Identity">

      <t>No changes, 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
      MUST NOT <bcp14>MUST
          NOT</bcp14> be added to this message. The appearance of these
          attributes in a received message
      MUST <bcp14>MUST</bcp14> be ignored. The peer
          Peer identifier SHALL <bcp14>SHALL</bcp14> comply with the
          privacy-friendly requirements of <xref target="RFC9190"/>. target="RFC9190"
          format="default"/>.  An example of a compliant way of constructing a
          privacy-friendly peer Peer identifier is using a non-NULL non-null SUCI <xref target="TS.33.501"/>.
          target="TS.33.501" format="default"/>.
          </t>
        </section>
        <section anchor="procakachall" title="EAP-Request/AKA'-Challenge"> numbered="true" toc="default">
          <name>EAP-Request/AKA'-Challenge</name>
          <t>The server Server sends the EAP-Request/AKA'-Challenge on full
          authentication as specified by <xref target="RFC4187"/> target="RFC4187"
          format="default"/> and <xref target="RFC9048"/>. target="RFC9048" format="default"/>.
          The attributes AT_RAND, AT_AUTN, and AT_MAC MUST <bcp14>MUST</bcp14> be
          included and checked on reception as specified in <xref target="RFC4187"/>.
          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 MUST <bcp14>MUST</bcp14> be included. The
          AT_PUB_ECDHE attribute carries the server's Server's public Diffie-Hellman
          key. If either AT_KDF_FS or AT_PUB_ECDHE is missing on reception,
          the peer
      MUST Peer <bcp14>MUST</bcp14> treat it as if neither one was sent, sent
          and the assume that the extension defined in this document is not in
          use.</t>
          <t>The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING,
          AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID AT_NEXT_REAUTH_ID, and other attributes may be
          included as specified in Section 9.3 of <xref
      target="RFC4187"/>.</t> target="RFC4187" sectionFormat="of"
          section="9.3"/>.</t>

          <t>When processing this message, the peer MUST Peer <bcp14>MUST</bcp14>
          process AT_RAND, AT_AUTN, AT_KDF_FS, and AT_PUB_ECDHE before
          processing other attributes.
      Only The Peer derives keys and verifies
          AT_MAC only if these attributes are verified to be valid, the peer
      derives keys and verifies AT_MAC. valid.  If the peer
          Peer is unable or unwilling to perform the extension specified in
          this document, it proceeds as defined in <xref target="RFC9048"/>. target="RFC9048"
          format="default"/>. Finally, if there is an error error, see Section 6.3.1. of <xref target="RFC4187"/>.</t>
          target="RFC4187" sectionFormat="of" section="6.3.1"/>.</t>
        </section>
        <section anchor="procakachallresp" title="EAP-Response/AKA'-Challenge"> numbered="true" toc="default">
          <name>EAP-Response/AKA'-Challenge</name>
          <t>The peer Peer sends an EAP-Response/AKA'-Challenge in response to a
      valid EAP-Request/AKA'-Challenge message, as specified by <xref
      target="RFC4187"/> target="RFC4187" format="default"/> and <xref target="RFC9048"/>. target="RFC9048" format="default"/>.
      If the peer Peer supports and is willing to perform the extension
      specified in this protocol, and the server Server had made a valid
      request involving the attributes specified in <xref
      target="procakachall"/>, target="procakachall" format="default"/>, the peer Peer responds per the rules
      specified below. Otherwise, the peer Peer responds as specified in
      <xref target="RFC4187"/> target="RFC4187" format="default"/> and <xref
      target="RFC9048"/> target="RFC9048" format="default"/> and ignores the attributes
      related to this extension. If the peer 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 had been were incorrect and fails the authentication.</t>
          <t>The AT_MAC attribute MUST <bcp14>MUST</bcp14> be included and checked as
      specified in <xref target="RFC9048"/>. 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 MUST <bcp14>MUST</bcp14> be included, included
      and carries the peer's Peer's public Diffie-Hellman key.</t>
          <t>The AT_RES attribute MUST <bcp14>MUST</bcp14> be included and checked as
      specified in <xref target="RFC4187"/>. target="RFC4187" format="default"/>.  When processing this
      message, the Server MUST <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 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 MUST <bcp14>MUST</bcp14> behave as if authentication failed.</t>
          <t>The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA AT_ENCR_DATA, and other
      attributes may be included as specified in Section 9.4 of <xref target="RFC4187"/>.</t> target="RFC4187" sectionFormat="of" section="9.4"/>.</t>
        </section>

        <section anchor="reauth" title="EAP-Request/AKA'-Reauthentication">
      <t>No changes, 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,
      which employs key material from the Diffie-Hellman procedure if the extension specified in this document is in use,
      employs key material from the Diffie-Hellman procedure.</t> use.</t>
        </section>

        <section title="EAP-Response/AKA'-Reauthentication">
      <t>No changes, 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"/>, 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 title="EAP-Response/AKA'-Synchronization-Failure">
      <t>No changes, 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 MUST NOT <bcp14>MUST NOT</bcp14> be added to this
          message.  The appearance of these attributes in a received message MUST
          <bcp14>MUST</bcp14> be ignored.</t>
        </section>

        <section title="EAP-Response/AKA'-Authentication-Reject">
      <t>No changes, 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 MUST NOT <bcp14>MUST NOT</bcp14> be added to this
          message.  The appearance of these attributes in a received message MUST
          <bcp14>MUST</bcp14> be ignored.</t>
        </section>

        <section title="EAP-Response/AKA'-Client-Error">
      <t>No numbered="true" toc="default">
          <name>EAP-Response/AKA'-Client-Error</name>
          <t> changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT
          <bcp14>MUST NOT</bcp14> be added to this message.  The appearance of
          these attributes in a received message MUST <bcp14>MUST</bcp14> be
          ignored.</t>
        </section>
        <section title="EAP-Request/AKA'-Notification">
      <t>No changes.</t> numbered="true" toc="default">
          <name>EAP-Request/AKA'-Notification</name>
          <t>There are no changes for the EAP-Request/AKA'-Notification.</t>
        </section>
        <section title="EAP-Response/AKA'-Notification">
      <t>No changes.</t> numbered="true" toc="default">
          <name>EAP-Response/AKA'-Notification</name>
          <t>There are no changes for the EAP-Request/AKA'-Notification.</t>
        </section>
      </section>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>

      <t>This section deals only with the changes to security considerations
    as they differ from EAP-AKA', for
      EAP-AKA' or as new information that has been gathered since the publication
      of <xref target="RFC9048"/>.</t> target="RFC9048" format="default"/>.</t>
      <t>As discussed in <xref target="sec:intro"/>,
    forward secrecy target="sec_intro" format="default"/>, FS is an important countermeasure against adversaries who gain
      access to the 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, occurred and that
      we need to minimize the impact of these breaches (see <xref target="NSA-ZT"/> target="NSA-ZT"
      format="default"/> and <xref target="NIST-ZT"/>. 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 (such as (5G-AKA, 5G-AKA or
      EAP-AKA') is used used, the effects of key compromise are devastating.  There
      are serious consequences of to not properly providing forward secrecy FS for
      the key establishment. For both establishment, for the control plane and the user plane, and for
      both directions:
     <list style="numbers">
      </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 UE User Equipment (UE) or the
    Network
    network and inject messages in an ongoing 5G connection between
    the real UE and the real network.</t>
    </list>
    </t>

   <t>Best
        </li>
      </ol>
      <t>At the time of writing, best practice security today is to mandate forward secrecy FS (as is
      done in WPA3, Wi-Fi Protected Access 3 (WPA3), EAP-TLS 1.3, EAP-TTLS 1.3, IKEv2, SSH,
      Internet Key Exchange Protocol Version 2 (IKEv2), Secure Shell (SSH),
      QUIC, WireGuard, Signal, etc.). It In deployments, it is recommended that in deployments,
      EAP-AKA methods without forward secrecy FS be phased out in the long
      term.</t>

    <t>This

      <t>The FS extension provide 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 large-scale pervasive
      monitoring as they require much less 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 on-path during the AKA run and subsequent
      communication between the parties. Without forward secrecy FS, an active attacker that
      has compromised the long-term key can inject messages in an a connection
      between the real Peer and the real server Server without being on path. on-path. This
      extension is most useful when used implemented in a context where the MSK/EMSK MSK or
      EMSK are used in protocols not providing forward secrecy. FS. For instance, if used with
      IKEv2 <xref target="RFC7296"/>, target="RFC7296" format="default"/>, the session keys
      produced by IKEv2 will in any case have this property, so better
    characteristics of the MSK and EMSK is
      improvements from the use of EAP-AKA' FS are not that useful. However,
      typical
    link layer link-layer usage of EAP does not involve running another, forward secure, another key exchange. 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>This
      <t>The FS extension generates keying 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 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 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 with access to the long-term key 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 forward secrecy. Forward secrecy 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 &lt; 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"/>, forward secrecy 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 title="Deployment Considerations"> numbered="true" toc="default">
        <name>Deployment Considerations</name>
        <t>Achieving FS requires that that, when a connection is closed, each
    endpoint MUST <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 which, in turn 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 title="Security Properties"> numbered="true" toc="default">
        <name>Security Properties</name>
        <t>The following security properties of
    EAP-AKA' are impacted through this extension:

    <list style="hanging">

      <t hangText="Protected extension:</t>

        <dl newline="true" spacing="normal">
          <dt>Protected ciphersuite negotiation"><vspace blankLines="1"/>

      EAP-AKA' negotiation:</dt>
          <dd>
            <t>EAP-AKA' has a negotiation mechanism for selecting the key
      derivation functions, 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.
      <vspace blankLines="1"/>

      There bidding-down attacks.</t>
            <t>There are two specific needs in the negotiation mechanism:
      <list style="hanging">

        <t hangText="Negotiating key derivation function mechanism:</t>
            <dl newline="true" spacing="normal">
              <dt>Negotiating KDFs within the extension"><vspace blankLines="1"/> extension:</dt>
              <dd>
        The negotiation mechanism allows changing the offered key
        derivation function, KDF, but the change is visible in the final EAP-
        Request/AKA'-Challenge
        EAP-Request/AKA'-Challenge message that the server Server sends to the peer. Peer.
        This message is authenticated via the AT_MAC attribute, and carries
        both the chosen alternative and the initially offered list.  The peer Peer
        refuses to accept a change it did not initiate.  As a result, both
        parties are aware that a change is being made and what the original
        offer was.</t>

        <t hangText="Negotiating was.</dd>
              <dt>Negotiating the use of this extension"><vspace
        blankLines="1"/> extension:</dt>
              <dd>
                <t> This extension is offered by the server Server through presenting
                the AT_KDF_FS and AT_PUB_ECDHE attributes in the
                EAP-Request/AKA'-Challenge message. These attributes are
                protected by AT_MAC, so attempts to change or omit them by an
                adversary will be detected.<vspace blankLines="1"/>

	Except 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. Such  For instance, such an attack can, for instance, can forge the negotiation
		process so that no FS will be provided. However, as noted
		above, an attacker with these capabilities will will, in any case 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,
		Introduction, even an attacker with access to the long-term
		keys is required to be on path on-path on each AKA run and subsequent
		communication, which makes mass surveillance more laborious.
	<vspace blankLines="1"/>
                </t>
                <t>
		  The security properties of the extension also depend on a
		  policy choice. As discussed in <xref
	target="procakachallresp"/>,
		  target="procakachallresp" format="default"/>, both the peer Peer
		  and the server Server make a policy decision of what to do when it
		  was willing to perform the extension specified in this
		  protocol, but the other side does not wish to use the
		  extension. Allowing this has the benefit of allowing
		  backwards compatibility to equipment that did not yet
		  support the extension. When the extension is not supported
		  or negotiated by the parties, no FS can obviously be
		  provided.
	<vspace blankLines="1"/>
                </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, widespread or required in a particular version
		  of a mobile network.</t>

      </list></t>

      <t hangText="Key derivation"><vspace blankLines="1"/>

      This network.
		</t>
              </dd>
            </dl>
          </dd>
          <dt>Key derivation:</dt>
          <dd>This extension provides forward secrecy. FS.  As described in several places in
          this specification, this can be roughly summarized as
      that 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, and hence keys;
          hence, they continue to be equally safe against expose exposure of the
          long-term key as the original authentication.</t>

  </list></t> authentication.</dd>
        </dl>
      </section>
      <section title="Denial-of-Service">

  <t>In addition, it 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 Peer or the server. Server. While some forms of Denial-of-Service DoS
        attacks are always possible, the following factors help mitigate the
        concerns relating to public key cryptography and EAP-AKA' FS.

  <list style="symbols">

        </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 is possible. 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 takes 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. When For instance, when processing the EAP-Request/AKA'-Challenge
    message, for instance, the AKA authentication must be checked and
    succeed before the peer Peer proceeds to calculating or processing the
    FS related
    FS-related parameters (see <xref
    target="procakachallresp"/>). target="procakachallresp" format="default"/>). The same is true of an
    EAP-Response/AKA'-Challenge (see <xref
    target="procakachallresp"/>). 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
    Denial-of-Service
    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 (a) limited are:</t>
<ol type="a"><li>limited in terms of subscribers they control, and
    (b) identifiable and</li>
<li>identifiable for the purposes of blocking the affected
    subscribers.</t>

  </list></t>
    subscribers.</li></ol>
          </li>
        </ul>
      </section>
      <section title="Identity Privacy"> numbered="true" toc="default">
        <name>Identity Privacy</name>
        <t>As specified in <xref target="secMessageProc"/>, target="secMessageProc" format="default"/>, the peer Peer identity sent
       in the Identity Response message needs
       to follow the privacy-friendly requirements in <xref target="RFC9190"/>.</t> target="RFC9190" format="default"/>.</t>
      </section>
      <section anchor="unp" title="Unprotected numbered="true" toc="default">
        <name>Unprotected Data and Privacy"> 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, algorithms; if these depend on the
   peer identity
   Peer identity, they leak information about the peer. 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 title="Forward numbered="true" toc="default">
        <name>Forward Secrecy within AT_ENCR">

     <t>They 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 data in the
        EAP-Req/AKA'-Challenge message, especially the DH g^x g<sup>x</sup>
        ephemeral pub key. At that point point, the server Server does not yet have the
        corresponding g^y g<sup>y</sup> from the peer Peer and cannot compute the
        shared secret. K_aut is then used as the authentication key for the
        shared secret.</t>

     <t>For K_encr though,

        <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 protocol runs when pseudonyms are used, within a
        sequence of runs followed after a full EAP-AKA' authentication. No
        such linking would be possible across different full authentaction authentication
        runs. If the pseudonum pseudonym linkage risk is not acceptable, one way to
        avoid the linkage is to always require full EAP-AKA'
        authentication.</t>
      </section>
      <section title="Post-Quantum Considerations"> 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
   elliptic curve cryptography ECC will exist.  Deployments that need to consider
        risks decades into the future should transition to Post-
   Quantum Post-Quantum Cryptography (PQC) in the not-too-distant future.  Other systems may
        employ PQC when the quantum threat is more imminent. Current PQC
        algorithms have limitations compared to Elliptic Curve Cryptography
   (ECC) ECC, and the data sizes could be problematic for some constrained
        systems. If a Cryptographically Relevant Quantum Computer (CRQC) is built
        built, it could recover the SHARED_SECRET from the ECDHE public
        keys.</t>

   <t>This

        <t>However, this would not affect the ability of EAP-AKA' - EAP-AKA', with or
        without this extension - extension, to authenticate properly, however. 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 key, which is
        based on MK and, ultimately, CK' 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 also the CK' and IK' 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', and 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 security 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 FS, such as HMAC-SHA-256 and
        the algorithms use used to generate AT_AUTN and AT_RES AT_RES, are practically
        secure against even large large, robust quantum computers. EAP-AKA' FS is
        currently only specified for use with ECDHE key exchange algorithms,
        but use of any Key Encapsulation Method (KEM), including Post-Quantum Cryptography
   (PQC) 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 Server or the SHARED_SECRET encapsulated with the server's
        Server's public key. Note that the use of a KEM might require other changes
        changes, such as including the ephemeral public key of the server Server in
        the key derivation to retain the property that both parties contribute
        randomness to the session key.
        </t>
      </section>
    </section>
    <section title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This extension of EAP-AKA' shares its attribute space and subtypes
      with
  Extensible the following:</t>
      <ul>
	<li>"Extensible Authentication Protocol Method for Global System for
      Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) (EAP-SIM)" <xref target="RFC4186"/>, EAP-AKA
      target="RFC4186" format="default"/>,</li>
      <li>"Extensible Authentication Protocol
      Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)"
      <xref target="RFC4187"/>, target="RFC4187" format="default"/>, and</li>
      <li>"Improved Extensible
      Authentication Protocol Method for 3GPP Mobile Network Authentication
      and
  EAP-AKA' Key Agreement (EAP-AKA')" <xref target="RFC9048"/>.</t>

  <t>Two target="RFC9048"
      format="default"/>.</li></ul>

  <t>IANA has assigned two new values (TBA1, TBA2) in the skippable
  range need to be assigned for AT_PUB_ECDHE (<xref target="at_pub_dh"/>)
  and AT_KDF_FS (<xref target="at_kdf_dh"/>) in the "Attribute Types" Types (Skippable
  Attributes 128-255)" registry under the "EAP-AKA and EAP-SIM Parameters" group.</t>

  <t>Also, IANA is requested to create a new registry
  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 Key Derivation Function 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"/>) need to be target="kdf2" format="default"/>) have been assigned, along with one reserved value. The initial contents of
      this registry is are illustrated in <xref target="iana-fs-values"/>; target="iana-fs-values"
      format="default"/>; new values can be created through the Specification
      Required policy <xref target="RFC8126"/>. target="RFC8126" format="default"/>.  Expert
      reviewers should ensure that the referenced specification is clearly
      identified and stable, stable and that the proposed addition is reasonable for
      the given category of allocation.
      </t>
      <table anchor="iana-fs-values">
          <name>Initial Content of the EAP-AKA'
        <name>EAP-AKA' AT_KDF_FS Key Derivation Function Values Registry</name> 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">[TBD BY IANA: THIS RFC]</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">[TBD BY IANA: THIS RFC]</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">[TBD BY IANA: THIS RFC]</td> align="left">RFC 9678</td>
          </tr>
          <tr>
            <td align="left">3-65535</td>
            <td align="left">Unassigned</td>
            <td align="left">[TBD BY IANA: THIS RFC]</td> align="left">RFC 9678</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>

<references title="Normative References">
      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.3748.xml"?>
      <?rfc include="reference.RFC.4187.xml"?>
      <?rfc include="reference.RFC.5448.xml"?>
      <?rfc include="reference.RFC.7624.xml"?>
      <?rfc include="reference.RFC.7748.xml"?>
      <?rfc include="reference.RFC.8126.xml"?>
      <?rfc include="reference.RFC.8174.xml"?>
      <?rfc include="reference.RFC.9048.xml"?>
    <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"> 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>
          <organization>NIST</organization>
            <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'/> year="2023"/>
          </front>
          <seriesInfo name="NIST" value="Special Publication value="SP 800-186"/>
        <format type='HTML' target='https://doi.org/10.6028/NIST.SP.800-186'/>
	  <seriesInfo name="DOI" value="10.6028/NIST.SP.800-186"/>
        </reference>

        <reference anchor="SEC1"> anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf">
          <front>
            <title>SEC 1: Elliptic Curve Cryptography</title>
            <author>
          <organization>Certicom Research</organization>
              <organization>Standards for Efficient Cryptography</organization>
            </author>
            <date month="May" year='2009'/> year="2009"/>
          </front>
        <seriesInfo name="Standards for Efficient Cryptography 1 (SEC 1)" value="Version 2.0" />
        <format type='HTML' target='https://www.secg.org/sec1-v2.pdf'/>
	  <refcontent>Version 2.0</refcontent>
        </reference>

        <reference anchor="SEC2"> anchor="SEC2" target="https://www.secg.org/sec2-v2.pdf">
          <front>
            <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
            <author>
          <organization>Certicom Research</organization>
              <organization>Standards for Efficient Cryptography</organization>
            </author>
            <date month="January" year='2010'/> year="2010"/>
          </front>
        <seriesInfo name="Standards for Efficient Cryptography 2 (SEC 2)" value="Version 2.0" />
        <format type='HTML' target='https://www.secg.org/sec2-v2.pdf'/>
	  <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></organization>
              <organization>National Institute of Standards and Technology</organization>
            </author>
            <author initials="L." surname="Chen">
      <organization></organization>
              <organization/>
            </author>
            <author initials="A." surname="Roginsky">
      <organization></organization>
              <organization/>
            </author>
            <author initials="A." surname="Vassilev">
      <organization></organization>
              <organization/>
            </author>
            <author initials="R." surname="Davis">
      <organization></organization>
              <organization/>
            </author>
            <date year="2018" month="April"/>
          </front>
          <seriesInfo name="NIST" value="Special Publication 800-56A Revision 3"/> value="SP 800-56A"/>
	  <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
        </reference>

      </references>

<references title="Informative References">
  <?rfc include="reference.RFC.4186.xml"?>
  <?rfc include="reference.RFC.5216.xml"?>
  <?rfc include="reference.RFC.7258.xml"?>
  <?rfc include="reference.RFC.7296.xml"?>
  <?rfc include="reference.RFC.9190.xml"?>

      <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"> anchor="TrustCom2015" target="https://doi.org/10.1109/Trustcom.2015.506">
          <front>
            <title>A USIM compatible Compatible 5G AKA protocol Protocol with perfect forward secrecy</title> Perfect Forward Secrecy</title>
            <author initials="J." surname="Arkko"></author> surname="Arkko"/>
            <author initials="K." surname="Norrman"></author> surname="Norrman"/>
            <author initials="M." surname="Näslund"></author> surname="Näslund"/>
            <author initials="B." surname="Sahlin"></author> surname="Sahlin"/>
            <date month='August' year='2015'/> month="August" year="2015"/>
          </front>
    <seriesInfo name="Proceedings of IEEE
          <refcontent>IEEE International Conference on Trust, Security and
	  Privacy in Computing and Communications (TrustCom)" value="2015" />
    <format type='HTML' target='https://doi.org/10.1109/Trustcom.2015.506'/> (TrustCom)</refcontent>
	  <seriesInfo name="DOI" value="10.1109/Trustcom.2015.506"/>
        </reference>

        <reference anchor="Heist2015"> 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> surname="Scahill"/>
            <author initials="J." surname="Begley"></author> surname="Begley"/>
            <date month="February" year="2015"/>
          </front>
    <format type='HTML' target='https://theintercept.com/2015/02/19/great-sim-heist/'/>
        </reference>

        <reference anchor="DOW1992"> anchor="DOW1992" target="https://doi.org/10.1007/BF00124891">
          <front>
            <title>Authentication and Authenticated Key Exchanges</title> authenticated key exchanges</title>
            <author initials="W." surname="Diffie"></author> surname="Diffie"/>
            <author initials="P." initials="P. C." surname="Van Oorschot"></author> Oorschot"/>
            <author initials="M." surname="Wiener"></author> initials="M. J." surname="Wiener"/>
            <date month="June" year="1992"/>
          </front>
    <seriesInfo name="Designs,
          <refcontent>Designs, Codes and Cryptography 2" value="pp. 107-125" />
    <format type='HTML' target='https://doi.org/10.1007/BF00124891'/> 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="March" year="2023" /> year="2023"/>
          </front>
          <seriesInfo name="3GPP TS" value="33.501 18.1.0" /> value="33.501"/>
	  <refcontent>Version 18.1.0</refcontent>
        </reference>

        <reference anchor="NIST-ZT" target="https://www.nccoe.nist.gov/sites/default/files/2022-12/zta-nist-sp-1800-35b-preliminary-draft-2.pdf"> 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 initials="" surname="National
            <author>
              <organization>National Institute of Standards and Technology">
              <organization/> Technology</organization>
            </author>
            <date year="2022" month="December"/> 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 initials="" surname="National
            <author>
	      <organization>National Security Agency">
              <organization/> Agency</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
        </reference>

      </references>
    </references>

    <section title="Change Log">

  <t>RFC Editor: Please remove this appendix.</t>

  <t>The -12 version of the WG draft has the following changes, most
  due to IESG review comments in January 2023:

  <list style="symbols">

    <t>Update the draft track to Standards Track.</t>

    <t>Clarified the calculation of the Length field in the AT_ECDHE
    attribute, along with padding requirements.</t>

    <t>Avoided the use of keywords in operational recommendations,
    e.g., about deployment.</t>

    <t>Changed the definition of what "supported" means to focus on feature being implemented, but not require that it is usable during a protocol run, because configuration, new security information, etc. might imply that a particular feature is implemented but disabled for policy reasons.</t>

    <t>Changed the MITM terminology to be on-path attacks.</t>

    <t>Corrected a reference typo in the IANA considerations
    section.</t>

    <t>Shortened the abstract and introduction to the key aspects and removed duplication.</t>

    <t>Several editorial changes.</t>

  </list></t>

  <t>The -11 version of the WG draft has the following changes:
  <list style="symbols">

    <t>Addressed IETF Last Call comments from directorates, Security AD, Meiling Cheng, and a detailed review from the author Karl. In particular:</t>

    <t>Replaced the reference to the deprecated FIPS 186-4 with SP 800-186.</t>

    <t>Changed HSS (Home Subscriber Server) to Authentication Database (AD) as HSS is a 4G term.</t>

    <t>Explained difference between EAP-AKA and EAP-AKA'</t>

    <t>Explained that the emphemeral key exhange provide more that forward secrecy and how this is important to mitigate pervasive monitoring.</t>

    <t>Included links for the zero trust principles.</t>

    <t>Explained why K_encr and K_auth not being protected by the ECDHE addition.</t>

    <t>Added that a future introduction of KEM might require additional changes.</t>

    <t>Explained how ephemeral key exchange is linked to pervasive monitoring.</t>

    <t>Changed SIM to USIM everywhere. A USIM is required for AKA.</t>

    <t>Changed to long-term key instead of long-term secret or long-term shared secret.</t>

    <t>Reference updates.</t>

    <t>Various editorial improvements.</t>

  </list></t>

  <t>The -10 version of the WG draft has the following changes:
  <list style="symbols">

    <t>Various nits found by Peter Yee.</t>

  </list></t>

  <t>The -09 version of the WG draft has the following changes:
  <list style="symbols">

    <t>Scalable Vector Graphics (SVG) versions for all figures has been added
    and the figures has been slightly modified to render nicely with aasvg.</t>

    <t>A reference has been added to the Section in SEC1 describing how
    to do decompression.</t>

    <t>The strengthened identity protection requirements are now mentioned in the
    introduction.</t>

    <t>Corrections and clarifications were made in the IANA considerations. The
    table in the IANA section has been made into a proper xml table.</t>

    <t>Reference updates.</t>

    <t>Various editorial improvements.</t>

  </list></t>

  <t>The -08 version of the WG draft has the following changes:
  <list style="symbols">

    <t>Further clarification of key calculation in <xref
    target="kdf2"/>.</t>

    <t>Support for the NIST  P-256 group has been made mandatory in
    <xref target="groups"/>, in
    order to align the requirements with 3GPP SUCI encryption
    requirements.</t>

    <t>The interaction between AT_KDF and AT_KDF_FS has been specified more
    clearly, including specifying how future specifications need to specify
    the treatment of new combinations.</t>

    <t>Addition of a discussion about the impacts of potential future quantum
    computing attacks with specific impacts to this extension.</t>

    <t>Addition of a discussion about metadata/unprotected data in
    <xref target="unp"/>.</t>

    <t>Reference updates.</t>

    <t>Various editorial improvements.</t>

  </list></t>

  <t>The -07 version of the WG draft has the following changes:
  <list style="symbols">

    <t>The impact of forward secrecy explanation has been improved in
    the abstract and security considerations.</t>

    <t>The draft now more forcefully explains why the authors believe
    it is important to migrate existing systems to use forward
    secrecy, and makes a recommendation for this migration.</t>

    <t>The draft does no longer refer to issues within the smart cards but
    rather the smart card supply chain.</t>

    <t>The rationale for chosen algorithms is explained.</t>

    <t>Also, the authors have checked the language relating to the
    public value encoding, and believe it is exactly according to the
    references (<xref target="RFC7748"/> Section 6.1 and <xref
    target="SEC2"/> Section 2.7.1)</t>

    </list></t>

  <t>The -06 version of the WG draft is a refresh and a
  reference update. However, the
  following should be noted:

  <list style="symbols">

    <t>The draft now uses "forward secrecy" terminology and references
    RFC 7624 per recommendations on mailing list discussion.</t>

    <t>There's been mailing list discussion about the encoding of the
    public values; the current text requires confirmation from the
    working group that it is sufficient.</t>

  </list>
  </t>

  <t>The -05 version of the WG draft takes into account feedback from
  the working group list, about the number of bytes needed to encode
  P-256  values.</t>

  <t>The -04 version of the WG draft takes into account feedback from
  the May 2020 WG interim meeting, correcting the reference to the
  NIST P-256 specification.</t>

  <t>The -03 version of the WG draft is first of all a refresh; there
  are no issues that we think need addressing, beyond the one for
  which there is a suggestion in -03: The document now suggests
  an alternate group/curve as an optional one besides X25519. The
  specific choice of particular groups and algorithms is still up to the
  working group.</t>

  <t>The -02 version of the WG draft took into account additional
  reviews, and changed the document to update RFC 5448 (or rather, its
  successor, <xref target="RFC9048"/>), changed the
  wording of the recommendation with regards to the use of this
  extension, clarified the references to the definition of X25519 and
  Curve25519, clarified the distinction to ECDH methods that use
  partially static keys, and simplified the use of AKA and USIM card
  terminology. Some editorial changes were also made.</t>

  <t>The -00 and -01 versions of the WG draft made no major
  changes, only updates to some references.</t>

  <t>The -05 version is merely a refresh while the draft was waiting
  for WG adoption.</t>

  <t>The -04 version of this draft made only editorial changes.</t>

    <t>The -03 version of this draft changed the naming of various
    protocol components, values, and notation to match with the use of
    ECDH in ephemeral mode. The AT_KDF_FS negotiation process was
    clarified in that exactly one key is ever sent in
    AT_KDF_ECDHE. The option of checking for zero key values IN ECDHE
    was added. The format of the actual key in AT_PUB_ECDHE was
    specified. Denial-of-service considerations for the FS process
    have been updated. Bidding down attacks against this extension
    itself are discussed extensively. This version also addressed
    comments from reviewers, including the August review from Mohit
    Sethi, and comments made during IETF-102 discussion.</t>

  </section>

  <section numbered="no" title="Acknowledgments"> 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"/>, 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
    uses also uses a lot of
      material from <xref target="RFC4187"/> target="RFC4187" format="default"/> by <contact
      fullname="J. Arkko"/> and <contact fullname="H. Haverinen"/> Haverinen"/>, as well as
      <xref target="RFC5448"/> 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 GSMA, and 3GPP groups for interesting discussions in this problem
      space.</t>
    </section>
  </back>

</rfc>