<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" ipr="trust200902" docName="draft-ietf-emu-aka-pfs-12" number="9678" category="std" updates="5448,9048" consensus="true" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" prepTime="2025-03-04T15:24:22" indexInclude="true" scripts="Common,Latin" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-emu-aka-pfs-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9678" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="EAP-AKA' FS">Forward Secrecy Extension to the Improved Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)</title>
    <seriesInfo name="RFC" value="9678" stream="IETF"/>
    <author initials="J." surname="Arkko" fullname="Jari Arkko">
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <postal>
          <city>Jorvas</city>
          <code>02420</code>
          <country>Finland</country>
        </postal>
        <email>jari.arkko@piuha.net</email>
      </address>
    </author>
    <author initials="K." surname="Norrman" fullname="Karl Norrman">
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <postal>
          <city>Stockholm</city>
          <code>16483</code>
          <country>Sweden</country>
        </postal>
        <email>karl.norrman@ericsson.com</email>
      </address>
    </author>
    <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
      <organization showOnFrontPage="true">Ericsson</organization>
      <address>
        <postal>
          <city>Kista</city>
          <code>164 40</code>
          <country>Sweden</country>
        </postal>
        <email>john.mattsson@ericsson.com</email>
      </address>
    </author>
    <date month="03" year="2025"/>
    <area>SEC</area>
    <workgroup>emu</workgroup>
    <keyword>EAP</keyword>
    <keyword>AKA</keyword>
    <keyword>AKA'</keyword>
    <keyword>EAP-AKA'</keyword>
    <keyword>EAP-AKA' FS</keyword>
    <keyword>3GPP</keyword>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document updates RFC 9048, "Improved Extensible Authentication
      Protocol Method for 3GPP Mobile Network Authentication and Key Agreement
      (EAP-AKA')", and its predecessor RFC 5448 with an optional extension
      providing ephemeral key exchange. The extension EAP-AKA' Forward Secrecy
      (EAP-AKA' FS), when negotiated, provides forward secrecy for the session
      keys generated as a part of the authentication run in EAP-AKA'. This
      prevents an attacker who has gained access to the long-term key from
      obtaining session keys established in the past. In addition, EAP-AKA' FS mitigates passive attacks
      (e.g., large-scale pervasive monitoring) against future sessions. This
      forces attackers to use active attacks instead.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9678" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2025 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-requirements-language">Requirements Language</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-design-and-deploym">Protocol Design and Deployment Objectives</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-background">Background</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-aka">AKA</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-aka-protocol">EAP-AKA' Protocol</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-attacks-against-long-term-k">Attacks Against Long-Term Keys in Smart Cards</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-overview">Protocol Overview</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-extensions-to-eap-aka">Extensions to EAP-AKA'</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-at_pub_ecdhe">AT_PUB_ECDHE</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-at_kdf_fs">AT_KDF_FS</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t indent="0" pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-forward-secrecy-key-derivat">Forward Secrecy Key Derivation Functions</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t indent="0" pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ecdhe-groups">ECDHE Groups</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t indent="0" pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-message-processing">Message Processing</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.5.2">
                  <li pn="section-toc.1-1.6.2.5.2.1">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.1.1"><xref derivedContent="6.5.1" format="counter" sectionFormat="of" target="section-6.5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-request-aka-identity">EAP-Request/AKA'-Identity</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.2">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.2.1"><xref derivedContent="6.5.2" format="counter" sectionFormat="of" target="section-6.5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-response-aka-identity">EAP-Response/AKA'-Identity</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.3">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.3.1"><xref derivedContent="6.5.3" format="counter" sectionFormat="of" target="section-6.5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-request-aka-challenge">EAP-Request/AKA'-Challenge</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.4">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.4.1"><xref derivedContent="6.5.4" format="counter" sectionFormat="of" target="section-6.5.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-response-aka-challenge">EAP-Response/AKA'-Challenge</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.5">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.5.1"><xref derivedContent="6.5.5" format="counter" sectionFormat="of" target="section-6.5.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-request-aka-reauthentic">EAP-Request/AKA'-Reauthentication</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.6">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.6.1"><xref derivedContent="6.5.6" format="counter" sectionFormat="of" target="section-6.5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-response-aka-reauthenti">EAP-Response/AKA'-Reauthentication</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.7">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.7.1"><xref derivedContent="6.5.7" format="counter" sectionFormat="of" target="section-6.5.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-response-aka-synchroniz">EAP-Response/AKA'-Synchronization-Failure</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.8">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.8.1"><xref derivedContent="6.5.8" format="counter" sectionFormat="of" target="section-6.5.8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-response-aka-authentica">EAP-Response/AKA'-Authentication-Reject</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.9">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.9.1"><xref derivedContent="6.5.9" format="counter" sectionFormat="of" target="section-6.5.9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-response-aka-client-err">EAP-Response/AKA'-Client-Error</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.10">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.10.1"><xref derivedContent="6.5.10" format="counter" sectionFormat="of" target="section-6.5.10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-request-aka-notificatio">EAP-Request/AKA'-Notification</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.5.2.11">
                    <t indent="0" pn="section-toc.1-1.6.2.5.2.11.1"><xref derivedContent="6.5.11" format="counter" sectionFormat="of" target="section-6.5.11"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-eap-response-aka-notificati">EAP-Response/AKA'-Notification</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-deployment-considerations">Deployment Considerations</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-properties">Security Properties</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.3">
                <t indent="0" pn="section-toc.1-1.7.2.3.1"><xref derivedContent="7.3" format="counter" sectionFormat="of" target="section-7.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-denial-of-service">Denial of Service</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.4">
                <t indent="0" pn="section-toc.1-1.7.2.4.1"><xref derivedContent="7.4" format="counter" sectionFormat="of" target="section-7.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-identity-privacy">Identity Privacy</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.5">
                <t indent="0" pn="section-toc.1-1.7.2.5.1"><xref derivedContent="7.5" format="counter" sectionFormat="of" target="section-7.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-unprotected-data-and-privac">Unprotected Data and Privacy</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.6">
                <t indent="0" pn="section-toc.1-1.7.2.6.1"><xref derivedContent="7.6" format="counter" sectionFormat="of" target="section-7.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-forward-secrecy-within-at_e">Forward Secrecy within AT_ENCR</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.7">
                <t indent="0" pn="section-toc.1-1.7.2.7.1"><xref derivedContent="7.7" format="counter" sectionFormat="of" target="section-7.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-post-quantum-considerations">Post-Quantum Considerations</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgments</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sec_intro" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">Many different attacks have been reported as part of the revelations
      associated with pervasive surveillance. Some of the reported attacks
      involved compromising the Universal Subscriber Identity Module (USIM)
      card supply chain. Attacks revealing the AKA long-term key may occur,
      for instance:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-1-2">
        <li pn="section-1-2.1">during the manufacturing process of USIM cards,</li>
        <li pn="section-1-2.2">during the transfer of the cards and associated information to
	the operator, and</li>
        <li pn="section-1-2.3">when the system is running.</li>
      </ul>
      <t indent="0" pn="section-1-3">Since the publication of reports about such attacks (see <xref target="Heist2015" format="default" sectionFormat="of" derivedContent="Heist2015"/>), manufacturing and provisioning
      processes have gained much scrutiny and have improved.</t>
      <t indent="0" pn="section-1-4">However, the danger of resourceful attackers attempting to gain
      information about long-term keys is still a concern because these keys
      are high-value targets.  Note that the attacks are largely independent
      of the used authentication technology; the issue is not vulnerabilities
      in algorithms or protocols, but rather the possibility of someone
      gaining unauthorized access to key material. Furthermore, an explicit
      goal of the IETF is to ensure that we understand the surveillance
      concerns related to IETF protocols and take appropriate countermeasures
      <xref target="RFC7258" format="default" sectionFormat="of" derivedContent="RFC7258"/>.</t>
      <t indent="0" pn="section-1-5">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 indent="0" pn="section-1-6">This document updates <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>,
      "Improved Extensible Authentication Protocol Method for 3GPP Mobile
      Network Authentication and Key Agreement (EAP-AKA')", with an optional
      extension providing ephemeral key exchange, which minimizes the impact of
      long-term key compromise and strengthens the identity privacy
      requirements.  This is important, given the large number of users of AKA
      in mobile networks.</t>
      <t indent="0" pn="section-1-7">The extension, when
  negotiated, provides Forward Secrecy (FS) <xref target="DOW1992" format="default" sectionFormat="of" derivedContent="DOW1992"/> for the session key
  generated as a part of the authentication run in EAP-AKA'.  This
  prevents an attacker who has gained access to the long-term
  key in a USIM card from getting access to past session
  keys.	In addition to FS, the included Diffie-Hellman exchange forces
  attackers to be active if they want access to future session keys, even
  if they have access to the long-term key. This is beneficial because
  active attacks demand many more resources to launch and are easier to
  detect. As
  with other protocols, an active attacker with access to the
  long-term key material will, of course, be able to attack all future
  communications, but risks detection, particularly if done at
  scale.</t>
      <t indent="0" pn="section-1-8">It should also be noted that 5G network architecture <xref target="TS.33.501" format="default" sectionFormat="of" derivedContent="TS.33.501"/>
  includes the
  use of the EAP framework for authentication. While any methods can
  be run, the default authentication method within that context will
  be EAP-AKA'. As a result, improvements in EAP-AKA' security have the
  potential to improve security for many users.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-requirements-language">Requirements Language</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
      </t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-protocol-design-and-deploym">Protocol Design and Deployment Objectives</name>
      <t indent="0" pn="section-3-1">The extension specified here reuses large portions of the
  current structure of 3GPP interfaces and functions, with the
  rationale that this will make the construction more easily adopted.
  In particular, the construction keeps the interface between the
  USIM and the mobile
  terminal intact. As a consequence, there is no need to roll out new
  credentials to existing subscribers. The work is based on an earlier
  paper (see <xref target="TrustCom2015" format="default" sectionFormat="of" derivedContent="TrustCom2015"/>) and uses much of the same
  material but is applied to EAP rather than the underlying AKA
  method.</t>
      <t indent="0" pn="section-3-2">It has been a goal to implement this change as an extension
  of the widely supported EAP-AKA' method, rather than implement a completely new
  authentication method. The extension is implemented as a set of
  new, optional attributes that are provided alongside the
  base attributes in EAP-AKA'. Old implementations can ignore
  these attributes, but their presence will nevertheless be verified
  as part of the base EAP-AKA' integrity verification process, helping
  protect against bidding down attacks. This extension does
  not increase the number of rounds necessary to complete the
  protocol.</t>
      <t indent="0" pn="section-3-3">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 indent="0" pn="section-3-4">While adding FS to the existing mobile
  network infrastructure can be done in multiple different ways, this
  document specifies a solution that is relatively easy to deploy. In particular:
      </t>
      <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3-5">
        <li pn="section-3-5.1">As noted above, no new credentials are needed; there is no change
        to USIM cards.</li>
        <li pn="section-3-5.2">FS property can be incorporated into any current or future system
        that supports EAP, without changing any network functions beyond the
        EAP endpoints.</li>
        <li pn="section-3-5.3">Key generation happens at the endpoints, enabling the highest grade
        key material to be used both by the endpoints and the intermediate
        systems (such as access points that are given access to specific
        keys).</li>
        <li pn="section-3-5.4">While EAP-AKA' is just one EAP method, for practical purposes,
        FS being available for both EAP-TLS <xref target="RFC5216" format="default" sectionFormat="of" derivedContent="RFC5216"/> <xref target="RFC9190" format="default" sectionFormat="of" derivedContent="RFC9190"/> and EAP-AKA' ensures that, for many practical
        systems, FS can be enabled for either all or a significant
        fraction of users.</li>
      </ul>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-background">Background</name>
      <t indent="0" pn="section-4-1">The reader is assumed to
    have a basic understanding of the EAP framework <xref target="RFC3748" format="default" sectionFormat="of" derivedContent="RFC3748"/>.</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-aka">AKA</name>
        <t indent="0" pn="section-4.1-1">We use the term "Authentication and Key Agreement" (or "AKA") for the
    main authentication and key agreement protocol used by 3GPP mobile
    networks from the third generation (3G) and onward. Later
    generations add new features to AKA, but the core remains the
    same.  It is based on challenge-response mechanisms and symmetric
    cryptography.  In contrast to its earlier GSM counterparts, AKA
    provides long key lengths and mutual authentication.  The phone
    typically executes AKA in a USIM. A USIM is technically just an
    application that can reside on a removable Universal
    Integrated Circuit Card (UICC), an embedded UICC, or integrated in a
    Trusted Execution Environment (TEE). In this document, we use the
    term "USIM card" to refer to any Subscriber Identity Module (SIM)
    capable of running AKA.</t>
        <t indent="0" pn="section-4.1-2">The goals of AKA are to mutually authenticate the USIM and the
        so-called home environment, which is the authentication Server in the
        subscriber's home operator's network, and to establish key material
        between the two.</t>
        <t indent="0" pn="section-4.1-3">AKA works in the following manner:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.1-4">
          <li pn="section-4.1-4.1">The USIM and the home environment have agreed on a long-term
          symmetric key beforehand.</li>
          <li pn="section-4.1-4.2">The actual authentication process starts by having the home
          environment produce an authentication vector, based on the long-term
          key and a sequence number. The authentication vector contains a
          random part RAND, an authenticator part AUTN used for authenticating
          the network to the USIM, an expected result part XRES, a 128-bit
          session key for the integrity check IK, and a 128-bit session key for the
          encryption CK.</li>
          <li pn="section-4.1-4.3">The authentication vector is passed to the serving network,
          which uses it to authenticate the device.</li>
          <li pn="section-4.1-4.4">The RAND and the AUTN are delivered to the USIM.</li>
          <li pn="section-4.1-4.5">The USIM verifies the AUTN, again based on the long-term key and
          the sequence number.  If this process is successful (the AUTN is
          valid and the sequence number used to generate the AUTN is within the
          correct range), the USIM produces an authentication result RES and
          sends it to the serving network.</li>
          <li pn="section-4.1-4.6">The serving network verifies that the result from the USIM
          matches the expected value in the authentication vector.  If it
          does, the USIM is considered authenticated, and the IK and CK can be
          used to protect further communications between the USIM and the home
          environment.</li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-eap-aka-protocol">EAP-AKA' Protocol</name>
        <t indent="0" pn="section-4.2-1">When AKA is embedded into EAP, the authentication processing on
    the network side is moved to the home environment. The 3GPP Authentication
    Database (AD) generates authentication vectors. The 3GPP authentication
    Server takes the role of EAP Server. The USIM combined with
    the mobile phone takes the role of client.
    The difference between EAP-AKA <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/> and
    EAP-AKA' <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/> is that EAP-AKA' 
    binds the derived keys to the name of the access network.
    <xref target="figaka" format="default" sectionFormat="of" derivedContent="Figure 1"/> describes the basic flow in the EAP-AKA'
    authentication process. The definition of the full protocol
    behavior, along with the definition of the attributes AT_RAND,
    AT_AUTN, AT_MAC, and AT_RES can be found in <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/> and <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/>.
    Note the use of EAP terminology from hereon.  That is, the 3GPP
    serving network takes on the role of an EAP access network.
</t>
        <figure anchor="figaka" align="left" suppress-title="false" pn="figure-1">
          <name slugifiedName="name-eap-aka-authentication-proc">EAP-AKA' Authentication Process</name>
          <artset pn="section-4.2-2.1">
            <artwork type="ascii-art" name="" align="left" alt="" pn="section-4.2-2.1.1">
 Peer                                                        Server
   |                                                            |
   |                                       EAP-Request/Identity |
   |&lt;-----------------------------------------------------------+
   |                                                            |
   | EAP-Response/Identity                                      |
   | (Includes user's Network Access Identifier (NAI))          |
   +-----------------------------------------------------------&gt;|
   |    +-------------------------------------------------------+--+
   |    | The Server determines the network name and ensures that  |
   |    | the given access network is authorized to use the        |
   |    | claimed name.  The Server then runs the EAP-AKA'         |
   |    | algorithms generating RAND and AUTN, and derives session |
   |    | keys from CK' and IK'.  RAND and AUTN are sent as        |
   |    | AT_RAND and AT_AUTN attributes, whereas the network name |
   |    | is transported in the AT_KDF_INPUT attribute.  AT_KDF    |
   |    | signals the used key derivation function.  The session   |
   |    | keys are used to create the AT_MAC attribute.            |
   |    +-------------------------------------------------------+--+
   |                                                            |
   |                                 EAP-Request/AKA'-Challenge |
   |           (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) |
   |&lt;-----------------------------------------------------------+
+--+------------------------------------------------------+     |
| The Peer determines what the network name should be,    |     |
| based on, e.g., what access technology it is using.     |     |
| The Peer also retrieves the network name sent by the    |     |
| network from the AT_KDF_INPUT attribute.  The two names |     |
| are compared for discrepancies, and if they do not      |     |
| match, the authentication is aborted.  Otherwise, the   |     |
| network name from the AT_KDF_INPUT attribute is used    |     |
| in running the EAP-AKA' algorithms, verifying AUTN from |     |
| AT_AUTN and Message Authentication Code (MAC) from the  |     |
| AT_MAC attributes.  The Peer then generates RES.  The   |     |
| Peer also derives session keys from CK'/IK.  The AT_RES |     |
| and AT_MAC attributes are constructed.                  |     |
+--+------------------------------------------------------+     |
   |                                                            |
   | EAP-Response/AKA'-Challenge                                |
   | (AT_RES, AT_MAC)                                           |
   +-----------------------------------------------------------&gt;|
   |      +-----------------------------------------------------+--+
   |      | The Server checks the RES and MAC values received in   |
   |      | AT_RES and AT_MAC, respectively.  Success requires     |
   |      | both compared values match, respectively.              |
   |      +-----------------------------------------------------+--+
   |                                                            |
   |                                                EAP-Success |
   |&lt;-----------------------------------------------------------+
   |                                                            |
</artwork>
            <artwork type="svg" align="center" pn="section-4.2-2.1.2"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="750" width="500" viewBox="0 0 600 800" 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 72,160 L 72,320" fill="none" stroke="black"/>
                <path d="M 88,688 L 88,752" fill="none" stroke="black"/>
                <path d="M 472,400 L 472,608" fill="none" stroke="black"/>
                <path d="M 520,48 L 520,160" fill="none" stroke="black"/>
                <path d="M 520,320 L 520,688" fill="none" stroke="black"/>
                <path d="M 520,752 L 520,816" fill="none" stroke="black"/>
                <path d="M 544,160 L 544,320" fill="none" stroke="black"/>
                <path d="M 544,688 L 544,752" fill="none" stroke="black"/>
                <path d="M 40,80 L 520,80" fill="none" stroke="black"/>
                <path d="M 32,144 L 512,144" fill="none" stroke="black"/>
                <path d="M 72,160 L 544,160" fill="none" stroke="black"/>
                <path d="M 72,320 L 544,320" fill="none" stroke="black"/>
                <path d="M 40,384 L 520,384" fill="none" stroke="black"/>
                <path d="M 8,400 L 472,400" fill="none" stroke="black"/>
                <path d="M 8,608 L 472,608" fill="none" stroke="black"/>
                <path d="M 32,672 L 512,672" fill="none" stroke="black"/>
                <path d="M 88,688 L 544,688" fill="none" stroke="black"/>
                <path d="M 88,752 L 544,752" fill="none" stroke="black"/>
                <path d="M 40,800 L 520,800" fill="none" stroke="black"/>
                <path d="M 144,640 L 144,640" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="520,672 508,666.4 508,677.6" fill="black" transform="rotate(0,512,672)"/>
                <polygon class="arrowhead" points="520,144 508,138.4 508,149.6" fill="black" transform="rotate(0,512,144)"/>
                <polygon class="arrowhead" points="48,800 36,794.4 36,805.6" fill="black" transform="rotate(180,40,800)"/>
                <polygon class="arrowhead" points="48,384 36,378.4 36,389.6" fill="black" transform="rotate(180,40,384)"/>
                <polygon class="arrowhead" points="48,80 36,74.4 36,85.6" fill="black" transform="rotate(180,40,80)"/>
                <g class="text">
                  <text x="28" y="36">Peer</text>
                  <text x="516" y="36">Server</text>
                  <text x="428" y="68">EAP-Request/Identity</text>
                  <text x="128" y="116">EAP-Response/Identity</text>
                  <text x="80" y="132">(Includes</text>
                  <text x="148" y="132">user's</text>
                  <text x="208" y="132">Network</text>
                  <text x="268" y="132">Access</text>
                  <text x="340" y="132">Identifier</text>
                  <text x="412" y="132">(NAI))</text>
                  <text x="96" y="180">The</text>
                  <text x="140" y="180">Server</text>
                  <text x="212" y="180">determines</text>
                  <text x="272" y="180">the</text>
                  <text x="320" y="180">network</text>
                  <text x="372" y="180">name</text>
                  <text x="408" y="180">and</text>
                  <text x="456" y="180">ensures</text>
                  <text x="508" y="180">that</text>
                  <text x="96" y="196">the</text>
                  <text x="136" y="196">given</text>
                  <text x="188" y="196">access</text>
                  <text x="248" y="196">network</text>
                  <text x="292" y="196">is</text>
                  <text x="348" y="196">authorized</text>
                  <text x="404" y="196">to</text>
                  <text x="432" y="196">use</text>
                  <text x="464" y="196">the</text>
                  <text x="112" y="212">claimed</text>
                  <text x="168" y="212">name.</text>
                  <text x="216" y="212">The</text>
                  <text x="260" y="212">Server</text>
                  <text x="308" y="212">then</text>
                  <text x="348" y="212">runs</text>
                  <text x="384" y="212">the</text>
                  <text x="436" y="212">EAP-AKA'</text>
                  <text x="124" y="228">algorithms</text>
                  <text x="212" y="228">generating</text>
                  <text x="276" y="228">RAND</text>
                  <text x="312" y="228">and</text>
                  <text x="352" y="228">AUTN,</text>
                  <text x="392" y="228">and</text>
                  <text x="440" y="228">derives</text>
                  <text x="504" y="228">session</text>
                  <text x="100" y="244">keys</text>
                  <text x="140" y="244">from</text>
                  <text x="176" y="244">CK'</text>
                  <text x="208" y="244">and</text>
                  <text x="244" y="244">IK'.</text>
                  <text x="292" y="244">RAND</text>
                  <text x="328" y="244">and</text>
                  <text x="364" y="244">AUTN</text>
                  <text x="400" y="244">are</text>
                  <text x="436" y="244">sent</text>
                  <text x="468" y="244">as</text>
                  <text x="112" y="260">AT_RAND</text>
                  <text x="160" y="260">and</text>
                  <text x="208" y="260">AT_AUTN</text>
                  <text x="288" y="260">attributes,</text>
                  <text x="368" y="260">whereas</text>
                  <text x="416" y="260">the</text>
                  <text x="464" y="260">network</text>
                  <text x="516" y="260">name</text>
                  <text x="92" y="276">is</text>
                  <text x="152" y="276">transported</text>
                  <text x="212" y="276">in</text>
                  <text x="240" y="276">the</text>
                  <text x="308" y="276">AT_KDF_INPUT</text>
                  <text x="404" y="276">attribute.</text>
                  <text x="484" y="276">AT_KDF</text>
                  <text x="112" y="292">signals</text>
                  <text x="160" y="292">the</text>
                  <text x="196" y="292">used</text>
                  <text x="232" y="292">key</text>
                  <text x="292" y="292">derivation</text>
                  <text x="376" y="292">function.</text>
                  <text x="440" y="292">The</text>
                  <text x="488" y="292">session</text>
                  <text x="100" y="308">keys</text>
                  <text x="136" y="308">are</text>
                  <text x="172" y="308">used</text>
                  <text x="204" y="308">to</text>
                  <text x="244" y="308">create</text>
                  <text x="288" y="308">the</text>
                  <text x="332" y="308">AT_MAC</text>
                  <text x="404" y="308">attribute.</text>
                  <text x="404" y="356">EAP-Request/AKA'-Challenge</text>
                  <text x="160" y="372">(AT_RAND,</text>
                  <text x="236" y="372">AT_AUTN,</text>
                  <text x="304" y="372">AT_KDF,</text>
                  <text x="392" y="372">AT_KDF_INPUT,</text>
                  <text x="480" y="372">AT_MAC)</text>
                  <text x="32" y="420">The</text>
                  <text x="68" y="420">Peer</text>
                  <text x="132" y="420">determines</text>
                  <text x="196" y="420">what</text>
                  <text x="232" y="420">the</text>
                  <text x="280" y="420">network</text>
                  <text x="332" y="420">name</text>
                  <text x="380" y="420">should</text>
                  <text x="424" y="420">be,</text>
                  <text x="40" y="436">based</text>
                  <text x="80" y="436">on,</text>
                  <text x="120" y="436">e.g.,</text>
                  <text x="164" y="436">what</text>
                  <text x="212" y="436">access</text>
                  <text x="284" y="436">technology</text>
                  <text x="340" y="436">it</text>
                  <text x="364" y="436">is</text>
                  <text x="404" y="436">using.</text>
                  <text x="32" y="452">The</text>
                  <text x="68" y="452">Peer</text>
                  <text x="108" y="452">also</text>
                  <text x="168" y="452">retrieves</text>
                  <text x="224" y="452">the</text>
                  <text x="272" y="452">network</text>
                  <text x="324" y="452">name</text>
                  <text x="364" y="452">sent</text>
                  <text x="396" y="452">by</text>
                  <text x="424" y="452">the</text>
                  <text x="48" y="468">network</text>
                  <text x="100" y="468">from</text>
                  <text x="136" y="468">the</text>
                  <text x="204" y="468">AT_KDF_INPUT</text>
                  <text x="300" y="468">attribute.</text>
                  <text x="368" y="468">The</text>
                  <text x="400" y="468">two</text>
                  <text x="440" y="468">names</text>
                  <text x="32" y="484">are</text>
                  <text x="84" y="484">compared</text>
                  <text x="136" y="484">for</text>
                  <text x="212" y="484">discrepancies,</text>
                  <text x="288" y="484">and</text>
                  <text x="316" y="484">if</text>
                  <text x="348" y="484">they</text>
                  <text x="380" y="484">do</text>
                  <text x="408" y="484">not</text>
                  <text x="44" y="500">match,</text>
                  <text x="88" y="500">the</text>
                  <text x="164" y="500">authentication</text>
                  <text x="236" y="500">is</text>
                  <text x="284" y="500">aborted.</text>
                  <text x="372" y="500">Otherwise,</text>
                  <text x="432" y="500">the</text>
                  <text x="48" y="516">network</text>
                  <text x="100" y="516">name</text>
                  <text x="140" y="516">from</text>
                  <text x="176" y="516">the</text>
                  <text x="244" y="516">AT_KDF_INPUT</text>
                  <text x="336" y="516">attribute</text>
                  <text x="388" y="516">is</text>
                  <text x="420" y="516">used</text>
                  <text x="28" y="532">in</text>
                  <text x="72" y="532">running</text>
                  <text x="120" y="532">the</text>
                  <text x="172" y="532">EAP-AKA'</text>
                  <text x="256" y="532">algorithms,</text>
                  <text x="344" y="532">verifying</text>
                  <text x="404" y="532">AUTN</text>
                  <text x="444" y="532">from</text>
                  <text x="48" y="548">AT_AUTN</text>
                  <text x="96" y="548">and</text>
                  <text x="144" y="548">Message</text>
                  <text x="236" y="548">Authentication</text>
                  <text x="316" y="548">Code</text>
                  <text x="360" y="548">(MAC)</text>
                  <text x="404" y="548">from</text>
                  <text x="440" y="548">the</text>
                  <text x="44" y="564">AT_MAC</text>
                  <text x="120" y="564">attributes.</text>
                  <text x="192" y="564">The</text>
                  <text x="228" y="564">Peer</text>
                  <text x="268" y="564">then</text>
                  <text x="328" y="564">generates</text>
                  <text x="388" y="564">RES.</text>
                  <text x="432" y="564">The</text>
                  <text x="36" y="580">Peer</text>
                  <text x="76" y="580">also</text>
                  <text x="128" y="580">derives</text>
                  <text x="192" y="580">session</text>
                  <text x="244" y="580">keys</text>
                  <text x="284" y="580">from</text>
                  <text x="336" y="580">CK'/IK.</text>
                  <text x="392" y="580">The</text>
                  <text x="436" y="580">AT_RES</text>
                  <text x="32" y="596">and</text>
                  <text x="76" y="596">AT_MAC</text>
                  <text x="148" y="596">attributes</text>
                  <text x="208" y="596">are</text>
                  <text x="276" y="596">constructed.</text>
                  <text x="92" y="644">EAP-Response</text>
                  <text x="204" y="644">AKA'-Challenge</text>
                  <text x="76" y="660">(AT_RES,</text>
                  <text x="144" y="660">AT_MAC)</text>
                  <text x="112" y="708">The</text>
                  <text x="156" y="708">Server</text>
                  <text x="212" y="708">checks</text>
                  <text x="256" y="708">the</text>
                  <text x="288" y="708">RES</text>
                  <text x="320" y="708">and</text>
                  <text x="352" y="708">MAC</text>
                  <text x="396" y="708">values</text>
                  <text x="460" y="708">received</text>
                  <text x="508" y="708">in</text>
                  <text x="124" y="724">AT_RES</text>
                  <text x="168" y="724">and</text>
                  <text x="216" y="724">AT_MAC,</text>
                  <text x="304" y="724">respectively.</text>
                  <text x="400" y="724">Success</text>
                  <text x="468" y="724">requires</text>
                  <text x="116" y="740">both</text>
                  <text x="172" y="740">compared</text>
                  <text x="236" y="740">values</text>
                  <text x="292" y="740">match,</text>
                  <text x="376" y="740">respectively.</text>
                  <text x="464" y="788">EAP-Success</text>
                </g>
              </svg>
            </artwork>
          </artset>
        </figure>
      </section>
      <section anchor="attacks" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-attacks-against-long-term-k">Attacks Against Long-Term Keys in Smart Cards</name>
        <t indent="0" pn="section-4.3-1">The general security properties and potential vulnerabilities of
        AKA and EAP-AKA' are discussed in <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>.</t>
        <t indent="0" pn="section-4.3-2">An important question in that discussion relates to the potential
        compromise of long-term keys, as discussed earlier.  Attacks on
        long-term keys are not specific to AKA or EAP-AKA', and all security
        systems fail, at least to some extent, if key material is
        stolen. However, it would be preferable to retain some security even
        in the face of such attacks.  This document specifies a mechanism that
        reduces the risks of compromising key material belonging to previous
        sessions, before the long-term keys were compromised.  It also forces
        attackers to be active even after the compromise.</t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-protocol-overview">Protocol Overview</name>
      <t indent="0" pn="section-5-1">Forward Secrecy (FS) for EAP-AKA' is achieved by using an Elliptic
      Curve Diffie-Hellman (ECDH) exchange <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>. To provide FS, the exchange must be run in an
      ephemeral manner, i.e., both sides generate temporary keys according to
      the negotiated ciphersuite. For example, for X25519, this is done as
      specified in <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>.  This method is
      referred to as "ECDHE", where the last "E" stands for "Ephemeral". The
      two initially registered elliptic curves and their wire formats are
      chosen to align with the elliptic curves and formats specified for
      Subscription Concealed Identifier (SUCI) encryption in Appendix C.3.4 of
      3GPP <xref target="TS.33.501" format="default" sectionFormat="of" derivedContent="TS.33.501"/>.</t>
      <t indent="0" pn="section-5-2">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 indent="0" pn="section-5-3">The purpose of the protocol is to achieve mutual authentication
  between the EAP Server and Peer and to establish key material
  for secure communication between the two.  This document specifies
  the calculation of key material, providing new properties that are
  not present in key material provided by EAP-AKA' in its original
      form.</t>
      <t indent="0" pn="section-5-4"><xref target="figakafs" format="default" sectionFormat="of" derivedContent="Figure 2"/> describes the overall
      process. Since the goal has been to not require new infrastructure or
      credentials, the flow diagrams also show the conceptual interaction with
      the USIM card and the home environment. Recall that the home environment
      represents the 3GPP Authentication Database (AD) and Server.  The
      details of those interactions are outside the scope of this document;
      however, and the reader is referred to the 3GPP specifications (for 5G,
      this is specified in 3GPP <xref target="TS.33.501" format="default" sectionFormat="of" derivedContent="TS.33.501"/>).</t>
      <figure anchor="figakafs" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-eap-aka-fs-authentication-p">EAP-AKA' FS Authentication Process</name>
        <artset pn="section-5-5.1">
          <artwork type="ascii-art" name="" align="left" alt="" pn="section-5-5.1.1">
 USIM           Peer                        Server              AD
   |              |                            |                |
   |              |           EAP-Req/Identity |                |
   |              |&lt;---------------------------+                |
   |              |                            |                |
   |              | EAP-Resp/Identity          |                |
   |              | (Privacy-Friendly)         |                |
   |              +---------------------------&gt;|                |
   |      +-------+----------------------------+----------------+----+
   |      | The Server now has an identity for the Peer.  The Server |
   |      | then asks the help of the AD to run EAP-AKA algorithms,  |
   |      | generating RAND, AUTN, XRES, CK, and IK.  Typically, the |
   |      | AD performs the first part of derivations so that the    |
   |      | authentication Server gets the CK' and IK' keys already  |
   |      | tied to a particular network name.                       |
   |      +-------+----------------------------+----------------+----+
   |              |                            |                |
   |              |                            | ID, key deriv. |
   |              |                            | function,      |
   |              |                            | network name   |
   |              |                            +---------------&gt;|
   |              |                            |                |
   |              |                            |    RAND, AUTN, |
   |              |                            | XRES, CK', IK' |
   |              |                            |&lt;---------------+
   |      +-------+----------------------------+----------------+----+
   |      | The Server now has the needed authentication vector.  It |
   |      | generates an ephemeral key pair, and sends the public    |
   |      | key of that key pair and the first EAP method message to |
   |      | the Peer. In the message the AT_PUB_ECDHE attribute      |
   |      | carries the public key and the AT_KDF_FS attribute       |
   |      | carries other FS-related parameters. Both of these are   |
   |      | skippable attributes that can be ignored if the Peer     |
   |      | does not support this extension.                         |
   |      +-------+----------------------------+----------------+----+
   |              |                            |                |
   |              |     EAP-Req/AKA'-Challenge |                |
   |              |  AT_RAND, AT_AUTN, AT_KDF, |                |
   |              |   AT_KDF_FS, AT_KDF_INPUT, |                |
   |              |       AT_PUB_ECDHE, AT_MAC |                |
   |              |&lt;---------------------------+                |
+--+--------------+----------------------------+---------+      |
| The Peer checks if it wants to do the FS extension.    |      |
| If yes, it will eventually respond with AT_PUB_ECDHE   |      |
| and AT_MAC.  If not, it will ignore AT_PUB_ECDHE and   |      |
| AT_KDF_FS and base all calculations on basic EAP-AKA'  |      |
| attributes, continuing just as in EAP-AKA' per RFC     |      |
| 9048 rules.  In any case, the Peer needs to query the  |      |
| auth parameters from the USIM card.                    |      |
+--+--------------+----------------------------+---------+      |
   |              |                            |                |
   |   RAND, AUTN |                            |                |
   |&lt;-------------+                            |                |
   |              |                            |                |
   | CK, IK, RES  |                            |                |
   +-------------&gt;|                            |                |
+--+--------------+----------------------------+---------+      |
| The Peer now has everything to respond.  If it wants   |      |
| to participate in the FS extension, it will then       |      |
| generate its key pair, calculate a shared key based on |      |
| its key pair and the Server's public key.  Finally, it |      |
| proceeds to derive all EAP-AKA' key values and         |      |
| constructs a full response.                            |      |
+--+--------------+----------------------------+---------+      |
   |              |                            |                |
   |              | EAP-Resp/AKA'-Challenge    |                |
   |              | AT_RES, AT_PUB_ECDHE,      |                |
   |              | AT_MAC                     |                |
   |              +---------------------------&gt;|                |
   |      +-------+----------------------------+----------------+--+
   |      | The Server now has all the necessary values.  It       |
   |      | generates the ECDHE shared secret and checks the RES   |
   |      | and MAC values received in AT_RES and AT_MAC,          |
   |      | respectively.  Success requires both to be found       |
   |      | correct.  Note that when this document is used,        |
   |      | the keys generated from EAP-AKA' are based on CK, IK,  |
   |      | and the ECDHE value.  Even if there was an attacker    |
   |      | who held the long-term key, only an active attacker    |
   |      | could have determined the generated session keys; in   |
   |      | basic EAP-AKA' the generated keys are only based on CK |
   |      | and IK.                                                |
   |      +-------+----------------------------+----------------+--+
   |              |                            |                |
   |              |                EAP-Success |                |
   |              |&lt;---------------------------+                |
   |              |                            |                |
</artwork>
          <artwork type="svg" align="center" pn="section-5-5.1.2"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="1200" width="900" 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,1136 L 544,1328" fill="none" stroke="black"/>
              <path d="M 560,160 L 560,272" fill="none" stroke="black"/>
              <path d="M 560,432 L 560,576" fill="none" stroke="black"/>
              <path d="M 160,80 L 384,80" fill="none" stroke="black"/>
              <path d="M 152,144 L 376,144" fill="none" stroke="black"/>
              <path d="M 88,160 L 560,160" fill="none" stroke="black"/>
              <path d="M 88,272 L 560,272" fill="none" stroke="black"/>
              <path d="M 384,352 L 512,352" fill="none" stroke="black"/>
              <path d="M 392,416 L 520,416" fill="none" stroke="black"/>
              <path d="M 88,432 L 560,432" fill="none" stroke="black"/>
              <path d="M 88,576 L 560,576" fill="none" stroke="black"/>
              <path d="M 160,672 L 384,672" fill="none" stroke="black"/>
              <path d="M 8,688 L 464,688" fill="none" stroke="black"/>
              <path d="M 8,816 L 464,816" fill="none" stroke="black"/>
              <path d="M 40,864 L 152,864" fill="none" stroke="black"/>
              <path d="M 32,912 L 144,912" fill="none" stroke="black"/>
              <path d="M 8,928 L 464,928" fill="none" stroke="black"/>
              <path d="M 8,1040 L 464,1040" fill="none" stroke="black"/>
              <path d="M 152,1120 L 376,1120" fill="none" stroke="black"/>
              <path d="M 88,1136 L 544,1136" fill="none" stroke="black"/>
              <path d="M 88,1328 L 544,1328" fill="none" stroke="black"/>
              <path d="M 160,1376 L 384,1376" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="520,352 508,346.4 508,357.6" fill="black" transform="rotate(0,512,352)"/>
              <polygon class="arrowhead" points="400,416 388,410.4 388,421.6" fill="black" transform="rotate(180,392,416)"/>
              <polygon class="arrowhead" points="384,1120 372,1114.4 372,1125.6" fill="black" transform="rotate(0,376,1120)"/>
              <polygon class="arrowhead" points="384,144 372,138.4 372,149.6" fill="black" transform="rotate(0,376,144)"/>
              <polygon class="arrowhead" points="168,1376 156,1370.4 156,1381.6" fill="black" transform="rotate(180,160,1376)"/>
              <polygon class="arrowhead" points="168,672 156,666.4 156,677.6" fill="black" transform="rotate(180,160,672)"/>
              <polygon class="arrowhead" points="168,80 156,74.4 156,85.6" fill="black" transform="rotate(180,160,80)"/>
              <polygon class="arrowhead" points="152,912 140,906.4 140,917.6" fill="black" transform="rotate(0,144,912)"/>
              <polygon class="arrowhead" points="48,864 36,858.4 36,869.6" fill="black" transform="rotate(180,40,864)"/>
              <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="112" y="180">The</text>
                <text x="156" y="180">Server</text>
                <text x="200" y="180">now</text>
                <text x="232" y="180">has</text>
                <text x="260" y="180">an</text>
                <text x="308" y="180">identity</text>
                <text x="360" y="180">for</text>
                <text x="392" y="180">the</text>
                <text x="432" y="180">Peer.</text>
                <text x="480" y="180">The</text>
                <text x="524" y="180">Server</text>
                <text x="116" y="196">then</text>
                <text x="156" y="196">asks</text>
                <text x="192" y="196">the</text>
                <text x="228" y="196">help</text>
                <text x="260" y="196">of</text>
                <text x="288" y="196">the</text>
                <text x="316" y="196">AD</text>
                <text x="340" y="196">to</text>
                <text x="368" y="196">run</text>
                <text x="416" y="196">EAP-AKA</text>
                <text x="496" y="196">algorithms,</text>
                <text x="140" y="212">generating</text>
                <text x="208" y="212">RAND,</text>
                <text x="256" y="212">AUTN,</text>
                <text x="304" y="212">XRES,</text>
                <text x="344" y="212">CK,</text>
                <text x="376" y="212">and</text>
                <text x="408" y="212">IK.</text>
                <text x="476" y="212">Typically,</text>
                <text x="536" y="212">the</text>
                <text x="108" y="228">AD</text>
                <text x="156" y="228">performs</text>
                <text x="208" y="228">the</text>
                <text x="248" y="228">first</text>
                <text x="292" y="228">part</text>
                <text x="324" y="228">of</text>
                <text x="384" y="228">derivations</text>
                <text x="444" y="228">so</text>
                <text x="476" y="228">that</text>
                <text x="512" y="228">the</text>
                <text x="156" y="244">authentication</text>
                <text x="244" y="244">Server</text>
                <text x="292" y="244">gets</text>
                <text x="328" y="244">the</text>
                <text x="360" y="244">CK'</text>
                <text x="392" y="244">and</text>
                <text x="424" y="244">IK'</text>
                <text x="460" y="244">keys</text>
                <text x="512" y="244">already</text>
                <text x="116" y="260">tied</text>
                <text x="148" y="260">to</text>
                <text x="168" y="260">a</text>
                <text x="220" y="260">particular</text>
                <text x="296" y="260">network</text>
                <text x="352" y="260">name.</text>
                <text x="408" y="308">ID,</text>
                <text x="440" y="308">key</text>
                <text x="484" y="308">deriv.</text>
                <text x="432" y="324">function,</text>
                <text x="424" y="340">network</text>
                <text x="476" y="340">name</text>
                <text x="440" y="388">RAND,</text>
                <text x="488" y="388">AUTN,</text>
                <text x="416" y="404">XRES,</text>
                <text x="460" y="404">CK',</text>
                <text x="496" y="404">IK'</text>
                <text x="112" y="452">The</text>
                <text x="156" y="452">Server</text>
                <text x="200" y="452">now</text>
                <text x="232" y="452">has</text>
                <text x="264" y="452">the</text>
                <text x="308" y="452">needed</text>
                <text x="396" y="452">authentication</text>
                <text x="488" y="452">vector.</text>
                <text x="540" y="452">It</text>
                <text x="136" y="468">generates</text>
                <text x="188" y="468">an</text>
                <text x="240" y="468">ephemeral</text>
                <text x="296" y="468">key</text>
                <text x="336" y="468">pair,</text>
                <text x="376" y="468">and</text>
                <text x="416" y="468">sends</text>
                <text x="456" y="468">the</text>
                <text x="500" y="468">public</text>
                <text x="112" y="484">key</text>
                <text x="140" y="484">of</text>
                <text x="172" y="484">that</text>
                <text x="208" y="484">key</text>
                <text x="244" y="484">pair</text>
                <text x="280" y="484">and</text>
                <text x="312" y="484">the</text>
                <text x="352" y="484">first</text>
                <text x="392" y="484">EAP</text>
                <text x="436" y="484">method</text>
                <text x="496" y="484">message</text>
                <text x="540" y="484">to</text>
                <text x="112" y="500">the</text>
                <text x="152" y="500">Peer.</text>
                <text x="188" y="500">In</text>
                <text x="216" y="500">the</text>
                <text x="264" y="500">message</text>
                <text x="312" y="500">the</text>
                <text x="380" y="500">AT_PUB_ECDHE</text>
                <text x="472" y="500">attribute</text>
                <text x="128" y="516">carries</text>
                <text x="176" y="516">the</text>
                <text x="220" y="516">public</text>
                <text x="264" y="516">key</text>
                <text x="296" y="516">and</text>
                <text x="328" y="516">the</text>
                <text x="384" y="516">AT_KDF_FS</text>
                <text x="464" y="516">attribute</text>
                <text x="128" y="532">carries</text>
                <text x="184" y="532">other</text>
                <text x="252" y="532">FS-related</text>
                <text x="344" y="532">parameters.</text>
                <text x="412" y="532">Both</text>
                <text x="444" y="532">of</text>
                <text x="480" y="532">these</text>
                <text x="520" y="532">are</text>
                <text x="136" y="548">skippable</text>
                <text x="220" y="548">attributes</text>
                <text x="284" y="548">that</text>
                <text x="320" y="548">can</text>
                <text x="348" y="548">be</text>
                <text x="392" y="548">ignored</text>
                <text x="436" y="548">if</text>
                <text x="464" y="548">the</text>
                <text x="500" y="548">Peer</text>
                <text x="116" y="564">does</text>
                <text x="152" y="564">not</text>
                <text x="200" y="564">support</text>
                <text x="252" y="564">this</text>
                <text x="316" y="564">extension.</text>
                <text x="284" y="612">EAP-Req/AKA'-Challenge</text>
                <text x="204" y="628">AT_RAND,</text>
                <text x="276" y="628">AT_AUTN,</text>
                <text x="344" y="628">AT_KDF,</text>
                <text x="220" y="644">AT_KDF_FS,</text>
                <text x="320" y="644">AT_KDF_INPUT,</text>
                <text x="264" y="660">AT_PUB_ECDHE,</text>
                <text x="348" y="660">AT_MAC</text>
                <text x="32" y="708">The</text>
                <text x="68" y="708">Peer</text>
                <text x="116" y="708">checks</text>
                <text x="156" y="708">if</text>
                <text x="180" y="708">it</text>
                <text x="216" y="708">wants</text>
                <text x="252" y="708">to</text>
                <text x="276" y="708">do</text>
                <text x="304" y="708">the</text>
                <text x="332" y="708">FS</text>
                <text x="388" y="708">extension.</text>
                <text x="28" y="724">If</text>
                <text x="60" y="724">yes,</text>
                <text x="92" y="724">it</text>
                <text x="124" y="724">will</text>
                <text x="188" y="724">eventually</text>
                <text x="264" y="724">respond</text>
                <text x="316" y="724">with</text>
                <text x="388" y="724">AT_PUB_ECDHE</text>
                <text x="32" y="740">and</text>
                <text x="80" y="740">AT_MAC.</text>
                <text x="132" y="740">If</text>
                <text x="164" y="740">not,</text>
                <text x="196" y="740">it</text>
                <text x="228" y="740">will</text>
                <text x="276" y="740">ignore</text>
                <text x="356" y="740">AT_PUB_ECDHE</text>
                <text x="424" y="740">and</text>
                <text x="56" y="756">AT_KDF_FS</text>
                <text x="112" y="756">and</text>
                <text x="148" y="756">base</text>
                <text x="184" y="756">all</text>
                <text x="252" y="756">calculations</text>
                <text x="316" y="756">on</text>
                <text x="352" y="756">basic</text>
                <text x="412" y="756">EAP-AKA'</text>
                <text x="64" y="772">attributes,</text>
                <text x="156" y="772">continuing</text>
                <text x="220" y="772">just</text>
                <text x="252" y="772">as</text>
                <text x="276" y="772">in</text>
                <text x="324" y="772">EAP-AKA'</text>
                <text x="376" y="772">per</text>
                <text x="408" y="772">RFC</text>
                <text x="36" y="788">9048</text>
                <text x="84" y="788">rules.</text>
                <text x="132" y="788">In</text>
                <text x="160" y="788">any</text>
                <text x="200" y="788">case,</text>
                <text x="240" y="788">the</text>
                <text x="276" y="788">Peer</text>
                <text x="320" y="788">needs</text>
                <text x="356" y="788">to</text>
                <text x="392" y="788">query</text>
                <text x="432" y="788">the</text>
                <text x="36" y="804">auth</text>
                <text x="100" y="804">parameters</text>
                <text x="164" y="804">from</text>
                <text x="200" y="804">the</text>
                <text x="236" y="804">USIM</text>
                <text x="280" y="804">card.</text>
                <text x="80" y="852">RAND,</text>
                <text x="124" y="852">AUTN</text>
                <text x="56" y="900">CK,</text>
                <text x="88" y="900">IK,</text>
                <text x="120" y="900">RES</text>
                <text x="32" y="948">The</text>
                <text x="68" y="948">Peer</text>
                <text x="104" y="948">now</text>
                <text x="136" y="948">has</text>
                <text x="196" y="948">everything</text>
                <text x="252" y="948">to</text>
                <text x="300" y="948">respond.</text>
                <text x="356" y="948">If</text>
                <text x="380" y="948">it</text>
                <text x="416" y="948">wants</text>
                <text x="28" y="964">to</text>
                <text x="88" y="964">participate</text>
                <text x="148" y="964">in</text>
                <text x="176" y="964">the</text>
                <text x="204" y="964">FS</text>
                <text x="260" y="964">extension,</text>
                <text x="316" y="964">it</text>
                <text x="348" y="964">will</text>
                <text x="388" y="964">then</text>
                <text x="52" y="980">generate</text>
                <text x="104" y="980">its</text>
                <text x="136" y="980">key</text>
                <text x="176" y="980">pair,</text>
                <text x="240" y="980">calculate</text>
                <text x="288" y="980">a</text>
                <text x="324" y="980">shared</text>
                <text x="368" y="980">key</text>
                <text x="408" y="980">based</text>
                <text x="444" y="980">on</text>
                <text x="32" y="996">its</text>
                <text x="64" y="996">key</text>
                <text x="100" y="996">pair</text>
                <text x="136" y="996">and</text>
                <text x="168" y="996">the</text>
                <text x="220" y="996">Server's</text>
                <text x="284" y="996">public</text>
                <text x="332" y="996">key.</text>
                <text x="396" y="996">Finally,</text>
                <text x="444" y="996">it</text>
                <text x="52" y="1012">proceeds</text>
                <text x="100" y="1012">to</text>
                <text x="140" y="1012">derive</text>
                <text x="184" y="1012">all</text>
                <text x="236" y="1012">EAP-AKA'</text>
                <text x="288" y="1012">key</text>
                <text x="332" y="1012">values</text>
                <text x="376" y="1012">and</text>
                <text x="60" y="1028">constructs</text>
                <text x="112" y="1028">a</text>
                <text x="140" y="1028">full</text>
                <text x="200" y="1028">response.</text>
                <text x="256" y="1076">EAP-Resp/AKA'-Challenge</text>
                <text x="192" y="1092">AT_RES,</text>
                <text x="280" y="1092">AT_PUB_ECDHE,</text>
                <text x="188" y="1108">AT_MAC</text>
                <text x="112" y="1156">The</text>
                <text x="156" y="1156">Server</text>
                <text x="200" y="1156">now</text>
                <text x="232" y="1156">has</text>
                <text x="264" y="1156">all</text>
                <text x="296" y="1156">the</text>
                <text x="352" y="1156">necessary</text>
                <text x="424" y="1156">values.</text>
                <text x="476" y="1156">It</text>
                <text x="136" y="1172">generates</text>
                <text x="192" y="1172">the</text>
                <text x="232" y="1172">ECDHE</text>
                <text x="284" y="1172">shared</text>
                <text x="340" y="1172">secret</text>
                <text x="384" y="1172">and</text>
                <text x="428" y="1172">checks</text>
                <text x="472" y="1172">the</text>
                <text x="504" y="1172">RES</text>
                <text x="112" y="1188">and</text>
                <text x="144" y="1188">MAC</text>
                <text x="188" y="1188">values</text>
                <text x="252" y="1188">received</text>
                <text x="300" y="1188">in</text>
                <text x="340" y="1188">AT_RES</text>
                <text x="384" y="1188">and</text>
                <text x="432" y="1188">AT_MAC,</text>
                <text x="152" y="1204">respectively.</text>
                <text x="248" y="1204">Success</text>
                <text x="316" y="1204">requires</text>
                <text x="372" y="1204">both</text>
                <text x="404" y="1204">to</text>
                <text x="428" y="1204">be</text>
                <text x="464" y="1204">found</text>
                <text x="132" y="1220">correct.</text>
                <text x="196" y="1220">Note</text>
                <text x="236" y="1220">that</text>
                <text x="276" y="1220">when</text>
                <text x="316" y="1220">this</text>
                <text x="372" y="1220">document</text>
                <text x="420" y="1220">is</text>
                <text x="456" y="1220">used,</text>
                <text x="112" y="1236">the</text>
                <text x="148" y="1236">keys</text>
                <text x="208" y="1236">generated</text>
                <text x="268" y="1236">from</text>
                <text x="324" y="1236">EAP-AKA'</text>
                <text x="376" y="1236">are</text>
                <text x="416" y="1236">based</text>
                <text x="452" y="1236">on</text>
                <text x="480" y="1236">CK,</text>
                <text x="512" y="1236">IK,</text>
                <text x="112" y="1252">and</text>
                <text x="144" y="1252">the</text>
                <text x="184" y="1252">ECDHE</text>
                <text x="236" y="1252">value.</text>
                <text x="292" y="1252">Even</text>
                <text x="324" y="1252">if</text>
                <text x="360" y="1252">there</text>
                <text x="400" y="1252">was</text>
                <text x="428" y="1252">an</text>
                <text x="476" y="1252">attacker</text>
                <text x="112" y="1268">who</text>
                <text x="148" y="1268">held</text>
                <text x="184" y="1268">the</text>
                <text x="240" y="1268">long-term</text>
                <text x="300" y="1268">key,</text>
                <text x="340" y="1268">only</text>
                <text x="372" y="1268">an</text>
                <text x="412" y="1268">active</text>
                <text x="476" y="1268">attacker</text>
                <text x="120" y="1284">could</text>
                <text x="164" y="1284">have</text>
                <text x="228" y="1284">determined</text>
                <text x="288" y="1284">the</text>
                <text x="344" y="1284">generated</text>
                <text x="416" y="1284">session</text>
                <text x="472" y="1284">keys;</text>
                <text x="508" y="1284">in</text>
                <text x="120" y="1300">basic</text>
                <text x="180" y="1300">EAP-AKA'</text>
                <text x="232" y="1300">the</text>
                <text x="288" y="1300">generated</text>
                <text x="348" y="1300">keys</text>
                <text x="384" y="1300">are</text>
                <text x="420" y="1300">only</text>
                <text x="464" y="1300">based</text>
                <text x="500" y="1300">on</text>
                <text x="524" y="1300">CK</text>
                <text x="112" y="1316">and</text>
                <text x="144" y="1316">IK.</text>
                <text x="328" y="1364">EAP-Success</text>
              </g>
            </svg>
          </artwork>
        </artset>
      </figure>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-extensions-to-eap-aka">Extensions to EAP-AKA'</name>
      <section anchor="at_pub_dh" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-at_pub_ecdhe">AT_PUB_ECDHE</name>
        <t indent="0" pn="section-6.1-1">The AT_PUB_ECDHE attribute carries an ECDHE value.</t>
        <t indent="0" pn="section-6.1-2">The format of the AT_PUB_ECDHE attribute is shown below.</t>
        <artset pn="section-6.1-3">
          <artwork type="ascii-art" align="center" name="" alt="" pn="section-6.1-3.1">
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_PUB_ECDHE  | Length        | Value                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          <artwork type="svg" name="" align="left" alt="" pn="section-6.1-3.2"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="112" width="528" viewBox="0 0 528 112" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,64 L 8,96" fill="none" stroke="black"/>
              <path d="M 136,64 L 136,96" fill="none" stroke="black"/>
              <path d="M 264,64 L 264,96" fill="none" stroke="black"/>
              <path d="M 520,64 L 520,96" fill="none" stroke="black"/>
              <path d="M 8,64 L 520,64" fill="none" stroke="black"/>
              <path d="M 8,96 L 520,96" fill="none" stroke="black"/>
              <g class="text">
                <text x="16" y="36">0</text>
                <text x="176" y="36">1</text>
                <text x="336" y="36">2</text>
                <text x="496" y="36">3</text>
                <text x="16" y="52">0</text>
                <text x="32" y="52">1</text>
                <text x="48" y="52">2</text>
                <text x="64" y="52">3</text>
                <text x="80" y="52">4</text>
                <text x="96" y="52">5</text>
                <text x="112" y="52">6</text>
                <text x="128" y="52">7</text>
                <text x="144" y="52">8</text>
                <text x="160" y="52">9</text>
                <text x="176" y="52">0</text>
                <text x="192" y="52">1</text>
                <text x="208" y="52">2</text>
                <text x="224" y="52">3</text>
                <text x="240" y="52">4</text>
                <text x="256" y="52">5</text>
                <text x="272" y="52">6</text>
                <text x="288" y="52">7</text>
                <text x="304" y="52">8</text>
                <text x="320" y="52">9</text>
                <text x="336" y="52">0</text>
                <text x="352" y="52">1</text>
                <text x="368" y="52">2</text>
                <text x="384" y="52">3</text>
                <text x="400" y="52">4</text>
                <text x="416" y="52">5</text>
                <text x="432" y="52">6</text>
                <text x="448" y="52">7</text>
                <text x="464" y="52">8</text>
                <text x="480" y="52">9</text>
                <text x="496" y="52">0</text>
                <text x="512" y="52">1</text>
                <text x="68" y="84">AT_PUB_ECDHE</text>
                <text x="172" y="84">Length</text>
                <text x="296" y="84">Value</text>
              </g>
            </svg>
          </artwork>
        </artset>
        <t indent="0" pn="section-6.1-4">The fields are as follows:</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-6.1-5">
          <dt pn="section-6.1-5.1">AT_PUB_ECDHE:</dt>
          <dd pn="section-6.1-5.2">This is set to 152.</dd>
          <dt pn="section-6.1-5.3">Length:</dt>
          <dd pn="section-6.1-5.4">This is the length of the attribute, set as other attributes in
          EAP-AKA <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/>. The length is
          expressed in multiples of 4 bytes. The length includes the attribute
          type field, the Length field itself, and the Value field (along with
          any padding).</dd>
          <dt pn="section-6.1-5.5">Value:</dt>
          <dd pn="section-6.1-5.6">
            <t indent="0" pn="section-6.1-5.6.1">This value is
           the sender's ECDHE public key. The value depends on the AT_KDF_FS attribute and
           is calculated as follows:</t>
            <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.1-5.6.2">
              <li pn="section-6.1-5.6.2.1">
                <t indent="0" pn="section-6.1-5.6.2.1.1">For X25519, the length of this value is 32 bytes, encoded
                as specified in <xref target="RFC7748" sectionFormat="of" section="5" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7748#section-5" derivedContent="RFC7748"/>.</t>
              </li>
              <li pn="section-6.1-5.6.2.2">
                <t indent="0" pn="section-6.1-5.6.2.2.1">For P-256, the length of this value is 33 bytes, encoded
                using the compressed form specified in Section 2.3.3 of <xref target="SEC1" format="default" sectionFormat="of" derivedContent="SEC1"/>.</t>
              </li>
            </ul>
            <t indent="0" pn="section-6.1-5.6.3">Because the length of the attribute must be a multiple of 4
            bytes, the sender pads the Value field with zero bytes when
            necessary. To retain the security of the keys, the sender
            <bcp14>SHALL</bcp14> generate a fresh value for each run of the
            protocol.</t>
          </dd>
        </dl>
      </section>
      <section anchor="at_kdf_dh" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-at_kdf_fs">AT_KDF_FS</name>
        <t indent="0" pn="section-6.2-1">The AT_KDF_FS attribute indicates the used or desired FS key
         generation function, if the FS extension
         is used. It will also indicate the
         used or desired ECDHE group. A new attribute is needed to
         carry this information, as AT_KDF carries the basic KDF
         value that is still used together with the FS KDF
         value. The basic KDF value is also used by those EAP Peers
         that cannot or do not want to use this extension.</t>
        <t indent="0" pn="section-6.2-2">This document only specifies the behavior relating to the following
        combinations of basic KDF values and FS KDF values:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6.2-3">
          <li pn="section-6.2-3.1">the
        basic KDF value in AT_KDF is 1, as specified in <xref target="RFC5448" format="default" sectionFormat="of" derivedContent="RFC5448"/> and <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/> and</li>
          <li pn="section-6.2-3.2">the FS KDF values in AT_KDF_FS are 1 or 2, as specified
        below and in <xref target="kdf2" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.</li>
        </ul>
        <t indent="0" pn="section-6.2-4">Any future specifications that add either new basic KDFs or new FS KDF values need to specify
	 how they are treated and what combinations are allowed. This requirement is an update to how 
	 <xref target="RFC5448" format="default" sectionFormat="of" derivedContent="RFC5448"/> and <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/> may be extended in the future.</t>
        <t indent="0" pn="section-6.2-5">The format of the AT_KDF_FS attribute is shown below.</t>
        <artset pn="section-6.2-6">
          <artwork type="ascii-art" align="center" name="" alt="" pn="section-6.2-6.1">
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AT_KDF_FS     | Length        | FS Key Derivation Function    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
          <artwork type="svg" name="" align="left" alt="" pn="section-6.2-6.2"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="112" width="528" viewBox="0 0 528 112" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px">
              <path d="M 8,64 L 8,96" fill="none" stroke="black"/>
              <path d="M 136,64 L 136,96" fill="none" stroke="black"/>
              <path d="M 264,64 L 264,96" fill="none" stroke="black"/>
              <path d="M 520,64 L 520,96" fill="none" stroke="black"/>
              <path d="M 8,64 L 520,64" fill="none" stroke="black"/>
              <path d="M 8,96 L 520,96" fill="none" stroke="black"/>
              <g class="text">
                <text x="16" y="36">0</text>
                <text x="176" y="36">1</text>
                <text x="336" y="36">2</text>
                <text x="496" y="36">3</text>
                <text x="16" y="52">0</text>
                <text x="32" y="52">1</text>
                <text x="48" y="52">2</text>
                <text x="64" y="52">3</text>
                <text x="80" y="52">4</text>
                <text x="96" y="52">5</text>
                <text x="112" y="52">6</text>
                <text x="128" y="52">7</text>
                <text x="144" y="52">8</text>
                <text x="160" y="52">9</text>
                <text x="176" y="52">0</text>
                <text x="192" y="52">1</text>
                <text x="208" y="52">2</text>
                <text x="224" y="52">3</text>
                <text x="240" y="52">4</text>
                <text x="256" y="52">5</text>
                <text x="272" y="52">6</text>
                <text x="288" y="52">7</text>
                <text x="304" y="52">8</text>
                <text x="320" y="52">9</text>
                <text x="336" y="52">0</text>
                <text x="352" y="52">1</text>
                <text x="368" y="52">2</text>
                <text x="384" y="52">3</text>
                <text x="400" y="52">4</text>
                <text x="416" y="52">5</text>
                <text x="432" y="52">6</text>
                <text x="448" y="52">7</text>
                <text x="464" y="52">8</text>
                <text x="480" y="52">9</text>
                <text x="496" y="52">0</text>
                <text x="512" y="52">1</text>
                <text x="56" y="84">AT_KDF_FS</text>
                <text x="172" y="84">Length</text>
                <text x="284" y="84">FS</text>
                <text x="312" y="84">Key</text>
                <text x="372" y="84">Derivation</text>
                <text x="452" y="84">Function</text>
              </g>
            </svg>
          </artwork>
        </artset>
        <t indent="0" pn="section-6.2-7">The fields are as follows:</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-6.2-8">
          <dt pn="section-6.2-8.1">AT_KDF_FS:</dt>
          <dd pn="section-6.2-8.2">This is set to 153.</dd>
          <dt pn="section-6.2-8.3">Length:</dt>
          <dd pn="section-6.2-8.4">This is the length of the attribute; it <bcp14>MUST</bcp14> be set to 1.</dd>
          <dt pn="section-6.2-8.5">FS Key Derivation Function:</dt>
          <dd pn="section-6.2-8.6">This is an enumerated value representing the FS Key Derivation Function (KDF) that the Server (or Peer) wishes to use. See
          <xref target="kdf2" format="default" sectionFormat="of" derivedContent="Section 6.3"/> for the functions specified
          in this document. Note: this field has a different name space than
          the similar field in the AT_KDF attribute KDF
          defined in <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>.</dd>
        </dl>
        <t indent="0" pn="section-6.2-9">Servers <bcp14>MUST</bcp14> send one or more AT_KDF_FS attributes
        in the EAP-Request/AKA'-Challenge message. These attributes represent
        the desired functions ordered by preference, with the most preferred
        function being the first attribute. The most preferred function is the
        only one that the Server includes a public key value for, however. So,
        for a set of AT_KDF_FS attributes, there is always only one
        AT_PUB_ECDHE attribute.</t>
        <t indent="0" pn="section-6.2-10">Upon receiving a set of these attributes:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-6.2-11">
          <li pn="section-6.2-11.1">If the Peer supports and is willing to use the FS KDF indicated
          by the first AT_KDF_FS attribute, and is willing and able to use the
          extension defined in this document, the function will be used
          without any further negotiation.</li>
          <li pn="section-6.2-11.2">If the Peer does not support this function or is unwilling to
          use it, it responds to the Server with an indication that a
          different function is needed. Similarly, with the negotiation process
          defined in <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/> for AT_KDF, the
          Peer sends an EAP-Response/AKA'-Challenge message that contains only
          one attribute, AT_KDF_FS, with the value set to the desired
          alternative function from among the ones suggested by the Server
          earlier. If there is no suitable alternative, the Peer has a choice
          of either falling back to EAP-AKA' or behaving as if the AUTN had been
          incorrect and failing authentication (see Figure 3 of <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/>). The Peer <bcp14>MUST</bcp14>
          fail the authentication if there are any duplicate values within the
          list of AT_KDF_FS attributes (except where the duplication is due to
          a request to change the KDF; see below for
          further information).</li>
          <li pn="section-6.2-11.3">If the Peer does not recognize the extension defined in this
          document or is unwilling to use it, it ignores the AT_KDF_FS
          attribute.</li>
        </ul>
        <t indent="0" pn="section-6.2-12">Upon receiving an EAP-Response/AKA'-Challenge message with an AT_KDF_FS attribute
        from the Peer, the Server checks that the suggested AT_KDF_FS value
        was one of the alternatives in its offer. The first AT_KDF_FS value in
        the message from the Server is not a valid alternative. If the Peer
        has replied with the first AT_KDF_FS value, the Server behaves as if
        the AT_MAC of the response had been incorrect and fails the
        authentication. For an overview of the failed authentication process
        in the Server side, see Section <xref target="RFC4187" sectionFormat="bare" section="3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4187#section-3" derivedContent="RFC4187"/> and Figure 2 in <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/>. Otherwise, the Server re-sends the
        EAP-Response/AKA'-Challenge message, but adds the selected alternative
        to the beginning of the list of AT_KDF_FS attributes and retains the
        entire list following it. Note that this means that the selected
        alternative appears twice in the set of AT_KDF values. Responding to
        the Peer's request to change the FS KDF is the
        only valid situation where such duplication may occur.</t>
        <t indent="0" pn="section-6.2-13">When the Peer receives the new EAP-Request/AKA'-Challenge message,
        it <bcp14>MUST</bcp14> check that the requested change, and only the
        requested change, occurred in the list of AT_KDF_FS attributes. If so,
        it continues.  If not, it behaves as if AT_MAC were incorrect and
        fails the authentication. If the Peer receives multiple
        EAP-Request/AKA'-Challenge messages with differing AT_KDF_FS
        attributes without having requested negotiation, the Peer
        <bcp14>MUST</bcp14> behave as if AT_MAC were incorrect and fail
        the authentication.</t>
      </section>
      <section anchor="kdf2" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-forward-secrecy-key-derivat">Forward Secrecy Key Derivation Functions</name>
        <t indent="0" pn="section-6.3-1">Two new FS KDF types are defined for "EAP-AKA'
        with ECDHE and X25519", represented by value 1, and "EAP-AKA' with
        ECDHE and P-256", represented by value 2. These values represent a particular
        choice of KDF and, at the same time, select an
        ECDHE group to be used.</t>
        <t indent="0" pn="section-6.3-2">The FS KDF type value is only used in the
        AT_KDF_FS attribute. When the FS extension is used, the
        AT_KDF_FS attribute determines how to derive the MK_ECDHE key, K_re key,
        Master Session Key (MSK), and Extended Master Session Key (EMSK). The
        AT_KDF_FS attribute should not be confused with the different range of
        KDFs that can be represented in the AT_KDF
        attribute as defined in <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>. When the FS extension is used, the
        AT_KDF attribute only specifies how to derive the Master Key (MK), the K_encr key, and the
        K_aut key.</t>
        <t indent="0" pn="section-6.3-3">Key derivation in this extension produces exactly the same keys for
        internal use within one authentication run as EAP-AKA' <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/> 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 indent="0" pn="section-6.3-4">When the FS KDF field in the AT_KDF_FS
         attribute is set to 1 or 2 and the KDF field
         in the AT_KDF attribute is set to 1, the MK and
         accompanying keys are derived as follows:		 
        </t>
        <artwork align="center" name="" type="" alt="" pn="section-6.3-5">
MK       = PRF'(IK'|CK',"EAP-AKA'"|Identity) 
MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity)
K_encr   = MK[0..127]
K_aut    = MK[128..383]
K_re     = MK_ECDHE[0..255]
MSK      = MK_ECDHE[256..767]
EMSK     = MK_ECDHE[768..1279]
</artwork>
        <t indent="0" pn="section-6.3-6">An explanation of the notation used above is copied here:</t>
        <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-6.3-7">
          <li pn="section-6.3-7.1">[n..m] denotes the substring from bit n to m.</li>
          <li pn="section-6.3-7.2">PRF' is a new pseudorandom function specified in <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>.</li>
          <li pn="section-6.3-7.3">K_encr is the encryption key (128 bits).</li>
          <li pn="section-6.3-7.4">K_aut is the authentication key (256 bits).</li>
          <li pn="section-6.3-7.5">K_re is the re-authentication key (256 bits).</li>
          <li pn="section-6.3-7.6">MSK is the Master Session Key (512 bits).</li>
          <li pn="section-6.3-7.7">EMSK is the Extended Master Session Key (512 bits).</li>
        </ul>
        <t indent="0" pn="section-6.3-8">Note: MSK and EMSK are outputs from a successful EAP method run
        <xref target="RFC3748" format="default" sectionFormat="of" derivedContent="RFC3748"/>.</t>
        <t indent="0" pn="section-6.3-9">The CK and IK are produced by the AKA algorithm. The IK' and CK' are
        derived as specified in <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/> from
        the IK and CK.</t>
        <t indent="0" pn="section-6.3-10">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 indent="0" pn="section-6.3-11">Requirements for how to securely generate, validate, and process the
	ephemeral public keys depend on the elliptic curve.</t>
        <t indent="0" pn="section-6.3-12">For P-256, the SHARED_SECRET is the shared secret computed as
        specified in Section 5.7.1.2 of <xref target="SP-800-56A" format="default" sectionFormat="of" derivedContent="SP-800-56A"/>. Requirements are defined in Section 5 of 
	<xref target="SP-800-56A" format="default" sectionFormat="of" derivedContent="SP-800-56A"/>, in particular, Sections 5.6.2.3.4, 5.6.3.1,
        and 5.6.3.3. At least partial public key validation
        <bcp14>MUST</bcp14> be done for the ephemeral public keys. The
        uncompressed y-coordinate can be computed as described in Section
        2.3.4 of <xref target="SEC1" format="default" sectionFormat="of" derivedContent="SEC1"/>.</t>
        <t indent="0" pn="section-6.3-13">For X25519, the SHARED_SECRET is the shared secret computed as specified in
	<xref target="RFC7748" sectionFormat="of" section="6.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7748#section-6.1" derivedContent="RFC7748"/>. Both the Peer and the Server
	<bcp14>MAY</bcp14> check for the zero-value shared secret as specified in 
	<xref target="RFC7748" sectionFormat="of" section="6.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7748#section-6.1" derivedContent="RFC7748"/>.</t>
        <aside pn="section-6.3-14">
          <t indent="0" pn="section-6.3-14.1">Note: If performed inappropriately, the way that the shared
	secret is tested for zero can provide an ability for attackers to
	listen to CPU power usage side channels. Refer to <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/> for a description of how to
	perform this check in a way that it does not become a
problem.</t>
        </aside>
        <t indent="0" pn="section-6.3-15">If validation of the other party's ephemeral public key or the shared secret fails,
	a party <bcp14>MUST</bcp14> behave as if the current EAP-AKA' process starts again from the beginning.</t>
        <t indent="0" pn="section-6.3-16">The rest of the computation proceeds as defined in <xref target="RFC9048" sectionFormat="of" section="3.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc9048#section-3.3" derivedContent="RFC9048"/>.</t>
      </section>
      <section anchor="groups" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-ecdhe-groups">ECDHE Groups</name>
        <t indent="0" pn="section-6.4-1">The selection of suitable groups for the elliptic curve
         computation is necessary. The choice of a group is made at
         the same time as the decision to use a particular KDF in the AT_KDF_FS attribute.</t>
        <t indent="0" pn="section-6.4-2">For "EAP-AKA' with ECDHE and
         X25519", the group is the Curve25519 group specified in
         <xref target="RFC7748" format="default" sectionFormat="of" derivedContent="RFC7748"/>. The support for this group is <bcp14>REQUIRED</bcp14>.</t>
        <t indent="0" pn="section-6.4-3">For "EAP-AKA' with ECDHE and P-256", the group is the NIST P-256
        group (SEC group secp256r1), specified in Section 3.2.1.3 of <xref target="SP-800-186" format="default" sectionFormat="of" derivedContent="SP-800-186"/> or alternatively, Section 2.4.2
        of <xref target="SEC2" format="default" sectionFormat="of" derivedContent="SEC2"/>.  The support for this group
        is <bcp14>REQUIRED</bcp14>.</t>
        <t indent="0" pn="section-6.4-4">The term "support" here means that the group <bcp14>MUST</bcp14> be implemented.</t>
      </section>
      <section anchor="secMessageProc" numbered="true" toc="include" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-message-processing">Message Processing</name>
        <t indent="0" pn="section-6.5-1">This section specifies the changes related to message processing
        when this extension is used in EAP-AKA'. It specifies when a message
        may be transmitted or accepted, which attributes are allowed in a
        message, which attributes are required in a message, and other
        message-specific details, where those details are different for this
        extension than the base EAP-AKA' or EAP-AKA protocol. Unless otherwise
        specified here, the rules from <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/> or <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/>
        apply.</t>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.5.1">
          <name slugifiedName="name-eap-request-aka-identity">EAP-Request/AKA'-Identity</name>
          <t indent="0" pn="section-6.5.1-1">There are no changes for the EAP-Request/AKA'-Identity, except
          that the AT_KDF_FS or AT_PUB_ECDHE attributes <bcp14>MUST NOT</bcp14> be added to this message.  The appearance of these
          attributes in a received message <bcp14>MUST</bcp14> be ignored.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.5.2">
          <name slugifiedName="name-eap-response-aka-identity">EAP-Response/AKA'-Identity</name>
          <t indent="0" pn="section-6.5.2-1">There are no changes for the EAP-Response/AKA'-Identity, except
          that the AT_KDF_FS or AT_PUB_ECDHE attributes <bcp14>MUST NOT</bcp14> be added to this message. The appearance of these
          attributes in a received message <bcp14>MUST</bcp14> be ignored. The
          Peer identifier <bcp14>SHALL</bcp14> comply with the
          privacy-friendly requirements of <xref target="RFC9190" format="default" sectionFormat="of" derivedContent="RFC9190"/>.  An example of a compliant way of constructing a
          privacy-friendly Peer identifier is using a non-null SUCI <xref target="TS.33.501" format="default" sectionFormat="of" derivedContent="TS.33.501"/>.
          </t>
        </section>
        <section anchor="procakachall" numbered="true" toc="include" removeInRFC="false" pn="section-6.5.3">
          <name slugifiedName="name-eap-request-aka-challenge">EAP-Request/AKA'-Challenge</name>
          <t indent="0" pn="section-6.5.3-1">The Server sends the EAP-Request/AKA'-Challenge on full
          authentication as specified by <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/> and <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>.
          The attributes AT_RAND, AT_AUTN, and AT_MAC <bcp14>MUST</bcp14> be
          included and checked on reception as specified in <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/>. They are also necessary for
          backwards compatibility.</t>
          <t indent="0" pn="section-6.5.3-2">In the EAP-Request/AKA'-Challenge, there is no message-specific data
          covered by the MAC for the AT_MAC attribute. The AT_KDF_FS and
          AT_PUB_ECDHE attributes <bcp14>MUST</bcp14> be included. The
          AT_PUB_ECDHE attribute carries the Server's public Diffie-Hellman
          key. If either AT_KDF_FS or AT_PUB_ECDHE is missing on reception,
          the Peer <bcp14>MUST</bcp14> treat it as if neither one was sent
          and assume that the extension defined in this document is not in
          use.</t>
          <t indent="0" pn="section-6.5.3-3">The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING,
          AT_NEXT_PSEUDONYM, AT_NEXT_REAUTH_ID, and other attributes may be
          included as specified in <xref target="RFC4187" sectionFormat="of" section="9.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4187#section-9.3" derivedContent="RFC4187"/>.</t>
          <t indent="0" pn="section-6.5.3-4">When processing this message, the Peer <bcp14>MUST</bcp14>
          process AT_RAND, AT_AUTN, AT_KDF_FS, and AT_PUB_ECDHE before
          processing other attributes. The Peer derives keys and verifies
          AT_MAC only if these attributes are verified to be valid.  If the
          Peer is unable or unwilling to perform the extension specified in
          this document, it proceeds as defined in <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>. Finally, if there is an error, see <xref target="RFC4187" sectionFormat="of" section="6.3.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4187#section-6.3.1" derivedContent="RFC4187"/>.</t>
        </section>
        <section anchor="procakachallresp" numbered="true" toc="include" removeInRFC="false" pn="section-6.5.4">
          <name slugifiedName="name-eap-response-aka-challenge">EAP-Response/AKA'-Challenge</name>
          <t indent="0" pn="section-6.5.4-1">The Peer sends an EAP-Response/AKA'-Challenge in response to a
      valid EAP-Request/AKA'-Challenge message, as specified by <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/> and <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>.
      If the Peer supports and is willing to perform the extension
      specified in this protocol, and the Server had made a valid
      request involving the attributes specified in <xref target="procakachall" format="default" sectionFormat="of" derivedContent="Section 6.5.3"/>, the Peer responds per the rules
      specified below. Otherwise, the Peer responds as specified in
      <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/> and <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/> and ignores the attributes
      related to this extension. If the Peer has not received
      attributes related to this extension from the Server, and has a
      policy that requires it to always use this extension, it behaves
      as if the AUTN were incorrect and fails the authentication.</t>
          <t indent="0" pn="section-6.5.4-2">The AT_MAC attribute <bcp14>MUST</bcp14> be included and checked as
      specified in <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>. In the
      EAP-Response/AKA'-Challenge, there is no message-specific data
      covered by the MAC. The AT_PUB_ECDHE attribute <bcp14>MUST</bcp14> be included
      and carries the Peer's public Diffie-Hellman key.</t>
          <t indent="0" pn="section-6.5.4-3">The AT_RES attribute <bcp14>MUST</bcp14> be included and checked as
      specified in <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/>.  When processing this
      message, the Server <bcp14>MUST</bcp14> process AT_RES before processing other
      attributes.  The Server derives keys and verifies AT_MAC only
      when this attribute is verified to be valid.</t>
          <t indent="0" pn="section-6.5.4-4">If the Server has proposed the use of the extension specified
      in this protocol, but the Peer ignores and continues the basic
      EAP-AKA' authentication, the Server makes a policy decision of
      whether this is allowed. If this is allowed, it continues the
      EAP-AKA' authentication to completion. If it is not allowed, the
      Server <bcp14>MUST</bcp14> behave as if authentication failed.</t>
          <t indent="0" pn="section-6.5.4-5">The AT_CHECKCODE, AT_RESULT_IND, AT_IV, AT_ENCR_DATA, and other
      attributes may be included as specified in <xref target="RFC4187" sectionFormat="of" section="9.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc4187#section-9.4" derivedContent="RFC4187"/>.</t>
        </section>
        <section anchor="reauth" numbered="true" toc="include" removeInRFC="false" pn="section-6.5.5">
          <name slugifiedName="name-eap-request-aka-reauthentic">EAP-Request/AKA'-Reauthentication</name>
          <t indent="0" pn="section-6.5.5-1">There are no changes for the EAP-Request/AKA'-Reauthentication, but note that the re-authentication process
      uses the keys generated in the original EAP-AKA' authentication,
      which employs key material from the Diffie-Hellman procedure if the extension specified in this document is in use.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.5.6">
          <name slugifiedName="name-eap-response-aka-reauthenti">EAP-Response/AKA'-Reauthentication</name>
          <t indent="0" pn="section-6.5.6-1">There are no changes for the EAP-Response/AKA'-Reauthentication,
          but as discussed in <xref target="reauth" format="default" sectionFormat="of" derivedContent="Section 6.5.5"/>,
          re-authentication is based on the key material generated by EAP-AKA'
          and the extension defined in this document.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.5.7">
          <name slugifiedName="name-eap-response-aka-synchroniz">EAP-Response/AKA'-Synchronization-Failure</name>
          <t indent="0" pn="section-6.5.7-1">There are no changes for the
          EAP-Response/AKA'-Synchronization-Failure, except that the AT_KDF_FS
          or AT_PUB_ECDHE attributes <bcp14>MUST NOT</bcp14> be added to this
          message.  The appearance of these attributes in a received message
          <bcp14>MUST</bcp14> be ignored.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.5.8">
          <name slugifiedName="name-eap-response-aka-authentica">EAP-Response/AKA'-Authentication-Reject</name>
          <t indent="0" pn="section-6.5.8-1">There are no changes for the
          EAP-Response/AKA'-Authentication-Reject, except that the AT_KDF_FS
          or AT_PUB_ECDHE attributes <bcp14>MUST NOT</bcp14> be added to this
          message.  The appearance of these attributes in a received message
          <bcp14>MUST</bcp14> be ignored.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.5.9">
          <name slugifiedName="name-eap-response-aka-client-err">EAP-Response/AKA'-Client-Error</name>
          <t indent="0" pn="section-6.5.9-1">There are no changes for the EAP-Response/AKA'-Client-Error,
          except that the AT_KDF_FS or AT_PUB_ECDHE attributes <bcp14>MUST NOT</bcp14> be added to this message.  The appearance of
          these attributes in a received message <bcp14>MUST</bcp14> be
          ignored.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.5.10">
          <name slugifiedName="name-eap-request-aka-notificatio">EAP-Request/AKA'-Notification</name>
          <t indent="0" pn="section-6.5.10-1">There are no changes for the EAP-Request/AKA'-Notification.</t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-6.5.11">
          <name slugifiedName="name-eap-response-aka-notificati">EAP-Response/AKA'-Notification</name>
          <t indent="0" pn="section-6.5.11-1">There are no changes for the EAP-Response/AKA'-Notification.</t>
        </section>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-7-1">This section deals only with changes to security considerations for
      EAP-AKA' or new information that has been gathered since the publication
      of <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>.</t>
      <t indent="0" pn="section-7-2">As discussed in <xref target="sec_intro" format="default" sectionFormat="of" derivedContent="Section 1"/>, FS is an important countermeasure against adversaries who gain
      access to long-term keys.  The long-term keys can be best protected
      with good processes, e.g., restricting access to the key material within
      a factory or among personnel, etc.  Even so, not all attacks can be
      entirely ruled out. For instance, well-resourced adversaries may be able
      to coerce insiders to collaborate, despite any technical protection
      measures.  The zero trust principles suggest that we assume that
      breaches are inevitable or have potentially already occurred and that
      we need to minimize the impact of these breaches (see <xref target="NSA-ZT" format="default" sectionFormat="of" derivedContent="NSA-ZT"/> and <xref target="NIST-ZT" format="default" sectionFormat="of" derivedContent="NIST-ZT"/>). One type
      of breach is key compromise or key exfiltration.</t>
      <t indent="0" pn="section-7-3">If a mechanism without ephemeral key exchange (such as 5G-AKA or
      EAP-AKA') is used, the effects of key compromise are devastating.  There
      are serious consequences to not properly providing FS for
      the key establishment, for the control plane and the user plane, and for
      both directions:
      </t>
      <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-7-4"><li pn="section-7-4.1" derivedCounter="1.">
          <t indent="0" pn="section-7-4.1.1">An attacker can decrypt 5G communication that they
     previously recorded.</t>
        </li>
        <li pn="section-7-4.2" derivedCounter="2.">
          <t indent="0" pn="section-7-4.2.1">A passive attacker can eavesdrop (decrypt) all
     future 5G communication.</t>
        </li>
        <li pn="section-7-4.3" derivedCounter="3.">
          <t indent="0" pn="section-7-4.3.1">An active attacker can impersonate the User Equipment (UE) or the
    network and inject messages in an ongoing 5G connection between
    the real UE and the real network.</t>
        </li>
      </ol>
      <t indent="0" pn="section-7-5">At the time of writing, best practice security is to mandate FS (as is
      done in Wi-Fi Protected Access 3 (WPA3), EAP-TLS 1.3, EAP-TTLS 1.3,
      Internet Key Exchange Protocol Version 2 (IKEv2), Secure Shell (SSH),
      QUIC, WireGuard, Signal, etc.). In deployments, it is recommended that
      EAP-AKA methods without FS be phased out in the long
      term.</t>
      <t indent="0" pn="section-7-6">The FS extension provides assistance against passive attacks from
      attackers that have compromised the key material on USIM cards.  Passive
      attacks are attractive for attackers performing large-scale pervasive
      monitoring as they require far fewer resources and are much harder to
      detect. The extension also provides protection against active attacks as
      the attacker is forced to be on-path during the AKA run and subsequent
      communication between the parties. Without FS, an active attacker that
      has compromised the long-term key can inject messages in a connection
      between the real Peer and the real Server without being on-path. This
      extension is most useful when implemented in a context where the MSK or
      EMSK are used in protocols not providing FS. For instance, if used with
      IKEv2 <xref target="RFC7296" format="default" sectionFormat="of" derivedContent="RFC7296"/>, the session keys
      produced by IKEv2 will in any case have this property, so the
      improvements from the use of EAP-AKA' FS are not that useful. However,
      typical link-layer usage of EAP does not involve running another key exchange with forward secrecy. Therefore, using EAP to authenticate
      access to a network is one situation where the extension defined in this
      document can be helpful.</t>
      <t indent="0" pn="section-7-7">The FS extension generates key material using the ECDHE
    exchange in order to gain the FS property. This means that once
    an EAP-AKA' authentication run ends, the session that it was used
    to protect is closed, and the corresponding keys are destroyed. Even someone who has recorded all of the data from the
    authentication run and session and gets access to all of the AKA
    long-term keys cannot reconstruct the keys used to protect the
    session or any previous session, without doing a brute-force
    search of the session key space.</t>
      <t indent="0" pn="section-7-8">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 indent="0" pn="section-7-9">The extension does not provide protection against active attackers that
    mount an on-path attack on future EAP-AKA' runs and have access to the
    long-term key. They will be able to eavesdrop on the traffic protected by
    the resulting session key(s).  Still, past sessions where FS was in use
    remain protected.</t>
      <t indent="0" pn="section-7-10">Using EAP-AKA' FS once provides FS. FS limits the effect of key leakage
    in one direction (compromise of a key at time T2 does not compromise some
    key at time T1 where T1 &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" format="default" sectionFormat="of" derivedContent="RFC7624"/>, FS without rerunning ECDHE does not stop an attacker
    from doing static key exfiltration. Frequently rerunning EC(DHE) forces an
    attacker to do dynamic key exfiltration (or content exfiltration).</t>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-deployment-considerations">Deployment Considerations</name>
        <t indent="0" pn="section-7.1-1">Achieving FS requires that, when a connection is closed, each
    endpoint <bcp14>MUST</bcp14> destroy not only the ephemeral keys used by the
    connection but also any information that could be used to
    recompute those keys.</t>
        <t indent="0" pn="section-7.1-2">Similarly, other parts of the system matter. For instance, when the keys generated by EAP are transported to a
         pass-through authenticator, such transport must also provide forward secure encryption with respect to the long-term keys used to establish
         its security. Otherwise, an adversary may attack the transport connection
	 used to carry keys from EAP, and use this method to gain access to current and past
	keys from EAP, which, in turn, would lead to the compromise of anything protected by those EAP keys.</t>
        <t indent="0" pn="section-7.1-3">Of course, these considerations
         apply to any EAP method, not only this one.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.2">
        <name slugifiedName="name-security-properties">Security Properties</name>
        <t indent="0" pn="section-7.2-1">The following security properties of
    EAP-AKA' are impacted through this extension:</t>
        <dl newline="true" spacing="normal" indent="3" pn="section-7.2-2">
          <dt pn="section-7.2-2.1">Protected ciphersuite negotiation:</dt>
          <dd pn="section-7.2-2.2">
            <t indent="0" pn="section-7.2-2.2.1">EAP-AKA' has a negotiation mechanism for selecting the KDFs, and this mechanism has been extended by the
            extension specified in this document.  The resulting mechanism
            continues to be secure against bidding-down attacks.</t>
            <t indent="0" pn="section-7.2-2.2.2">There are two specific needs in the negotiation mechanism:</t>
            <dl newline="true" spacing="normal" indent="3" pn="section-7.2-2.2.3">
              <dt pn="section-7.2-2.2.3.1">Negotiating KDFs within the extension:</dt>
              <dd pn="section-7.2-2.2.3.2">
        The negotiation mechanism allows changing the offered KDF, but the change is visible in the final
        EAP-Request/AKA'-Challenge message that the Server sends to the Peer.
        This message is authenticated via the AT_MAC attribute, and carries
        both the chosen alternative and the initially offered list.  The Peer
        refuses to accept a change it did not initiate.  As a result, both
        parties are aware that a change is being made and what the original
        offer was.</dd>
              <dt pn="section-7.2-2.2.3.3">Negotiating the use of this extension:</dt>
              <dd pn="section-7.2-2.2.3.4">
                <t indent="0" pn="section-7.2-2.2.3.4.1"> This extension is offered by the Server through presenting
                the AT_KDF_FS and AT_PUB_ECDHE attributes in the
                EAP-Request/AKA'-Challenge message. These attributes are
                protected by AT_MAC, so attempts to change or omit them by an
                adversary will be detected.</t>
                <t indent="0" pn="section-7.2-2.2.3.4.2">These attempts will be detected, except of course, if the
		adversary holds the long-term key and is willing to engage in
		an active attack.  For instance, such an attack can forge the negotiation
		process so that no FS will be provided. However, as noted
		above, an attacker with these capabilities will, in any case,
		be able to impersonate any party in the protocol and perform
		on-path attacks. That is not a situation that can be improved
		by a technical solution. However, as discussed in the
		Introduction, even an attacker with access to the long-term
		keys is required to be on-path on each AKA run and subsequent
		communication, which makes mass surveillance more laborious.
                </t>
                <t indent="0" pn="section-7.2-2.2.3.4.3">
		  The security properties of the extension also depend on a
		  policy choice. As discussed in <xref target="procakachallresp" format="default" sectionFormat="of" derivedContent="Section 6.5.4"/>, both the Peer
		  and the Server make a policy decision of what to do when it
		  was willing to perform the extension specified in this
		  protocol, but the other side does not wish to use the
		  extension. Allowing this has the benefit of allowing
		  backwards compatibility to equipment that did not yet
		  support the extension. When the extension is not supported
		  or negotiated by the parties, no FS can obviously be
		  provided.
                </t>
                <t indent="0" pn="section-7.2-2.2.3.4.4">
		  If turning off the extension specified in this protocol is
		  not allowed by policy, the use of legacy equipment that does
		  not support this protocol is no longer possible. This may be
		  appropriate when, for instance, support for the extension is
		  sufficiently widespread or required in a particular version
		  of a mobile network.
                </t>
              </dd>
            </dl>
          </dd>
          <dt pn="section-7.2-2.3">Key derivation:</dt>
          <dd pn="section-7.2-2.4">This extension provides FS.  As described in several places in
          this specification, this can be roughly summarized as follows: an
          attacker with access to long-term keys is unable to obtain session
          keys of ended past sessions, assuming these sessions deleted all
          relevant session key material.  This extension does not change the
          properties related to re-authentication. No new Diffie-Hellman run
          is performed during the re-authentication allowed by
          EAP-AKA'. However, if this extension was in use when the original
          EAP-AKA' authentication was performed, the keys used for
          re-authentication (K_re) are based on the Diffie-Hellman keys;
          hence, they continue to be equally safe against exposure of the
          long-term key as the original authentication.</dd>
        </dl>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.3">
        <name slugifiedName="name-denial-of-service">Denial of Service</name>
        <t indent="0" pn="section-7.3-1">It is worthwhile to discuss Denial-of-Service (DoS) attacks and
        their impact on this protocol. The calculations involved in public key
        cryptography require computing power, which could be used in an attack
        to overpower either the Peer or the Server. While some forms of DoS
        attacks are always possible, the following factors help mitigate the
        concerns relating to public key cryptography and EAP-AKA' FS.

        </t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-7.3-2">
          <li pn="section-7.3-2.1">
            <t indent="0" pn="section-7.3-2.1.1">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 pn="section-7.3-2.2">
            <t indent="0" pn="section-7.3-2.2.1">This specification is constructed so that it is possible to
	    have a separation between the USIM and Peer on the client side and
	    between the Server and AD on the network side. This ensures that
	    the most sensitive (or legacy) system components cannot be the
	    target of the attack. For instance, EAP-AKA' and public key
	    cryptography both take place in the phone and not the low-power
	    USIM card.</t>
          </li>
          <li pn="section-7.3-2.3">
            <t indent="0" pn="section-7.3-2.3.1">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 pn="section-7.3-2.4">
            <t indent="0" pn="section-7.3-2.4.1">Finally, this memo specifies an order in which computations and
    checks must occur. For instance, when processing the EAP-Request/AKA'-Challenge
    message, the AKA authentication must be checked and
    succeed before the Peer proceeds to calculating or processing the
    FS-related parameters (see <xref target="procakachallresp" format="default" sectionFormat="of" derivedContent="Section 6.5.4"/>). The same is true of an
    EAP-Response/AKA'-Challenge (see <xref target="procakachallresp" format="default" sectionFormat="of" derivedContent="Section 6.5.4"/>). This ensures that the parties need to
    show possession of the long-term key in some way, and only then
    will the FS calculations become active. This limits the
    DoS to specific, identified subscribers. While
    botnets and other forms of malicious parties could take advantage
    of actual subscribers and their key material, at least such
    attacks are:</t>
            <ol type="a" indent="adaptive" spacing="normal" start="1" pn="section-7.3-2.4.2"><li pn="section-7.3-2.4.2.1" derivedCounter="a.">limited in terms of subscribers they control, and</li>
              <li pn="section-7.3-2.4.2.2" derivedCounter="b.">identifiable for the purposes of blocking the affected
    subscribers.</li>
            </ol>
          </li>
        </ul>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.4">
        <name slugifiedName="name-identity-privacy">Identity Privacy</name>
        <t indent="0" pn="section-7.4-1">As specified in <xref target="secMessageProc" format="default" sectionFormat="of" derivedContent="Section 6.5"/>, the Peer identity sent
       in the Identity Response message needs
       to follow the privacy-friendly requirements in <xref target="RFC9190" format="default" sectionFormat="of" derivedContent="RFC9190"/>.</t>
      </section>
      <section anchor="unp" numbered="true" toc="include" removeInRFC="false" pn="section-7.5">
        <name slugifiedName="name-unprotected-data-and-privac">Unprotected Data and Privacy</name>
        <t indent="0" pn="section-7.5-1">Unprotected data and metadata can reveal sensitive information and need to be selected with care.
   In particular, this applies to
   AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF_FS, and
   AT_PUB_ECDHE reveal the used cryptographic algorithms; if these depend on the
   Peer identity, they leak information about the Peer. AT_KDF_INPUT reveals the
   network name, although that is done on purpose to bind the authentication to a particular context.</t>
        <t indent="0" pn="section-7.5-2">An attacker observing network traffic may use the above types of information
   for traffic flow analysis or to track an endpoint.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.6">
        <name slugifiedName="name-forward-secrecy-within-at_e">Forward Secrecy within AT_ENCR</name>
        <t indent="0" pn="section-7.6-1">The keys K_encr and K_aut are calculated and used before the shared secret from the ephemeral 
     key exchange is available.</t>
        <t indent="0" pn="section-7.6-2">K_encr and K_aut are used to encrypt and calculate a MAC in the
        EAP-Req/AKA'-Challenge message, especially the DH g<sup>x</sup>
        ephemeral pub key. At that point, the Server does not yet have the
        corresponding g<sup>y</sup> from the Peer and cannot compute the
        shared secret. K_aut is then used as the authentication key for the
        shared secret.</t>
        <t indent="0" pn="section-7.6-3">However, for K_encr, none of the encrypted data sent in the
        EAP-Req/AKA'-Challenge message in the AT_ENCR attribute will be a
        forward secret. That data may include re-authentication pseudonyms, so
        an adversary compromising the long-term key would be able to link
        re-authentication protocol runs when pseudonyms are used, within a
        sequence of runs followed after a full EAP-AKA' authentication. No
        such linking would be possible across different full authentication
        runs. If the pseudonym linkage risk is not acceptable, one way to
        avoid the linkage is to always require full EAP-AKA'
        authentication.</t>
      </section>
      <section numbered="true" toc="include" removeInRFC="false" pn="section-7.7">
        <name slugifiedName="name-post-quantum-considerations">Post-Quantum Considerations</name>
        <t indent="0" pn="section-7.7-1">As of the publication of this document, it is unclear when or even
        if a quantum computer of sufficient size and power to exploit ECC will exist.  Deployments that need to consider
        risks decades into the future should transition to Post-Quantum Cryptography (PQC) in the not-too-distant future.  Other systems may
        employ PQC when the quantum threat is more imminent. Current PQC
        algorithms have limitations compared to ECC, and the data sizes could be problematic for some constrained
        systems. If a Cryptographically Relevant Quantum Computer (CRQC) is
        built, it could recover the SHARED_SECRET from the ECDHE public
        keys.</t>
        <t indent="0" pn="section-7.7-2">However, this would not affect the ability of EAP-AKA', with or
        without this extension, to authenticate properly. As symmetric key
        cryptography is safe even if CRQCs are built, an adversary still will
        not be able to disrupt authentication as it requires computing a
        correct AT_MAC value. This computation requires the K_aut key, which is
        based on the MK, CK', and IK', but not SHARED_SECRET.</t>
        <t indent="0" pn="section-7.7-3">Other output keys do include SHARED_SECRET via MK_ECDHE, but they still include the CK' and IK', which are entirely based on symmetric cryptography. As a result,
	an adversary with a quantum computer still cannot compute the other output keys either.</t>
        <t indent="0" pn="section-7.7-4">However, if the adversary has also obtained knowledge of the long-term key, they
   could then compute the CK', IK', SHARED_SECRET, and any derived output keys. This means that
   the introduction of a powerful enough quantum computer would disable
   this protocol extension's ability to provide the forward secrecy
   capability. This would 
   make it necessary to update the current ECC algorithms in this document to PQC algorithms. This
   document does not add such algorithms, but a future update can do that.
        </t>
        <t indent="0" pn="section-7.7-5">Symmetric algorithms used in EAP-AKA' FS, such as HMAC-SHA-256 and
        the algorithms used to generate AT_AUTN and AT_RES, are practically
        secure against even large, robust quantum computers. EAP-AKA' FS is
        currently only specified for use with ECDHE key exchange algorithms,
        but use of any Key Encapsulation Method (KEM), including PQC KEMs, can
        be specified in the future. While the key exchange is specified with
        terms of the Diffie-Hellman protocol, the key exchange adheres to a
        KEM interface. AT_PUB_ECDHE would then contain either the ephemeral
        public key of the Server or the SHARED_SECRET encapsulated with the
        Server's public key. Note that the use of a KEM might require other
        changes, such as including the ephemeral public key of the Server in
        the key derivation to retain the property that both parties contribute
        randomness to the session key.
        </t>
      </section>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-8-1">This extension of EAP-AKA' shares its attribute space and subtypes
      with the following:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-8-2">
        <li pn="section-8-2.1">"Extensible Authentication Protocol Method for Global System for
      Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)" <xref target="RFC4186" format="default" sectionFormat="of" derivedContent="RFC4186"/>,</li>
        <li pn="section-8-2.2">"Extensible Authentication Protocol
      Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)"
      <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/>, and</li>
        <li pn="section-8-2.3">"Improved Extensible
      Authentication Protocol Method for 3GPP Mobile Network Authentication
      and Key Agreement (EAP-AKA')" <xref target="RFC9048" format="default" sectionFormat="of" derivedContent="RFC9048"/>.</li>
      </ul>
      <t indent="0" pn="section-8-3">IANA has assigned two new values in the "Attribute Types (Skippable
  Attributes 128-255)" registry under the "EAP-AKA and EAP-SIM Parameters"
  group as follows:</t>
      <dl indent="3" newline="false" spacing="normal" pn="section-8-4">
        <dt pn="section-8-4.1">152:</dt>
        <dd pn="section-8-4.2">AT_PUB_ECDHE (<xref target="at_pub_dh" format="default" sectionFormat="of" derivedContent="Section 6.1"/>)</dd>
        <dt pn="section-8-4.3">153:</dt>
        <dd pn="section-8-4.4">AT_KDF_FS (<xref target="at_kdf_dh" format="default" sectionFormat="of" derivedContent="Section 6.2"/>)</dd>
      </dl>
      <t indent="0" pn="section-8-5">IANA has also created the "EAP-AKA' AT_KDF_FS
      Key Derivation Function Values" registry to represent FS KDF
      types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA' with ECDHE and
      P-256" types (1 and 2, see <xref target="kdf2" format="default" sectionFormat="of" derivedContent="Section 6.3"/>) have been assigned, along with one reserved value. The initial contents of
      this registry are illustrated in <xref target="iana-fs-values" format="default" sectionFormat="of" derivedContent="Table 1"/>; new values can be created through the Specification
      Required policy <xref target="RFC8126" format="default" sectionFormat="of" derivedContent="RFC8126"/>.  Expert
      reviewers should ensure that the referenced specification is clearly
      identified and stable and that the proposed addition is reasonable for
      the given category of allocation.
      </t>
      <table anchor="iana-fs-values" align="center" pn="table-1">
        <name slugifiedName="name-eap-aka-at_kdf_fs-key-deriv">EAP-AKA' AT_KDF_FS Key Derivation Function Values Registry Initial Contents</name>
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Value</th>
            <th align="left" colspan="1" rowspan="1">Description</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">0</td>
            <td align="left" colspan="1" rowspan="1">Reserved</td>
            <td align="left" colspan="1" rowspan="1">RFC 9678</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">1</td>
            <td align="left" colspan="1" rowspan="1">EAP-AKA' with ECDHE and X25519</td>
            <td align="left" colspan="1" rowspan="1">RFC 9678</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">2</td>
            <td align="left" colspan="1" rowspan="1">EAP-AKA' with ECDHE and P-256</td>
            <td align="left" colspan="1" rowspan="1">RFC 9678</td>
          </tr>
          <tr>
            <td align="left" colspan="1" rowspan="1">3-65535</td>
            <td align="left" colspan="1" rowspan="1">Unassigned</td>
            <td align="left" colspan="1" rowspan="1">RFC 9678</td>
          </tr>
        </tbody>
      </table>
    </section>
  </middle>
  <back>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC3748" target="https://www.rfc-editor.org/info/rfc3748" quoteTitle="true" derivedAnchor="RFC3748">
          <front>
            <title>Extensible Authentication Protocol (EAP)</title>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <author fullname="L. Blunk" initials="L." surname="Blunk"/>
            <author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht"/>
            <author fullname="J. Carlson" initials="J." surname="Carlson"/>
            <author fullname="H. Levkowetz" initials="H." role="editor" surname="Levkowetz"/>
            <date month="June" year="2004"/>
            <abstract>
              <t indent="0">This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3748"/>
          <seriesInfo name="DOI" value="10.17487/RFC3748"/>
        </reference>
        <reference anchor="RFC4187" target="https://www.rfc-editor.org/info/rfc4187" quoteTitle="true" derivedAnchor="RFC4187">
          <front>
            <title>Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA)</title>
            <author fullname="J. Arkko" initials="J." surname="Arkko"/>
            <author fullname="H. Haverinen" initials="H." surname="Haverinen"/>
            <date month="January" year="2006"/>
            <abstract>
              <t indent="0">This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution that uses the Authentication and Key Agreement (AKA) mechanism. AKA is used in the 3rd generation mobile networks Universal Mobile Telecommunications System (UMTS) and CDMA2000. AKA is based on symmetric keys, and typically runs in a Subscriber Identity Module, which is a UMTS Subscriber Identity Module, USIM, or a (Removable) User Identity Module, (R)UIM, similar to a smart card.</t>
              <t indent="0">EAP-AKA includes optional identity privacy support, optional result indications, and an optional fast re-authentication procedure. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4187"/>
          <seriesInfo name="DOI" value="10.17487/RFC4187"/>
        </reference>
        <reference anchor="RFC5448" target="https://www.rfc-editor.org/info/rfc5448" quoteTitle="true" derivedAnchor="RFC5448">
          <front>
            <title>Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')</title>
            <author fullname="J. Arkko" initials="J." surname="Arkko"/>
            <author fullname="V. Lehtovirta" initials="V." surname="Lehtovirta"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <date month="May" year="2009"/>
            <abstract>
              <t indent="0">This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.</t>
              <t indent="0">This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5448"/>
          <seriesInfo name="DOI" value="10.17487/RFC5448"/>
        </reference>
        <reference anchor="RFC7624" target="https://www.rfc-editor.org/info/rfc7624" quoteTitle="true" derivedAnchor="RFC7624">
          <front>
            <title>Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement</title>
            <author fullname="R. Barnes" initials="R." surname="Barnes"/>
            <author fullname="B. Schneier" initials="B." surname="Schneier"/>
            <author fullname="C. Jennings" initials="C." surname="Jennings"/>
            <author fullname="T. Hardie" initials="T." surname="Hardie"/>
            <author fullname="B. Trammell" initials="B." surname="Trammell"/>
            <author fullname="C. Huitema" initials="C." surname="Huitema"/>
            <author fullname="D. Borkmann" initials="D." surname="Borkmann"/>
            <date month="August" year="2015"/>
            <abstract>
              <t indent="0">Since the initial revelations of pervasive surveillance in 2013, several classes of attacks on Internet communications have been discovered. In this document, we develop a threat model that describes these attacks on Internet confidentiality. We assume an attacker that is interested in undetected, indiscriminate eavesdropping. The threat model is based on published, verified attacks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7624"/>
          <seriesInfo name="DOI" value="10.17487/RFC7624"/>
        </reference>
        <reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748" quoteTitle="true" derivedAnchor="RFC7748">
          <front>
            <title>Elliptic Curves for Security</title>
            <author fullname="A. Langley" initials="A." surname="Langley"/>
            <author fullname="M. Hamburg" initials="M." surname="Hamburg"/>
            <author fullname="S. Turner" initials="S." surname="Turner"/>
            <date month="January" year="2016"/>
            <abstract>
              <t indent="0">This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7748"/>
          <seriesInfo name="DOI" value="10.17487/RFC7748"/>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126" quoteTitle="true" derivedAnchor="RFC8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <author fullname="M. Cotton" initials="M." surname="Cotton"/>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="June" year="2017"/>
            <abstract>
              <t indent="0">Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t indent="0">To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t indent="0">This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="26"/>
          <seriesInfo name="RFC" value="8126"/>
          <seriesInfo name="DOI" value="10.17487/RFC8126"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC9048" target="https://www.rfc-editor.org/info/rfc9048" quoteTitle="true" derivedAnchor="RFC9048">
          <front>
            <title>Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA')</title>
            <author fullname="J. Arkko" initials="J." surname="Arkko"/>
            <author fullname="V. Lehtovirta" initials="V." surname="Lehtovirta"/>
            <author fullname="V. Torvinen" initials="V." surname="Torvinen"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <date month="October" year="2021"/>
            <abstract>
              <t indent="0">The 3GPP mobile network Authentication and Key Agreement (AKA) is an authentication mechanism for devices wishing to access mobile networks. RFC 4187 (EAP-AKA) made the use of this mechanism possible within the Extensible Authentication Protocol (EAP) framework. RFC 5448 (EAP-AKA') was an improved version of EAP-AKA.</t>
              <t indent="0">This document is the most recent specification of EAP-AKA', including, for instance, details about and references related to operating EAP-AKA' in 5G networks.</t>
              <t indent="0">EAP-AKA' differs from EAP-AKA by providing a key derivation function that binds the keys derived within the method to the name of the access network. The key derivation function has been defined in the 3rd Generation Partnership Project (3GPP). EAP-AKA' allows its use in EAP in an interoperable manner. EAP-AKA' also updates the algorithm used in hash functions, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-SHA-1, which is used in EAP-AKA.</t>
              <t indent="0">This version of the EAP-AKA' specification defines the protocol behavior for both 4G and 5G deployments, whereas the previous version defined protocol behavior for 4G deployments only. While EAP-AKA' as defined in RFC 5448 is not obsolete, this document defines the most recent and fully backwards-compatible specification of EAP-AKA'. This document updates both RFCs 4187 and 5448.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9048"/>
          <seriesInfo name="DOI" value="10.17487/RFC9048"/>
        </reference>
        <reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf" quoteTitle="true" derivedAnchor="SEC1">
          <front>
            <title>SEC 1: Elliptic Curve Cryptography</title>
            <author>
              <organization showOnFrontPage="true">Standards for Efficient Cryptography</organization>
            </author>
            <date month="May" year="2009"/>
          </front>
          <refcontent>Version 2.0</refcontent>
        </reference>
        <reference anchor="SEC2" target="https://www.secg.org/sec2-v2.pdf" quoteTitle="true" derivedAnchor="SEC2">
          <front>
            <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title>
            <author>
              <organization showOnFrontPage="true">Standards for Efficient Cryptography</organization>
            </author>
            <date month="January" year="2010"/>
          </front>
          <refcontent>Version 2.0</refcontent>
        </reference>
        <reference anchor="SP-800-186" target="https://doi.org/10.6028/NIST.SP.800-186" quoteTitle="true" derivedAnchor="SP-800-186">
          <front>
            <title>Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters</title>
            <author initials="L." surname="Chen">
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <author initials="D." surname="Moody"/>
            <author initials="K." surname="Randall"/>
            <author initials="A." surname="Regenscheid"/>
            <author initials="A." surname="Robinson"/>
            <date month="February" year="2023"/>
          </front>
          <seriesInfo name="NIST" value="SP 800-186"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-186"/>
        </reference>
        <reference anchor="SP-800-56A" target="https://doi.org/10.6028/NIST.SP.800-56Ar3" quoteTitle="true" derivedAnchor="SP-800-56A">
          <front>
            <title>Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography</title>
            <author initials="E." surname="Barker">
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <author initials="L." surname="Chen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Roginsky">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Vassilev">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Davis">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2018" month="April"/>
          </front>
          <seriesInfo name="NIST" value="SP 800-56A"/>
          <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="DOW1992" target="https://doi.org/10.1007/BF00124891" quoteTitle="true" derivedAnchor="DOW1992">
          <front>
            <title>Authentication and authenticated key exchanges</title>
            <author initials="W." surname="Diffie"/>
            <author initials="P. C." surname="Van Oorschot"/>
            <author initials="M. J." surname="Wiener"/>
            <date month="June" year="1992"/>
          </front>
          <refcontent>Designs, Codes and Cryptography, vol. 2, pp. 107-125</refcontent>
          <seriesInfo name="DOI" value="10.1007/BF00124891"/>
        </reference>
        <reference anchor="Heist2015" target="https://theintercept.com/2015/02/19/great-sim-heist/" quoteTitle="true" derivedAnchor="Heist2015">
          <front>
            <title>The Great SIM Heist</title>
            <author initials="J." surname="Scahill"/>
            <author initials="J." surname="Begley"/>
            <date month="February" year="2015"/>
          </front>
        </reference>
        <reference anchor="NIST-ZT" target="https://www.nccoe.nist.gov/sites/default/files/2024-07/zta-nist-sp-1800-35-preliminary-draft-4.pdf" quoteTitle="true" derivedAnchor="NIST-ZT">
          <front>
            <title>Implementing a Zero Trust Architecture</title>
            <author>
              <organization showOnFrontPage="true">National Institute of Standards and Technology</organization>
            </author>
            <date year="2024" month="July"/>
          </front>
          <seriesInfo name="NIST" value="SP 1800-35"/>
        </reference>
        <reference anchor="NSA-ZT" target="https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF" quoteTitle="true" derivedAnchor="NSA-ZT">
          <front>
            <title>Embracing a Zero Trust Security Model</title>
            <author>
              <organization showOnFrontPage="true">National Security Agency</organization>
            </author>
            <date year="2021" month="February"/>
          </front>
        </reference>
        <reference anchor="RFC4186" target="https://www.rfc-editor.org/info/rfc4186" quoteTitle="true" derivedAnchor="RFC4186">
          <front>
            <title>Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)</title>
            <author fullname="H. Haverinen" initials="H." role="editor" surname="Haverinen"/>
            <author fullname="J. Salowey" initials="J." role="editor" surname="Salowey"/>
            <date month="January" year="2006"/>
            <abstract>
              <t indent="0">This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4186"/>
          <seriesInfo name="DOI" value="10.17487/RFC4186"/>
        </reference>
        <reference anchor="RFC5216" target="https://www.rfc-editor.org/info/rfc5216" quoteTitle="true" derivedAnchor="RFC5216">
          <front>
            <title>The EAP-TLS Authentication Protocol</title>
            <author fullname="D. Simon" initials="D." surname="Simon"/>
            <author fullname="B. Aboba" initials="B." surname="Aboba"/>
            <author fullname="R. Hurst" initials="R." surname="Hurst"/>
            <date month="March" year="2008"/>
            <abstract>
              <t indent="0">The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides support for multiple authentication methods. Transport Layer Security (TLS) provides for mutual authentication, integrity-protected ciphersuite negotiation, and key exchange between two endpoints. This document defines EAP-TLS, which includes support for certificate-based mutual authentication and key derivation.</t>
              <t indent="0">This document obsoletes RFC 2716. A summary of the changes between this document and RFC 2716 is available in Appendix A. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5216"/>
          <seriesInfo name="DOI" value="10.17487/RFC5216"/>
        </reference>
        <reference anchor="RFC7258" target="https://www.rfc-editor.org/info/rfc7258" quoteTitle="true" derivedAnchor="RFC7258">
          <front>
            <title>Pervasive Monitoring Is an Attack</title>
            <author fullname="S. Farrell" initials="S." surname="Farrell"/>
            <author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/>
            <date month="May" year="2014"/>
            <abstract>
              <t indent="0">Pervasive monitoring is a technical attack that should be mitigated in the design of IETF protocols, where possible.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="188"/>
          <seriesInfo name="RFC" value="7258"/>
          <seriesInfo name="DOI" value="10.17487/RFC7258"/>
        </reference>
        <reference anchor="RFC7296" target="https://www.rfc-editor.org/info/rfc7296" quoteTitle="true" derivedAnchor="RFC7296">
          <front>
            <title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
            <author fullname="C. Kaufman" initials="C." surname="Kaufman"/>
            <author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
            <author fullname="Y. Nir" initials="Y." surname="Nir"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <author fullname="T. Kivinen" initials="T." surname="Kivinen"/>
            <date month="October" year="2014"/>
            <abstract>
              <t indent="0">This document describes version 2 of the Internet Key Exchange (IKE) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs). This document obsoletes RFC 5996, and includes all of the errata for it. It advances IKEv2 to be an Internet Standard.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="79"/>
          <seriesInfo name="RFC" value="7296"/>
          <seriesInfo name="DOI" value="10.17487/RFC7296"/>
        </reference>
        <reference anchor="RFC9190" target="https://www.rfc-editor.org/info/rfc9190" quoteTitle="true" derivedAnchor="RFC9190">
          <front>
            <title>EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3</title>
            <author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Mattsson"/>
            <author fullname="M. Sethi" initials="M." surname="Sethi"/>
            <date month="February" year="2022"/>
            <abstract>
              <t indent="0">The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9190"/>
          <seriesInfo name="DOI" value="10.17487/RFC9190"/>
        </reference>
        <reference anchor="TrustCom2015" target="https://doi.org/10.1109/Trustcom.2015.506" quoteTitle="true" derivedAnchor="TrustCom2015">
          <front>
            <title>A USIM Compatible 5G AKA Protocol with Perfect Forward Secrecy</title>
            <author initials="J." surname="Arkko"/>
            <author initials="K." surname="Norrman"/>
            <author initials="M." surname="Näslund"/>
            <author initials="B." surname="Sahlin"/>
            <date month="August" year="2015"/>
          </front>
          <refcontent>IEEE International Conference on Trust, Security and
	  Privacy in Computing and Communications (TrustCom)</refcontent>
          <seriesInfo name="DOI" value="10.1109/Trustcom.2015.506"/>
        </reference>
        <reference anchor="TS.33.501" quoteTitle="true" derivedAnchor="TS.33.501">
          <front>
            <title>Security architecture and procedures for 5G System</title>
            <author>
              <organization showOnFrontPage="true">3GPP</organization>
            </author>
            <date month="September" year="2024"/>
          </front>
          <seriesInfo name="3GPP TS" value="33.501"/>
          <refcontent>Version 19.0.0</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgments">Acknowledgments</name>
      <t indent="0" pn="section-appendix.a-1">The authors would like to note that the technical solution in this
      document came out of the TrustCom paper <xref target="TrustCom2015" format="default" sectionFormat="of" derivedContent="TrustCom2015"/>, whose authors were <contact fullname="J. Arkko"/>,
      <contact fullname="K. Norrman"/>, <contact fullname="M. Näslund"/>, and
      <contact fullname="B. Sahlin"/>. This document also uses a lot of
      material from <xref target="RFC4187" format="default" sectionFormat="of" derivedContent="RFC4187"/> by <contact fullname="J. Arkko"/> and <contact fullname="H. Haverinen"/>, as well as
      <xref target="RFC5448" format="default" sectionFormat="of" derivedContent="RFC5448"/> by <contact fullname="J. Arkko"/>, <contact fullname="V. Lehtovirta"/>, and <contact fullname="P. Eronen"/>.</t>
      <t indent="0" pn="section-appendix.a-2">The authors would also like to thank <contact fullname="Ben       Campbell"/>, <contact fullname="Meiling Chen"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Linda Dunbar"/>, <contact fullname="Tim Evans"/>, <contact fullname="Zhang Fu"/>, <contact fullname="Russ Housley"/>, <contact fullname="Tero Kivinen"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Warren Kumari"/>,
      <contact fullname="Eliot Lear"/>, <contact fullname="Vesa Lehtovirta"/>,
      <contact fullname="Kathleen Moriarty"/>, <contact fullname="Prajwol       Kumar Nakarmi"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Anand R. Prasad"/>, <contact fullname="Michael Richardson"/>,
      <contact fullname="Göran Rune"/>, <contact fullname="Bengt Sahlin"/>,
      <contact fullname="Joseph Salowey"/>, <contact fullname="Mohit Sethi"/>,
      <contact fullname="Orie Steele"/>, <contact fullname="Rene Struik"/>,
      <contact fullname="Vesa Torvinen"/>, <contact fullname="Sean Turner"/>,
      <contact fullname="Helena Vahidi Mazinani"/>, <contact fullname="Robert       Wilton"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Bo       Wu"/>, <contact fullname="Peter Yee"/>, and many other people at the
      IETF, GSMA, and 3GPP groups for interesting discussions in this problem
      space.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="J." surname="Arkko" fullname="Jari Arkko">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <postal>
            <city>Jorvas</city>
            <code>02420</code>
            <country>Finland</country>
          </postal>
          <email>jari.arkko@piuha.net</email>
        </address>
      </author>
      <author initials="K." surname="Norrman" fullname="Karl Norrman">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <postal>
            <city>Stockholm</city>
            <code>16483</code>
            <country>Sweden</country>
          </postal>
          <email>karl.norrman@ericsson.com</email>
        </address>
      </author>
      <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson">
        <organization showOnFrontPage="true">Ericsson</organization>
        <address>
          <postal>
            <city>Kista</city>
            <code>164 40</code>
            <country>Sweden</country>
          </postal>
          <email>john.mattsson@ericsson.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
