<?xmlversion="1.0" encoding="utf-8" ?>version='1.0' encoding='UTF-8'?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd">[ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-emu-aka-pfs-12" number="9678" category="std" updates="5448,9048"consensus="true"> <?rfc toc="yes"?> <?rfc symrefs="yes"?> <?rfc autobreaks="yes"?> <?rfc tocindent="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?>consensus="true" obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <front> <title abbrev="EAP-AKA' FS">Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' FS)</title> <!-- [rfced] We had a few questions about the title of this document, mostly as relates to the expansion of the initialism EAP-AKA'. We would love some guidance that we can track for future documents using this abbreviation as it looks like this has not been consistent thus far. a) We believe the single quote following the abbreviation is used to indicate the "improved" method described in RFC 5448 (as opposed to basic EAP-AKA from RFC 4187). If this is so, should "improved" be added to the title of this document? b) We see past expansions of both EAP-AKA and EAP-AKA' in RFC titles include 3rd Generation or 3GPP Mobile Network. Should some mention of 3rd generation be added to the title of this document? RFC 4187: Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) RFC 5448: Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') RFC 9048: Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA') c) If the title is really a 1:1 with the initialism, it may be beneficial for the reader to move the initialism to the front followed by a colon (common use in RFCs) (see Perhaps A below). With *all* the above in mind (a-c), here are some suggested titles. If none of these fit the bill, please let us know if/how we can rephrase. Perhaps A: Forward Secrecy Extension to the Improved Extensible Authentication Protocol for Authentication and Key Agreement (EAP-AKA' FS) Perhaps B: EAP-AKA' FS: The Forward Secrecy Extension for Improved Extensible Authentication Protocol for Authentication and Key Agreement Perhaps C: Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement Forward Secrecy Extension (EAP-AKA' FS) --> <seriesInfo name="RFC" value="9678"/> <authorinitials="J"initials="J." surname="Arkko" fullname="Jari Arkko"> <organization>Ericsson</organization> <address> <postal><street/><city>Jorvas</city> <code>02420</code> <country>Finland</country> </postal> <email>jari.arkko@piuha.net</email> </address> </author> <authorinitials="K"initials="K." surname="Norrman" fullname="Karl Norrman"> <organization>Ericsson</organization> <address> <postal><street/><city>Stockholm</city> <code>16483</code> <country>Sweden</country> </postal> <email>karl.norrman@ericsson.com</email> </address> </author> <authorinitials="J"initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson"> <organization>Ericsson</organization> <address> <postal><street/><city>Kista</city> <code>164 40</code> <country>Sweden</country> </postal> <email>john.mattsson@ericsson.com</email> </address> </author> <date month="October" year="2024"/> <area>SEC</area> <workgroup>emu</workgroup> <keyword>EAP</keyword> <keyword>AKA</keyword> <keyword>AKA'</keyword> <keyword>EAP-AKA'</keyword> <keyword>EAP-AKA' FS</keyword> <keyword>3GPP</keyword> <!--[rfced] The Abstract and IANA Considerations each contain places where an (almost) RFC title is listed for one RFC but a "nickname" for another/others. How may we make these consistent? Abstract: This document updates RFC 9048, the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'),...Similarly, this document also updates the earlier version of the EAP-AKA' specification in RFC 5448. IANA: This extension of EAP-AKA' shares its attribute space and subtypes with Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM) [RFC4186], EAP-AKA [RFC4187], and EAP-AKA' [RFC9048]. --> <abstract> <t>This document updates RFC 9048, which details the improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement (EAP-AKA'), with an optional extension providing ephemeral key exchange. Similarly, this document also updates the earlier version of the EAP-AKA' specification in RFC 5448. The extension EAP-AKA' Forward Secrecy (EAP-AKA' FS), when negotiated, provides forward secrecy for the session keys generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key from obtaining session keys established in the past, assuming these have been properly deleted. In addition, EAP-AKA' FS mitigates passive attacks (e.g.,large scalelarge-scale pervasive monitoring) against future sessions. This forces attackers to use active attacks instead.</t> </abstract> </front> <middle> <sectionanchor="sec:intro" title="Introduction">anchor="sec_intro" numbered="true" toc="default"> <name>Introduction</name> <t>Many different attacks have been reported as part of the revelations associated with pervasive surveillance. Some of the reported attacks involved compromising the Universal Subscriber Identity Module (USIM) card supply chain. Attacks revealing the AKA long-term key mayoccuroccur, forinstance, duringinstance:</t> <ul><li>during the manufacturing process of USIMcards, duringcards,</li> <li>during the transfer of the cards and associated information to the operator,and whenand</li> <li>when a system isrunning. Sincerunning.</li></ul> <t>Since the publication of reports about such attacks (see <xreftarget="Heist2015"/>,target="Heist2015" format="default"/>), manufacturing and provisioning processes have gained much scrutiny and have improved.</t> <t>However, the danger of resourceful attackers attempting to gain information about long-term keys is still a concern because these keys are high-value targets. Note that the attacks are largely independent of the used authentication technology; the issue is not vulnerabilities in algorithms or protocols, but rather the possibility of someone gaining unauthorized access to key material. Furthermore, an explicit goal of the IETF is to ensure that we understand the surveillance concerns related to IETF protocols and take appropriate countermeasures <xreftarget="RFC7258"/>.</t>target="RFC7258" format="default"/>.</t> <t>While strong protection of manufacturing and other processes is essential in mitigating surveillance and other risks associated with AKA long-term keys, there are also protocol mechanisms that can help.</t> <t>This document updates <xreftarget="RFC9048"/>, the Improvedtarget="RFC9048" format="default"/>, "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network Authentication and Key Agreement(EAP-AKA') method,(EAP-AKA')", with an optional extension providing ephemeral keyexchange minimizingexchange, which minimizes the impact of long-term key compromise and strengthens the identity privacy requirements. This is important, given the large number of users of AKA in mobile networks.</t> <t>The extension, when negotiated, provides Forward Secrecy (FS) <xreftarget="DOW1992"/>target="DOW1992" format="default"/> for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term key in a USIM card from getting access to past session keys. In addition to FS, the included Diffie-Hellmanexchange,exchange forces attackers to be active if they want access to future sessionkeyskeys, even if they have access to the long-term key. This isbeneficial,beneficial because active attacks demandmuchmany more resources tolaunch,launch and are easier to detect. As with other protocols, an active attacker with access to the long-term key materialwillwill, ofcoursecourse, be able to attack all future communications, but risks detection, particularly if done at scale.</t> <t>It should also be noted that 5G network architecture <xreftarget="TS.33.501"/>target="TS.33.501" format="default"/> includes the use of the EAP framework for authentication. While any methods can be run, the default authentication method within that context will be EAP-AKA'. As a result, improvements in EAP-AKA' security haveathe potential to improve security for many users.</t> </section> <sectiontitle="Requirements Language"> <t>Thenumbered="true" toc="default"> <name>Requirements Language</name> <t> The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t>here. </t> </section> <sectiontitle="Protocolnumbered="true" toc="default"> <name>Protocol Design and DeploymentObjectives">Objectives</name> <t>The extension specified herere-usesreuses 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 <xreftarget="TrustCom2015"/>,target="TrustCom2015" format="default"/>) and uses much of the samematerial,material but is applied to EAP rather than the underlying AKA method.</t> <!--[rfced] FYI - We have added an additional verb to the sentence below for clarity. Please review to ensure this update retains your intended meaning. Original: It has been a goal to implement this change as an extension of the widely supported EAP-AKA' method, rather than a completely new authentication method. Current: 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. --> <t>It has been a goal to implement this change as an extension of the widely supported EAP-AKA' method, rather than implement a completely new authentication method. The extension is implemented as a set of new, optionalattributes,attributes that are provided alongside the base attributes in EAP-AKA'. Old implementations can ignore these attributes, but their presence will nevertheless be verified as part of the base EAP-AKA' integrity verification process, helping protect against bidding down attacks. This extension does not increase the number of rounds necessary to complete the protocol.</t> <t>The use of this extension is at the discretion of the authenticating parties. It should be noted that FS and defenses against passive attacks do not solve all problems, but they can provide a partial defense that increases the cost and risk associated with pervasive surveillance.</t> <t>While addingforward secrecyFS to the existing mobile network infrastructure can be done in multiple different ways, this document specifies a solution that is relativelyeasily deployable.easy to deploy. In particular:<list style="symbols"> <t>As</t> <ul spacing="normal"> <li>As noted above, no new credentials are needed; there is no change to USIMcards.</t> <t>FScards.</li> <li>FS property can be incorporated into any current or future system that supports EAP, without changing any network functions beyond the EAPendpoints.</t> <t>Keyendpoints.</li> <li>Key generation happens at the endpoints, enabling the highest grade key material to be used both by the endpoints and the intermediate systems (such as access points that are given access to specifickeys).</t> <t>Whilekeys).</li> <li>While EAP-AKA' is just one EAP method, for practicalpurposes forward secrecypurposes, FS being available for both EAP-TLS <xreftarget="RFC5216"/>target="RFC5216" format="default"/> <xreftarget="RFC9190"/>target="RFC9190" format="default"/> and EAP-AKA' ensuresthatthat, for many practicalsystems forward secrecysystems, FS can be enabled for either all or a significant fraction ofusers.</t> </list></t>users.</li> </ul> </section> <sectiontitle="Background">numbered="true" toc="default"> <name>Background</name> <t>The reader is assumed to have a basic understanding of the EAP framework <xreftarget="RFC3748"/>.</t>target="RFC3748" format="default"/>.</t> <sectiontitle="AKA">numbered="true" toc="default"> <name>AKA</name> <t>We use the termAuthentication"Authentication and KeyAgreement (AKA)Agreement" (or "AKA") for the main authentication and key agreement protocol used by 3GPP mobile networks from the third generation (3G) and onward. Later generationsaddsadd 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 removableUICC (UniversalUniversal Integrated CircuitCard),Card (UICC), an embedded UICC, or integrated in a Trusted Execution Environment (TEE). In thisdocumentdocument, we use the term "USIM card" to refer to any Subscriber Identity Module (SIM) capable of running AKA.</t> <!--[rfced] In the text below, is "the subscribers" plural possessive ("the subscribers'") or singular possessive ("the subscriber's")? Additionally, are any other updates needed to "home operator's network"? Original: The goal of AKA is to mutually authenticate the USIM and the so- called home environment, which is the authentication server in the subscribers home operator's network. Perhaps: The goal of AKA is to mutually authenticate the USIM and the so- called home environment, which is the authentication server in the subscriber's home operator's network. --> <t>The goal of AKA is to mutually authenticate the USIM and the so-called home environment, which is the authentication server in the subscribers home operator's network.</t> <t>AKA works in the followingmanner: <list style="symbols"> <t>Themanner:</t> <ul spacing="normal"> <li>The USIM and the home environment have agreed on a long-term symmetric keybeforehand.</t> <t>Thebeforehand.</li> <li>The actual authentication process starts by having the home environment produce an authentication vector, based on the long-term key and a sequence number. The authentication vector contains a random part RAND, an authenticator part AUTN used for authenticating the network to the USIM, an expected result part XRES, a 128-bit session key for integrity check IK, and a 128-bit session key for encryptionCK.</t> <t>TheCK.</li> <li>The authentication vector is passed to the serving network, which uses it to authenticate thedevice.</t> <t>Thedevice.</li> <li>The RAND and the AUTN are delivered to theUSIM.</t> <t>TheUSIM.</li> <li>The USIM verifies the AUTN, again based on the long-term key and the sequence number. If this process is successful (the AUTN is valid and the sequence number used to generate AUTN is within the correct range), the USIM produces an authentication result RES and sends it to the servingnetwork.</t> <t>Thenetwork.</li> <li>The serving network verifies that the result from the USIM matches the expected value in the authentication vector. If it does, the USIM is considered authenticated, and IK and CK can be used to protect further communications between the USIM and the homeenvironment.</t> </list></t>environment.</li> </ul> </section> <sectiontitle="EAP-AKA' Protocol">numbered="true" toc="default"> <name>EAP-AKA' Protocol</name> <t>When AKA is embedded into EAP, the authentication processing on the network side is moved to the home environment. The 3GPPauthentication databaseAuthentication 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 oftheclient. The difference between EAP-AKA <xreftarget="RFC4187"/>target="RFC4187" format="default"/> and EAP-AKA' <xreftarget="RFC9048"/>target="RFC9048" format="default"/> is that EAP-AKA' binds the derived keys to the name of the access network. <xreftarget="figaka"/>target="figaka" format="default"/> describes the basic flow in the EAP-AKA' authentication process. The definition of the full protocol behavior, along with the definition of the attributes AT_RAND, AT_AUTN, AT_MAC, and AT_RES can be found in <xreftarget="RFC9048"/>target="RFC9048" format="default"/> and <xreftarget="RFC4187"/>.target="RFC4187" format="default"/>. Note the use ofEAP-terminologyEAP terminology from hereon. That is, the 3GPP serving network takes on the role of an EAP access network. </t> <!--[rfced] We have the following changes and questions regarding the SVG and ASCII artwork in this document. a. FYI - The SVG artwork in Figure 2 ran off the page in the PDF output; we have adjusted the height and width attributes to allow this artwork to fit the page. Please review and let us know any objections or additional adjustments. b. Please review and/or update artworks with the following suggestions in mind: i. Articles appear inconsistently in front of some terms in the artwork (see an example below). How would you like to update for consistency? Original (with articles): The peer also retrieves the network name sent by the network from the AT_KDF_INPUT attribute... Original (without articles): Otherwise, the network name from AT_KDF_INPUT attribute... ii. Please review instances where the expansion "key derivation function" may be abbreviated to KDF. Original: AT_KDF signals the used key derivation function. ID, key deriv. function, network name Perhaps: AT_KDF signals the used KDF. ID, KDF, network name c) We note that the text in the figure does not follow this guidance from RFC 7322 (RFC Style Guide): * When a sentence ended by a period is immediately followed by another sentence, there must be two blank spaces after the period. --> <!--[rfced] We note that Figure 1 contains the only (two) mentions of AKA'. Elsewhere we see AKA or EAP-AKA'. Please review and confirm.--> <figuretitle="EAP-AKA' Authentication Process"anchor="figaka"> <name>EAP-AKA' Authentication Process</name> <artset> <artworktype="ascii-art"><![CDATA[type="ascii-art" name="" align="left" alt=""><![CDATA[ Peer Server | | | EAP-Request/Identity | |<-----------------------------------------------------------+ | | | EAP-Response/Identity | | (Includes user's Network AccessIdentifier, NAI)Identifier (NAI)) | +----------------------------------------------------------->| | +-----------------------------------------------------+--+ | | Server determines the network name and ensures that | | | the given access network is authorized to use the | | | claimed name. The server then runs the AKA' algorithms | | | generating RAND and AUTN, derives session keys from | | | CK' and IK'. RAND and AUTN are sent as AT_RAND and | | | AT_AUTN attributes, whereas the network name is | | | transported in the AT_KDF_INPUT attribute. AT_KDF | | | signals the used key derivation function. The session | | | keys are used to create the AT_MAC attribute. | | +-----------------------------------------------------+--+ | | | EAP-Request/AKA'-Challenge | | (AT_RAND, AT_AUTN, AT_KDF, AT_KDF_INPUT, AT_MAC) | |<-----------------------------------------------------------+ +--+-----------------------------------------------------+ | | The peer determines what the network name should be, | | | based on, e.g., what access technology it is using. | | | The peer also retrieves the network name sent by the | | | network from the AT_KDF_INPUT attribute. The two names | | | are compared for discrepancies, and if they do not | | | match, the authentication is aborted. Otherwise, the | | | network name from AT_KDF_INPUT attribute is used in | | | running the AKA' algorithms, verifying AUTN from | | | AT_AUTN and MAC from 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) | +----------------------------------------------------------->| | +-----------------------------------------------------+--+ | | Server checks the RES and MAC values received in | | | AT_RES and AT_MAC, respectively. Success requires both | | | compared values match, respectively. | | +-----------------------------------------------------+--+ | | | EAP-Success | |<-----------------------------------------------------------+ | | ]]></artwork> <artworktype="svg"><svgtype="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="832" width="552" viewBox="0 0 552 832" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,400 L 8,608" fill="none" stroke="black"/> <path d="M 32,48 L 32,400" fill="none" stroke="black"/> <path d="M 32,608 L 32,816" fill="none" stroke="black"/> <path d="M 88,160 L 88,320" fill="none" stroke="black"/> <path d="M 88,688 L 88,752" fill="none" stroke="black"/> <path d="M 464,400 L 464,608" fill="none" stroke="black"/> <path d="M 520,48 L 520,160" fill="none" stroke="black"/> <path d="M 520,320 L 520,688" fill="none" stroke="black"/> <path d="M 520,752 L 520,816" fill="none" stroke="black"/> <path d="M 544,160 L 544,320" fill="none" stroke="black"/> <path d="M 544,688 L 544,752" fill="none" stroke="black"/> <path d="M 40,80 L 520,80" fill="none" stroke="black"/> <path d="M 32,144 L 512,144" fill="none" stroke="black"/> <path d="M 88,160 L 544,160" fill="none" stroke="black"/> <path d="M 88,320 L 544,320" fill="none" stroke="black"/> <path d="M 40,384 L 520,384" fill="none" stroke="black"/> <path d="M 8,400 L 464,400" fill="none" stroke="black"/> <path d="M 8,608 L 464,608" fill="none" stroke="black"/> <path d="M 32,672 L 512,672" fill="none" stroke="black"/> <path d="M 88,688 L 544,688" fill="none" stroke="black"/> <path d="M 88,752 L 544,752" fill="none" stroke="black"/> <path d="M 40,800 L 520,800" fill="none" stroke="black"/> <path d="M 144,640 L 144,640" fill="none" stroke="black"/> <polygon class="arrowhead" points="520,672 508,666.4 508,677.6" fill="black" transform="rotate(0,512,672)"/> <polygon class="arrowhead" points="520,144 508,138.4 508,149.6" fill="black" transform="rotate(0,512,144)"/> <polygon class="arrowhead" points="48,800 36,794.4 36,805.6" fill="black" transform="rotate(180,40,800)"/> <polygon class="arrowhead" points="48,384 36,378.4 36,389.6" fill="black" transform="rotate(180,40,384)"/> <polygon class="arrowhead" points="48,80 36,74.4 36,85.6" fill="black" transform="rotate(180,40,80)"/> <g class="text"> <text x="28" y="36">Peer</text> <text x="516" y="36">Server</text> <text x="428" y="68">EAP-Request/Identity</text> <text x="128" y="116">EAP-Response/Identity</text> <text x="80" y="132">(Includes</text> <text x="148" y="132">user's</text> <text x="208" y="132">Network</text> <text x="268" y="132">Access</text> <text x="344"y="132">Identifier,</text>y="132">Identifier</text> <text x="412"y="132">NAI)</text>y="132">(NAI))</text> <text x="124" y="180">Server</text> <text x="196" y="180">determines</text> <text x="256" y="180">the</text> <text x="304" y="180">network</text> <text x="356" y="180">name</text> <text x="392" y="180">and</text> <text x="440" y="180">ensures</text> <text x="492" y="180">that</text> <text x="112" y="196">the</text> <text x="152" y="196">given</text> <text x="204" y="196">access</text> <text x="264" y="196">network</text> <text x="308" y="196">is</text> <text x="364" y="196">authorized</text> <text x="420" y="196">to</text> <text x="448" y="196">use</text> <text x="480" y="196">the</text> <text x="128" y="212">claimed</text> <text x="184" y="212">name.</text> <text x="224" y="212">The</text> <text x="268" y="212">server</text> <text x="316" y="212">then</text> <text x="356" y="212">runs</text> <text x="392" y="212">the</text> <text x="428" y="212">AKA'</text> <text x="492" y="212">algorithms</text> <text x="140" y="228">generating</text> <text x="204" y="228">RAND</text> <text x="240" y="228">and</text> <text x="280" y="228">AUTN,</text> <text x="336" y="228">derives</text> <text x="400" y="228">session</text> <text x="452" y="228">keys</text> <text x="492" y="228">from</text> <text x="112" y="244">CK'</text> <text x="144" y="244">and</text> <text x="180" y="244">IK'.</text> <text x="220" y="244">RAND</text> <text x="256" y="244">and</text> <text x="292" y="244">AUTN</text> <text x="328" y="244">are</text> <text x="364" y="244">sent</text> <text x="396" y="244">as</text> <text x="440" y="244">AT_RAND</text> <text x="488" y="244">and</text> <text x="128" y="260">AT_AUTN</text> <text x="208" y="260">attributes,</text> <text x="288" y="260">whereas</text> <text x="336" y="260">the</text> <text x="384" y="260">network</text> <text x="436" y="260">name</text> <text x="468" y="260">is</text> <text x="144" y="276">transported</text> <text x="204" y="276">in</text> <text x="232" y="276">the</text> <text x="300" y="276">AT_KDF_INPUT</text> <text x="396" y="276">attribute.</text> <text x="468" y="276">AT_KDF</text> <text x="128" y="292">signals</text> <text x="176" y="292">the</text> <text x="212" y="292">used</text> <text x="248" y="292">key</text> <text x="308" y="292">derivation</text> <text x="392" y="292">function.</text> <text x="448" y="292">The</text> <text x="496" y="292">session</text> <text x="116" y="308">keys</text> <text x="152" y="308">are</text> <text x="188" y="308">used</text> <text x="220" y="308">to</text> <text x="260" y="308">create</text> <text x="304" y="308">the</text> <text x="348" y="308">AT_MAC</text> <text x="420" y="308">attribute.</text> <text x="404" y="356">EAP-Request/AKA'-Challenge</text> <text x="160" y="372">(AT_RAND,</text> <text x="236" y="372">AT_AUTN,</text> <text x="304" y="372">AT_KDF,</text> <text x="392" y="372">AT_KDF_INPUT,</text> <text x="480" y="372">AT_MAC)</text> <text x="32" y="420">The</text> <text x="68" y="420">peer</text> <text x="132" y="420">determines</text> <text x="196" y="420">what</text> <text x="232" y="420">the</text> <text x="280" y="420">network</text> <text x="332" y="420">name</text> <text x="380" y="420">should</text> <text x="424" y="420">be,</text> <text x="40" y="436">based</text> <text x="80" y="436">on,</text> <text x="120" y="436">e.g.,</text> <text x="164" y="436">what</text> <text x="212" y="436">access</text> <text x="284" y="436">technology</text> <text x="340" y="436">it</text> <text x="364" y="436">is</text> <text x="404" y="436">using.</text> <text x="32" y="452">The</text> <text x="68" y="452">peer</text> <text x="108" y="452">also</text> <text x="168" y="452">retrieves</text> <text x="224" y="452">the</text> <text x="272" y="452">network</text> <text x="324" y="452">name</text> <text x="364" y="452">sent</text> <text x="396" y="452">by</text> <text x="424" y="452">the</text> <text x="48" y="468">network</text> <text x="100" y="468">from</text> <text x="136" y="468">the</text> <text x="204" y="468">AT_KDF_INPUT</text> <text x="300" y="468">attribute.</text> <text x="360" y="468">The</text> <text x="392" y="468">two</text> <text x="432" y="468">names</text> <text x="32" y="484">are</text> <text x="84" y="484">compared</text> <text x="136" y="484">for</text> <text x="212" y="484">discrepancies,</text> <text x="288" y="484">and</text> <text x="316" y="484">if</text> <text x="348" y="484">they</text> <text x="380" y="484">do</text> <text x="408" y="484">not</text> <text x="44" y="500">match,</text> <text x="88" y="500">the</text> <text x="164" y="500">authentication</text> <text x="236" y="500">is</text> <text x="284" y="500">aborted.</text> <text x="364" y="500">Otherwise,</text> <text x="424" y="500">the</text> <text x="48" y="516">network</text> <text x="100" y="516">name</text> <text x="140" y="516">from</text> <text x="212" y="516">AT_KDF_INPUT</text> <text x="304" y="516">attribute</text> <text x="356" y="516">is</text> <text x="388" y="516">used</text> <text x="420" y="516">in</text> <text x="48" y="532">running</text> <text x="96" y="532">the</text> <text x="132" y="532">AKA'</text> <text x="200" y="532">algorithms,</text> <text x="288" y="532">verifying</text> <text x="348" y="532">AUTN</text> <text x="388" y="532">from</text> <text x="48" y="548">AT_AUTN</text> <text x="96" y="548">and</text> <text x="128" y="548">MAC</text> <text x="164" y="548">from</text> <text x="212" y="548">AT_MAC</text> <text x="288" y="548">attributes.</text> <text x="352" y="548">The</text> <text x="388" y="548">peer</text> <text x="428" y="548">then</text> <text x="56" y="564">generates</text> <text x="116" y="564">RES.</text> <text x="152" y="564">The</text> <text x="188" y="564">peer</text> <text x="228" y="564">also</text> <text x="280" y="564">derives</text> <text x="344" y="564">session</text> <text x="396" y="564">keys</text> <text x="436" y="564">from</text> <text x="52" y="580">CK'/IK'.</text> <text x="104" y="580">The</text> <text x="148" y="580">AT_RES</text> <text x="192" y="580">and</text> <text x="236" y="580">AT_MAC</text> <text x="308" y="580">attributes</text> <text x="368" y="580">are</text> <text x="68" y="596">constructed.</text> <text x="92" y="644">EAP-Response</text> <text x="204" y="644">AKA'-Challenge</text> <text x="76" y="660">(AT_RES,</text> <text x="144" y="660">AT_MAC)</text> <text x="124" y="708">Server</text> <text x="180" y="708">checks</text> <text x="224" y="708">the</text> <text x="256" y="708">RES</text> <text x="288" y="708">and</text> <text x="320" y="708">MAC</text> <text x="364" y="708">values</text> <text x="428" y="708">received</text> <text x="476" y="708">in</text> <text x="124" y="724">AT_RES</text> <text x="168" y="724">and</text> <text x="216" y="724">AT_MAC,</text> <text x="304" y="724">respectively.</text> <text x="392" y="724">Success</text> <text x="460" y="724">requires</text> <text x="516" y="724">both</text> <text x="132" y="740">compared</text> <text x="196" y="740">values</text> <text x="252" y="740">match,</text> <text x="336" y="740">respectively.</text> <text x="464" y="788">EAP-Success</text> </g> </svg> </artwork> </artset> </figure> </section> <section anchor="attacks"title="Attacksnumbered="true" toc="default"> <name>Attacks Against Long-Term Keys in SmartCards">Cards</name> <t>The general security properties and potential vulnerabilities of AKA and EAP-AKA' are discussed in <xreftarget="RFC9048"/>.</t>target="RFC9048" format="default"/>.</t> <!--[rfced] For ease of the reader, may we adjust the text below as follows? Original: This document specifies a mechanism that reduces risks to compromise of key material belonging to previous sessions, before the long-term keys were compromised. Perhaps: This document specifies a mechanism that reduces the risks of compromising key material belonging to previous sessions, before the long-term keys were compromised. --> <t>An important question in that discussion relates to the potential compromise of long-term keys, as discussed earlier. Attacks on long-term keys are not specific to AKA or EAP-AKA', and all security systemsfailfail, at least to someextentextent, if key material is stolen. However, it would be preferable to retain some security even in the face of such attacks. This document specifies a mechanism that reduces risks to compromise of key material belonging to previous sessions, before the long-term keys were compromised. It also forces attackers to be active even after the compromise.</t> </section> </section> <sectiontitle="Protocol Overview">numbered="true" toc="default"> <name>Protocol Overview</name> <t>ForwardsecrecySecrecy (FS) for EAP-AKA' is achieved by using an Elliptic Curve Diffie-Hellman (ECDH) exchange <xreftarget="RFC7748"/>.target="RFC7748" format="default"/>. To provide FS, the exchange must be run in an ephemeral manner, i.e., both sides generate temporary keys according to the negotiatedciphersuite, e.g.,ciphersuite. For example, forX25519X25519, this is done as specified in <xreftarget="RFC7748"/>.target="RFC7748" format="default"/>. This method is referred to asECDHE,"ECDHE", where the last'E'"E" stands forEphemeral."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 3GPPTS 33.501<xreftarget="TS.33.501"/>.</t>target="TS.33.501" format="default"/>.</t> <t>The enhancements in the EAP-AKA' FS protocol are compatible with the signaling flow and other basic structures of both AKA and EAP-AKA'. The intent is to implement the enhancement as optional attributes that legacy implementations ignore.</t> <!--[rfced] We note a switch between "keying material" and "key material" in the following. Should these be made consistent? Original: ...and to establish keying 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>The purpose of the protocol is to achieve mutual authentication between the EAP server andpeer,peer and to establish keying 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> <!--[rfced] Might it be helpful to the reader to point them to the specific 3GPP specifications to which you refer? Original: The details of those interactions are outside the scope of this document, however, and the reader is referred to the 3GPP specifications. --> <t><xreftarget="figakafs"/> belowtarget="figakafs" format="default"/> describes the overall process. Since the goal has been to not require new infrastructure or credentials, the flow diagrams also show the conceptual interaction with the USIM card and the home environment. Recall that the home environmentrepresentrepresents 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. For5G5G, this is specified in 3GPPTS 33.501<xreftarget="TS.33.501"/></t>target="TS.33.501" format="default"/>.</t> <figuretitle="EAP-AKA'anchor="figakafs"> <name>EAP-AKA' FS AuthenticationProcess" anchor="figakafs">Process</name> <artset> <artworktype="ascii-art"><![CDATA[type="ascii-art" name="" align="left" alt=""><![CDATA[ USIM Peer Server AD | | | | | | EAP-Req/Identity | | | |<---------------------------+ | | | | | | | EAP-Resp/Identity | | | | (Privacy-Friendly) | | | +--------------------------->| | | +-------+----------------------------+----------------+--+ | | Server now has an identity for the peer. The server | | | then asks the help of AD to run AKA algorithms, | | | generating RAND, AUTN, XRES, CK, IK. Typically, the | | | AD performs the first part of key derivations so that | | | the authentication server gets the CK' and IK' keys | | | already tied to a particular network name. | | +-------+----------------------------+----------------+--+ | | | | | | | ID, key deriv. | | | | function, | | | | network name | | | +--------------->| | | | | | | | RAND, AUTN, | | | | XRES, CK', IK' | | | |<---------------+ | +-------+----------------------------+----------------+--+ | | Server now has the needed authentication vector. It | | | generates an ephemeral key pair, sends the public key | | | of that key pair and the first EAP method message to | | | the peer. In the message the AT_PUB_ECDHE attribute | | | carries the public key and the AT_KDF_FS attribute | | | carries other FS-related parameters. Both of these are | | | skippable attributes that can be ignored if the peer | | | does not support this extension. | | +-------+----------------------------+----------------+--+ | | | | | | EAP-Req/AKA'-Challenge | | | | AT_RAND, AT_AUTN, AT_KDF, | | | | AT_KDF_FS, AT_KDF_INPUT, | | | | AT_PUB_ECDHE, AT_MAC | | | |<---------------------------+ | +--+--------------+----------------------------+---------+ | | The peer checks if it wants to do the FS extension. If | | | yes, it will eventually respond with AT_PUB_ECDHE and | | | AT_MAC. If not, it will ignore AT_PUB_ECDHE and | | | AT_KDF_FS and base all calculations on basic EAP-AKA' | | | attributes, continuing just as in EAP-AKA' per RFC | | | 9048 rules. In any case, the peer needs to query the | | | auth parameters from the USIM card. | | +--+--------------+----------------------------+---------+ | | | | | | RAND, AUTN | | | |<-------------+ | | | | | | | CK, IK, RES | | | +------------->| | | +--+--------------+----------------------------+---------+ | | The peer now has everything to respond. If it wants to | | | participate in the FS extension, it will then generate | | | its key pair, calculate a shared key based on its key | | | pair and the server's public key. Finally, it proceeds | | | to derive all EAP-AKA' key values and constructs a | | | full response. | | +--+--------------+----------------------------+---------+ | | | | | | | EAP-Resp/AKA'-Challenge | | | | AT_RES, AT_PUB_ECDHE, | | | | AT_MAC | | | +--------------------------->| | | +-------+----------------------------+----------------+--+ | | The server now has all the necessary values. It | | | generates the ECDHE shared secret and checks the RES | | | and MAC values received in AT_RES and AT_MAC, | | | respectively. Success requires both to be found | | | correct. Note that when this document is used, | | | the keys generated from EAP-AKA' are based on CK, IK, | | | and the ECDHE value. Even if there was an attacker who | | | held the long-term key, only an active attacker could | | | have determined the generated session keys; in basic | | | EAP-AKA' the generated keys are only based on CK and | | | IK. | | +-------+----------------------------+----------------+--+ | | | | | | EAP-Success | | | |<---------------------------+ | | | | | ]]></artwork> <artworktype="svg"><svgtype="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1"height="1408" width="552"height="1200" width="875" viewBox="0 0 552 1408" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round"> <path d="M 8,688 L 8,816" fill="none" stroke="black"/> <path d="M 8,928 L 8,1040" fill="none" stroke="black"/> <path d="M 32,48 L 32,688" fill="none" stroke="black"/> <path d="M 32,816 L 32,928" fill="none" stroke="black"/> <path d="M 32,1040 L 32,1392" fill="none" stroke="black"/> <path d="M 88,160 L 88,272" fill="none" stroke="black"/> <path d="M 88,432 L 88,576" fill="none" stroke="black"/> <path d="M 88,1136 L 88,1328" fill="none" stroke="black"/> <path d="M 152,48 L 152,160" fill="none" stroke="black"/> <path d="M 152,272 L 152,432" fill="none" stroke="black"/> <path d="M 152,576 L 152,688" fill="none" stroke="black"/> <path d="M 152,816 L 152,928" fill="none" stroke="black"/> <path d="M 152,1040 L 152,1136" fill="none" stroke="black"/> <path d="M 152,1328 L 152,1392" fill="none" stroke="black"/> <path d="M 384,48 L 384,160" fill="none" stroke="black"/> <path d="M 384,272 L 384,432" fill="none" stroke="black"/> <path d="M 384,576 L 384,688" fill="none" stroke="black"/> <path d="M 384,816 L 384,928" fill="none" stroke="black"/> <path d="M 384,1040 L 384,1136" fill="none" stroke="black"/> <path d="M 384,1328 L 384,1392" fill="none" stroke="black"/> <path d="M 464,688 L 464,816" fill="none" stroke="black"/> <path d="M 464,928 L 464,1040" fill="none" stroke="black"/> <path d="M 520,48 L 520,160" fill="none" stroke="black"/> <path d="M 520,272 L 520,432" fill="none" stroke="black"/> <path d="M 520,576 L 520,1136" fill="none" stroke="black"/> <path d="M 520,1328 L 520,1392" fill="none" stroke="black"/> <path d="M 544,160 L 544,272" fill="none" stroke="black"/> <path d="M 544,432 L 544,576" fill="none" stroke="black"/> <path d="M 544,1136 L 544,1328" fill="none" stroke="black"/> <path d="M 160,80 L 384,80" fill="none" stroke="black"/> <path d="M 152,144 L 376,144" fill="none" stroke="black"/> <path d="M 88,160 L 544,160" fill="none" stroke="black"/> <path d="M 88,272 L 544,272" fill="none" stroke="black"/> <path d="M 384,352 L 512,352" fill="none" stroke="black"/> <path d="M 392,416 L 520,416" fill="none" stroke="black"/> <path d="M 88,432 L 544,432" fill="none" stroke="black"/> <path d="M 88,576 L 544,576" fill="none" stroke="black"/> <path d="M 160,672 L 384,672" fill="none" stroke="black"/> <path d="M 8,688 L 464,688" fill="none" stroke="black"/> <path d="M 8,816 L 464,816" fill="none" stroke="black"/> <path d="M 40,864 L 152,864" fill="none" stroke="black"/> <path d="M 32,912 L 144,912" fill="none" stroke="black"/> <path d="M 8,928 L 464,928" fill="none" stroke="black"/> <path d="M 8,1040 L 464,1040" fill="none" stroke="black"/> <path d="M 152,1120 L 376,1120" fill="none" stroke="black"/> <path d="M 88,1136 L 544,1136" fill="none" stroke="black"/> <path d="M 88,1328 L 544,1328" fill="none" stroke="black"/> <path d="M 160,1376 L 384,1376" fill="none" stroke="black"/> <polygon class="arrowhead" points="520,352 508,346.4 508,357.6" fill="black" transform="rotate(0,512,352)"/> <polygon class="arrowhead" points="400,416 388,410.4 388,421.6" fill="black" transform="rotate(180,392,416)"/> <polygon class="arrowhead" points="384,1120 372,1114.4 372,1125.6" fill="black" transform="rotate(0,376,1120)"/> <polygon class="arrowhead" points="384,144 372,138.4 372,149.6" fill="black" transform="rotate(0,376,144)"/> <polygon class="arrowhead" points="168,1376 156,1370.4 156,1381.6" fill="black" transform="rotate(180,160,1376)"/> <polygon class="arrowhead" points="168,672 156,666.4 156,677.6" fill="black" transform="rotate(180,160,672)"/> <polygon class="arrowhead" points="168,80 156,74.4 156,85.6" fill="black" transform="rotate(180,160,80)"/> <polygon class="arrowhead" points="152,912 140,906.4 140,917.6" fill="black" transform="rotate(0,144,912)"/> <polygon class="arrowhead" points="48,864 36,858.4 36,869.6" fill="black" transform="rotate(180,40,864)"/> <g class="text"> <text x="28" y="36">USIM</text> <text x="148" y="36">Peer</text> <text x="380" y="36">Server</text> <text x="524" y="36">AD</text> <text x="308" y="68">EAP-Req/Identity</text> <text x="232" y="116">EAP-Resp/Identity</text> <text x="236" y="132">(Privacy-Friendly)</text> <text x="124" y="180">Server</text> <text x="168" y="180">now</text> <text x="200" y="180">has</text> <text x="228" y="180">an</text> <text x="276" y="180">identity</text> <text x="328" y="180">for</text> <text x="360" y="180">the</text> <text x="400" y="180">peer.</text> <text x="440" y="180">The</text> <text x="484" y="180">server</text> <text x="116" y="196">then</text> <text x="156" y="196">asks</text> <text x="192" y="196">the</text> <text x="228" y="196">help</text> <text x="260" y="196">of</text> <text x="284" y="196">AD</text> <text x="308" y="196">to</text> <text x="336" y="196">run</text> <text x="368" y="196">AKA</text> <text x="432" y="196">algorithms,</text> <text x="140" y="212">generating</text> <text x="208" y="212">RAND,</text> <text x="256" y="212">AUTN,</text> <text x="304" y="212">XRES,</text> <text x="344" y="212">CK,</text> <text x="376" y="212">IK.</text> <text x="436" y="212">Typically,</text> <text x="496" y="212">the</text> <text x="108" y="228">AD</text> <text x="156" y="228">performs</text> <text x="208" y="228">the</text> <text x="248" y="228">first</text> <text x="292" y="228">part</text> <text x="324" y="228">of</text> <text x="352" y="228">key</text> <text x="416" y="228">derivations</text> <text x="476" y="228">so</text> <text x="508" y="228">that</text> <text x="112" y="244">the</text> <text x="188" y="244">authentication</text> <text x="276" y="244">server</text> <text x="324" y="244">gets</text> <text x="360" y="244">the</text> <text x="392" y="244">CK'</text> <text x="424" y="244">and</text> <text x="456" y="244">IK'</text> <text x="492" y="244">keys</text> <text x="128" y="260">already</text> <text x="180" y="260">tied</text> <text x="212" y="260">to</text> <text x="232" y="260">a</text> <text x="284" y="260">particular</text> <text x="360" y="260">network</text> <text x="416" y="260">name.</text> <text x="408" y="308">ID,</text> <text x="440" y="308">key</text> <text x="484" y="308">deriv.</text> <text x="432" y="324">function,</text> <text x="424" y="340">network</text> <text x="476" y="340">name</text> <text x="440" y="388">RAND,</text> <text x="488" y="388">AUTN,</text> <text x="416" y="404">XRES,</text> <text x="460" y="404">CK',</text> <text x="496" y="404">IK'</text> <text x="124" y="452">Server</text> <text x="168" y="452">now</text> <text x="200" y="452">has</text> <text x="232" y="452">the</text> <text x="276" y="452">needed</text> <text x="364" y="452">authentication</text> <text x="456" y="452">vector.</text> <text x="500" y="452">It</text> <text x="136" y="468">generates</text> <text x="188" y="468">an</text> <text x="240" y="468">ephemeral</text> <text x="296" y="468">key</text> <text x="336" y="468">pair,</text> <text x="384" y="468">sends</text> <text x="424" y="468">the</text> <text x="468" y="468">public</text> <text x="512" y="468">key</text> <text x="108" y="484">of</text> <text x="140" y="484">that</text> <text x="176" y="484">key</text> <text x="212" y="484">pair</text> <text x="248" y="484">and</text> <text x="280" y="484">the</text> <text x="320" y="484">first</text> <text x="360" y="484">EAP</text> <text x="404" y="484">method</text> <text x="464" y="484">message</text> <text x="508" y="484">to</text> <text x="112" y="500">the</text> <text x="152" y="500">peer.</text> <text x="188" y="500">In</text> <text x="216" y="500">the</text> <text x="264" y="500">message</text> <text x="312" y="500">the</text> <text x="380" y="500">AT_PUB_ECDHE</text> <text x="472" y="500">attribute</text> <text x="128" y="516">carries</text> <text x="176" y="516">the</text> <text x="220" y="516">public</text> <text x="264" y="516">key</text> <text x="296" y="516">and</text> <text x="328" y="516">the</text> <text x="384" y="516">AT_KDF_FS</text> <text x="464" y="516">attribute</text> <text x="128" y="532">carries</text> <text x="184" y="532">other</text> <text x="252" y="532">FS-related</text> <text x="344" y="532">parameters.</text> <text x="412" y="532">Both</text> <text x="444" y="532">of</text> <text x="480" y="532">these</text> <text x="520" y="532">are</text> <text x="136" y="548">skippable</text> <text x="220" y="548">attributes</text> <text x="284" y="548">that</text> <text x="320" y="548">can</text> <text x="348" y="548">be</text> <text x="392" y="548">ignored</text> <text x="436" y="548">if</text> <text x="464" y="548">the</text> <text x="500" y="548">peer</text> <text x="116" y="564">does</text> <text x="152" y="564">not</text> <text x="200" y="564">support</text> <text x="252" y="564">this</text> <text x="316" y="564">extension.</text> <text x="284" y="612">EAP-Req/AKA'-Challenge</text> <text x="204" y="628">AT_RAND,</text> <text x="276" y="628">AT_AUTN,</text> <text x="344" y="628">AT_KDF,</text> <text x="220" y="644">AT_KDF_FS,</text> <text x="320" y="644">AT_KDF_INPUT,</text> <text x="264" y="660">AT_PUB_ECDHE,</text> <text x="348" y="660">AT_MAC</text> <text x="32" y="708">The</text> <text x="68" y="708">peer</text> <text x="116" y="708">checks</text> <text x="156" y="708">if</text> <text x="180" y="708">it</text> <text x="216" y="708">wants</text> <text x="252" y="708">to</text> <text x="276" y="708">do</text> <text x="304" y="708">the</text> <text x="332" y="708">FS</text> <text x="388" y="708">extension.</text> <text x="444" y="708">If</text> <text x="36" y="724">yes,</text> <text x="68" y="724">it</text> <text x="100" y="724">will</text> <text x="164" y="724">eventually</text> <text x="240" y="724">respond</text> <text x="292" y="724">with</text> <text x="364" y="724">AT_PUB_ECDHE</text> <text x="432" y="724">and</text> <text x="48" y="740">AT_MAC.</text> <text x="92" y="740">If</text> <text x="124" y="740">not,</text> <text x="156" y="740">it</text> <text x="188" y="740">will</text> <text x="236" y="740">ignore</text> <text x="316" y="740">AT_PUB_ECDHE</text> <text x="384" y="740">and</text> <text x="56" y="756">AT_KDF_FS</text> <text x="112" y="756">and</text> <text x="148" y="756">base</text> <text x="184" y="756">all</text> <text x="252" y="756">calculations</text> <text x="316" y="756">on</text> <text x="352" y="756">basic</text> <text x="412" y="756">EAP-AKA'</text> <text x="64" y="772">attributes,</text> <text x="156" y="772">continuing</text> <text x="220" y="772">just</text> <text x="252" y="772">as</text> <text x="276" y="772">in</text> <text x="324" y="772">EAP-AKA'</text> <text x="376" y="772">per</text> <text x="408" y="772">RFC</text> <text x="36" y="788">9048</text> <text x="84" y="788">rules.</text> <text x="124" y="788">In</text> <text x="152" y="788">any</text> <text x="192" y="788">case,</text> <text x="232" y="788">the</text> <text x="268" y="788">peer</text> <text x="312" y="788">needs</text> <text x="348" y="788">to</text> <text x="384" y="788">query</text> <text x="424" y="788">the</text> <text x="36" y="804">auth</text> <text x="100" y="804">parameters</text> <text x="164" y="804">from</text> <text x="200" y="804">the</text> <text x="236" y="804">USIM</text> <text x="280" y="804">card.</text> <text x="80" y="852">RAND,</text> <text x="124" y="852">AUTN</text> <text x="56" y="900">CK,</text> <text x="88" y="900">IK,</text> <text x="120" y="900">RES</text> <text x="32" y="948">The</text> <text x="68" y="948">peer</text> <text x="104" y="948">now</text> <text x="136" y="948">has</text> <text x="196" y="948">everything</text> <text x="252" y="948">to</text> <text x="300" y="948">respond.</text> <text x="348" y="948">If</text> <text x="372" y="948">it</text> <text x="408" y="948">wants</text> <text x="444" y="948">to</text> <text x="64" y="964">participate</text> <text x="124" y="964">in</text> <text x="152" y="964">the</text> <text x="180" y="964">FS</text> <text x="236" y="964">extension,</text> <text x="292" y="964">it</text> <text x="324" y="964">will</text> <text x="364" y="964">then</text> <text x="420" y="964">generate</text> <text x="32" y="980">its</text> <text x="64" y="980">key</text> <text x="104" y="980">pair,</text> <text x="168" y="980">calculate</text> <text x="216" y="980">a</text> <text x="252" y="980">shared</text> <text x="296" y="980">key</text> <text x="336" y="980">based</text> <text x="372" y="980">on</text> <text x="400" y="980">its</text> <text x="432" y="980">key</text> <text x="36" y="996">pair</text> <text x="72" y="996">and</text> <text x="104" y="996">the</text> <text x="156" y="996">server's</text> <text x="220" y="996">public</text> <text x="268" y="996">key.</text> <text x="324" y="996">Finally,</text> <text x="372" y="996">it</text> <text x="420" y="996">proceeds</text> <text x="28" y="1012">to</text> <text x="68" y="1012">derive</text> <text x="112" y="1012">all</text> <text x="164" y="1012">EAP-AKA'</text> <text x="216" y="1012">key</text> <text x="260" y="1012">values</text> <text x="304" y="1012">and</text> <text x="364" y="1012">constructs</text> <text x="416" y="1012">a</text> <text x="36" y="1028">full</text> <text x="96" y="1028">response.</text> <text x="256" y="1076">EAP-Resp/AKA'-Challenge</text> <text x="192" y="1092">AT_RES,</text> <text x="280" y="1092">AT_PUB_ECDHE,</text> <text x="188" y="1108">AT_MAC</text> <text x="112" y="1156">The</text> <text x="156" y="1156">server</text> <text x="200" y="1156">now</text> <text x="232" y="1156">has</text> <text x="264" y="1156">all</text> <text x="296" y="1156">the</text> <text x="352" y="1156">necessary</text> <text x="424" y="1156">values.</text> <text x="468" y="1156">It</text> <text x="136" y="1172">generates</text> <text x="192" y="1172">the</text> <text x="232" y="1172">ECDHE</text> <text x="284" y="1172">shared</text> <text x="340" y="1172">secret</text> <text x="384" y="1172">and</text> <text x="428" y="1172">checks</text> <text x="472" y="1172">the</text> <text x="504" y="1172">RES</text> <text x="112" y="1188">and</text> <text x="144" y="1188">MAC</text> <text x="188" y="1188">values</text> <text x="252" y="1188">received</text> <text x="300" y="1188">in</text> <text x="340" y="1188">AT_RES</text> <text x="384" y="1188">and</text> <text x="432" y="1188">AT_MAC,</text> <text x="152" y="1204">respectively.</text> <text x="240" y="1204">Success</text> <text x="308" y="1204">requires</text> <text x="364" y="1204">both</text> <text x="396" y="1204">to</text> <text x="420" y="1204">be</text> <text x="456" y="1204">found</text> <text x="132" y="1220">correct.</text> <text x="188" y="1220">Note</text> <text x="228" y="1220">that</text> <text x="268" y="1220">when</text> <text x="308" y="1220">this</text> <text x="364" y="1220">document</text> <text x="412" y="1220">is</text> <text x="448" y="1220">used,</text> <text x="112" y="1236">the</text> <text x="148" y="1236">keys</text> <text x="208" y="1236">generated</text> <text x="268" y="1236">from</text> <text x="324" y="1236">EAP-AKA'</text> <text x="376" y="1236">are</text> <text x="416" y="1236">based</text> <text x="452" y="1236">on</text> <text x="480" y="1236">CK,</text> <text x="512" y="1236">IK,</text> <text x="112" y="1252">and</text> <text x="144" y="1252">the</text> <text x="184" y="1252">ECDHE</text> <text x="236" y="1252">value.</text> <text x="284" y="1252">Even</text> <text x="316" y="1252">if</text> <text x="352" y="1252">there</text> <text x="392" y="1252">was</text> <text x="420" y="1252">an</text> <text x="468" y="1252">attacker</text> <text x="520" y="1252">who</text> <text x="116" y="1268">held</text> <text x="152" y="1268">the</text> <text x="208" y="1268">long-term</text> <text x="268" y="1268">key,</text> <text x="308" y="1268">only</text> <text x="340" y="1268">an</text> <text x="380" y="1268">active</text> <text x="444" y="1268">attacker</text> <text x="504" y="1268">could</text> <text x="116" y="1284">have</text> <text x="180" y="1284">determined</text> <text x="240" y="1284">the</text> <text x="296" y="1284">generated</text> <text x="368" y="1284">session</text> <text x="424" y="1284">keys;</text> <text x="460" y="1284">in</text> <text x="496" y="1284">basic</text> <text x="132" y="1300">EAP-AKA'</text> <text x="184" y="1300">the</text> <text x="240" y="1300">generated</text> <text x="300" y="1300">keys</text> <text x="336" y="1300">are</text> <text x="372" y="1300">only</text> <text x="416" y="1300">based</text> <text x="452" y="1300">on</text> <text x="476" y="1300">CK</text> <text x="504" y="1300">and</text> <text x="112" y="1316">IK.</text> <text x="328" y="1364">EAP-Success</text> </g> </svg> </artwork> </artset> </figure> </section> <sectiontitle="Extensionsnumbered="true" toc="default"> <name>Extensions toEAP-AKA'">EAP-AKA'</name> <section anchor="at_pub_dh"title="AT_PUB_ECDHE">numbered="true" toc="default"> <name>AT_PUB_ECDHE</name> <t>The AT_PUB_ECDHE attribute carries an ECDHE value.</t> <t>The format of the AT_PUB_ECDHE attribute is shown below.</t><figure><artset> <artwork type="ascii-art"align="center">align="center" name="" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_PUB_ECDHE | Length | Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>]]></artwork> <artworktype="svg"><svgtype="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="112" width="528" viewBox="0 0 528 112" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"> <path d="M 8,64 L 8,96" fill="none" stroke="black"/> <path d="M 136,64 L 136,96" fill="none" stroke="black"/> <path d="M 264,64 L 264,96" fill="none" stroke="black"/> <path d="M 520,64 L 520,96" fill="none" stroke="black"/> <path d="M 8,64 L 520,64" fill="none" stroke="black"/> <path d="M 8,96 L 520,96" fill="none" stroke="black"/> <g class="text"> <text x="16" y="36">0</text> <text x="176" y="36">1</text> <text x="336" y="36">2</text> <text x="496" y="36">3</text> <text x="16" y="52">0</text> <text x="32" y="52">1</text> <text x="48" y="52">2</text> <text x="64" y="52">3</text> <text x="80" y="52">4</text> <text x="96" y="52">5</text> <text x="112" y="52">6</text> <text x="128" y="52">7</text> <text x="144" y="52">8</text> <text x="160" y="52">9</text> <text x="176" y="52">0</text> <text x="192" y="52">1</text> <text x="208" y="52">2</text> <text x="224" y="52">3</text> <text x="240" y="52">4</text> <text x="256" y="52">5</text> <text x="272" y="52">6</text> <text x="288" y="52">7</text> <text x="304" y="52">8</text> <text x="320" y="52">9</text> <text x="336" y="52">0</text> <text x="352" y="52">1</text> <text x="368" y="52">2</text> <text x="384" y="52">3</text> <text x="400" y="52">4</text> <text x="416" y="52">5</text> <text x="432" y="52">6</text> <text x="448" y="52">7</text> <text x="464" y="52">8</text> <text x="480" y="52">9</text> <text x="496" y="52">0</text> <text x="512" y="52">1</text> <text x="68" y="84">AT_PUB_ECDHE</text> <text x="172" y="84">Length</text> <text x="296" y="84">Value</text> </g> </svg> </artwork> </artset></figure><t>The fields are as follows:</t><t><list style="hanging"> <t hangText="AT_PUB_ECDHE"><vspace blankLines="1"/>This<dl newline="true" spacing="normal"> <dt>AT_PUB_ECDHE:</dt> <dd>This is set toTBA1 BY IANA.</t> <t hangText="Length"><vspace blankLines="1"/>The152 by IANA.</dd> <dt>Length:</dt> <dd>This is the length of the attribute, set as other attributes in EAP-AKA <xreftarget="RFC4187"/>.target="RFC4187" format="default"/>. The length is expressed in multiples of 4 bytes. The length includes the attribute type field, the Length field itself, and the Value field (along with anypadding). </t> <t hangText="Value"><vspace blankLines="1"/>Thispadding).</dd> <dt>Value:</dt> <dd> <t>This value is the sender's ECDHE public key. The value depends on the AT_KDF_FS attribute and is calculated asfollows: <list style="symbols">follows:</t> <ul spacing="normal"> <li> <t>For X25519, the length of this value is 32 bytes, encoded as specified in <xreftarget="RFC7748"/> Section 5.</t>target="RFC7748" sectionFormat="of" section="5"/>.</t> </li> <li> <t>For P-256, the length of this value is 33 bytes, encoded using the compressed form specified in Section 2.3.3 of <xreftarget="SEC1"/>.</t> </list> <vspace blankLines="1"/> Becausetarget="SEC1" format="default"/>.</t> </li> </ul> <t>Because the length of the attribute must be a multiple of 4 bytes, the sender pads the Value field with zero bytes when necessary. To retain the security of the keys, the senderSHALL<bcp14>SHALL</bcp14> generate a fresh value for each run of the protocol.</t></list></t></dd> </dl> </section> <section anchor="at_kdf_dh"title="AT_KDF_FS">numbered="true" toc="default"> <name>AT_KDF_FS</name> <t>The AT_KDF_FS attribute indicates the used or desiredforward secrecyFS key generation function, if theForward Secrecy (FS)FS extension is used. It will also indicate the used or desired ECDHE group. A new attribute is needed to carry this information, as AT_KDF carries the basic KDF valuewhichthat is still used together with theforward secrecyFS KDF value. The basic KDF value is also used by those EAP peers that cannot or do not want to use this extension.</t> <t>This document only specifies the behavior relating to the following combinations of basic KDF values andforward secrecyFS KDFvalues: Thevalues:</t> <ul> <li>the basic KDF value in AT_KDF is 1, as specified in <xreftarget="RFC5448"/>target="RFC5448" format="default"/> and <xreftarget="RFC9048"/>, and the forward secrecytarget="RFC9048" format="default"/> and</li> <li>the FS KDF values in AT_KDF_FS are 1 or 2, as specified below and in <xreftarget="kdf2"/>.</t>target="kdf2" format="default"/>.</li></ul> <t>Any future specifications that add either new basicKDFKDFs or newforward secrecyFS KDF values need to specify how they are treated and what combinations are allowed. This requirement is an update to how <xreftarget="RFC5448"/>target="RFC5448" format="default"/> and <xreftarget="RFC9048"/>target="RFC9048" format="default"/> may be extended in the future.</t> <t>The format of the AT_KDF_FS attribute is shown below.</t><figure><artset> <artwork type="ascii-art"align="center">align="center" name="" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_KDF_FS | Length | FS Key Derivation Function | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</artwork>]]></artwork> <artworktype="svg"><svgtype="svg" name="" align="left" alt=""><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="112" width="528" viewBox="0 0 528 112" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px"> <path d="M 8,64 L 8,96" fill="none" stroke="black"/> <path d="M 136,64 L 136,96" fill="none" stroke="black"/> <path d="M 264,64 L 264,96" fill="none" stroke="black"/> <path d="M 520,64 L 520,96" fill="none" stroke="black"/> <path d="M 8,64 L 520,64" fill="none" stroke="black"/> <path d="M 8,96 L 520,96" fill="none" stroke="black"/> <g class="text"> <text x="16" y="36">0</text> <text x="176" y="36">1</text> <text x="336" y="36">2</text> <text x="496" y="36">3</text> <text x="16" y="52">0</text> <text x="32" y="52">1</text> <text x="48" y="52">2</text> <text x="64" y="52">3</text> <text x="80" y="52">4</text> <text x="96" y="52">5</text> <text x="112" y="52">6</text> <text x="128" y="52">7</text> <text x="144" y="52">8</text> <text x="160" y="52">9</text> <text x="176" y="52">0</text> <text x="192" y="52">1</text> <text x="208" y="52">2</text> <text x="224" y="52">3</text> <text x="240" y="52">4</text> <text x="256" y="52">5</text> <text x="272" y="52">6</text> <text x="288" y="52">7</text> <text x="304" y="52">8</text> <text x="320" y="52">9</text> <text x="336" y="52">0</text> <text x="352" y="52">1</text> <text x="368" y="52">2</text> <text x="384" y="52">3</text> <text x="400" y="52">4</text> <text x="416" y="52">5</text> <text x="432" y="52">6</text> <text x="448" y="52">7</text> <text x="464" y="52">8</text> <text x="480" y="52">9</text> <text x="496" y="52">0</text> <text x="512" y="52">1</text> <text x="56" y="84">AT_KDF_FS</text> <text x="172" y="84">Length</text> <text x="284" y="84">FS</text> <text x="312" y="84">Key</text> <text x="372" y="84">Derivation</text> <text x="452" y="84">Function</text> </g> </svg> </artwork> </artset></figure><t>The fields are as follows:</t><t><list style="hanging"> <t hangText="AT_KDF_FS"><vspace blankLines="1"/>This<dl newline="true" spacing="normal"> <dt>AT_KDF_FS:</dt> <dd>This is set toTBA2 BY IANA.</t> <t hangText="Length"><vspace blankLines="1"/>The153 by IANA.</dd> <dt>Length:</dt> <dd>This is the length of theattribute, MUSTattribute; it <bcp14>MUST</bcp14> be set to1.</t> <t hangText="FS1.</dd> <dt>FS Key DerivationFunction"><vspace blankLines="1"/>AnFunction:</dt> <dd>This is an enumerated value representing theforward secrecy key derivation functionFS KDF that the server (or peer) wishes to use. See <xreftarget="kdf2"/>target="kdf2" format="default"/> for the functions specified in this document. Note:Thisthis field has a different name space than the similar field in the AT_KDF attributeKey Derivation FunctionKDF defined in <xreftarget="RFC9048"/>.</t> </list></t>target="RFC9048" format="default"/>.</dd> </dl> <t>ServersMUST<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.SoSo, for a set of AT_KDF_FS attributes, there is always only one AT_PUB_ECDHE attribute.</t> <!--[rfced] May we rephrase "taken into use"? While we see a couple of past instances in RFCs, we wonder if "will be used" has the same meaning or if there is another rephrase? Original: ...and is willing and able to use the extension defined in this document, the function is taken into use without any further negotiation. Perhaps: ...and is willing and able to use the extension defined in this document, the function will be used without any further negotiation. --> <t>Upon receiving a set of theseattributes: <list style="symbols"> <t>Ifattributes:</t> <ul spacing="normal"> <li>If the peer supports and is willing to use the FSKey Derivation FunctionKDF indicated by the first AT_KDF_FS attribute, and is willing and able to use the extension defined in this document, the function is taken into use without any furthernegotiation.</t> <t>Ifnegotiation.</li> <li>If the peer does not support this function or is unwilling to use it, it responds to the server with an indication that a different function is needed.SimilarlySimilarly, with the negotiation process defined in <xreftarget="RFC9048"/>target="RFC9048" format="default"/> for AT_KDF, the peer sends an EAP-Response/AKA'-Challenge message that contains only one attribute,AT_KDF_FSAT_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 AUTN had been incorrect and failing authentication (see Figure 3 of <xreftarget="RFC4187"/>).target="RFC4187" format="default"/>). The peerMUST<bcp14>MUST</bcp14> fail the authentication if there are any duplicate values within the list of AT_KDF_FS attributes (except where the duplication is due to a request to change the key derivation function; see below for furtherinformation).</t> <t>Ifinformation).</li> <li>If the peer does not recognize the extension defined in this document or is unwilling to use it, it ignores the AT_KDF_FSattribute.</t> </list></t>attribute.</li> </ul> <t>Upon receiving an EAP-Response/AKA'-Challenge message with an AT_KDF_FS attribute from the peer, the server checks that the suggested AT_KDF_FS value was one of the alternatives in its offer. The first AT_KDF_FS value in the message from the server is not a valid alternative. If the peer has replied with the first AT_KDF_FS value, the server behaves as if the AT_MAC of the response had been incorrect and fails the authentication. For an overview of the failed authentication process in the server side, see Section3<xref target="RFC4187" sectionFormat="bare" section="3"/> and Figure 2 in <xref target="RFC4187"/>. Otherwise, the server re-sends the EAP-Response/AKA'-Challenge message, but adds the selected alternative to the beginning of the list of AT_KDF_FSattributes,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 FSKey Derivation FunctionKDF is the only valid situation where such duplication may occur.</t> <t>When the peer receives the new EAP-Request/AKA'-Challenge message, itMUST<bcp14>MUST</bcp14> check that the requested change, and only the requestedchangechange, occurred in the list of AT_KDF_FS attributes. Ifyes,so, it continues. If not, it behaves as if AT_MAChad beenwere 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 peerMUST<bcp14>MUST</bcp14> behave as if AT_MAChad beenwere incorrect and fail the authentication.</t> </section> <section anchor="kdf2"title="Forwardnumbered="true" toc="default"> <name>Forward Secrecy Key DerivationFunctions">Functions</name> <t>Two new FSKey Derivation FunctionKDF 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 ofkey derivation function andKDF and, at the sametime selectstime, select an ECDHE group to be used.</t> <t>The FSKey Derivation FunctionKDF type value is only used in the AT_KDF_FS attribute. When theforward secrecyFS extension is used, the AT_KDF_FS attribute determines how to derive thekeys MK_ECDHE, K_re, MSK,MK_ECDHE key, K_re key, Master Session Key (MSK), andEMSK.Extended Master Session Key (EMSK). The AT_KDF_FS attribute should not be confused with the different range ofkey derivation functionsKDFs that can be represented in the AT_KDF attribute as defined in <xreftarget="RFC9048"/>.target="RFC9048" format="default"/>. When theforward secrecyFS extension is used, the AT_KDF attribute only specifies how to derive thekeys MK, K_encr,Master Key (MK), the K_encr key, andK_aut.</t>the K_aut key.</t> <t>Key derivation in this extension produces exactly the same keys for internal use within one authentication run as EAP-AKA' <xreftarget="RFC9048"/>target="RFC9048" format="default"/> does. For instance, the K_aut that is used in AT_MAC is still exactly as it was in EAP-AKA'. The only change to key derivation is in the re-authentication keys and keys exported out of the EAP method, MSK and EMSK. As a result, EAP-AKA' attributes such as AT_MAC continue to be usable even when this extension is in use.</t> <t>When the FSKey Derivation FunctionKDF field in the AT_KDF_FS attribute is set to 1 or 2 and the Key Derivation Function field in the AT_KDF attribute is set to 1, theMaster Key (MK)MK and accompanying keys are derived asfollows. <figure>follows: </t> <artworkalign="center">align="center" name="" type="" alt=""><![CDATA[ MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity) K_encr = MK[0..127] K_aut = MK[128..383] K_re = MK_ECDHE[0..255] MSK = MK_ECDHE[256..767] EMSK = MK_ECDHE[768..1279]</artwork> </figure></t>]]></artwork> <t>Requirements for how to securely generate, validate, and process the ephemeral public keys depend on the elliptic curve.</t> <t>ForP-256P-256, the SHARED_SECRET is the shared secret computed as specified in Section 5.7.1.2 of <xreftarget="SP-800-56A"/>.target="SP-800-56A" format="default"/>. Public key validation requirements are defined in Section 5 of <xreftarget="SP-800-56A"/>.target="SP-800-56A" format="default"/>. At least partialpublic-keypublic key validationMUST<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 <xreftarget="SEC1"/>.</t>target="SEC1" format="default"/>.</t> <t>ForX25519X25519, the SHARED_SECRET is the shared secret computed as specified inSection 6.1 of<xreftarget="RFC7748"/>.target="RFC7748" sectionFormat="of" section="6.1"/>. Both the peer and the serverMAY<bcp14>MAY</bcp14> check for the zero-value shared secret as specified inSection 6.1 of<xreftarget="RFC7748"/>.</t> <t><list style="empty"> <t>Note: Thetarget="RFC7748" sectionFormat="of" section="6.1"/>.</t> <aside><t>Note: If performed inappropriately, the way that the shared secret is tested for zerocan, if performed inappropriately,can provide an ability for attackers to listen to CPU power usage side channels. Refer to <xreftarget="RFC7748"/>target="RFC7748" format="default"/> for a description of how to perform this check in a way that it does not become aproblem.</t> </list></t>problem.</t></aside> <!--[rfced] Because "Authentication" is part of the expansion of "AKA'", may we cut it from the following for redundancy (or anywhere it follows this abbreviation)? Original: ...a party MUST behave as if the current EAP-AKA' authentication process starts again from the beginning. Perhaps: ...a party MUST behave as if the current EAP-AKA' process starts again from the beginning. --> <t>If validation of the other party's ephemeral public key or the shared secret fails, a partyMUST<bcp14>MUST</bcp14> behave as if the current EAP-AKA' authentication process starts again from the beginning.</t> <t>The rest of the computation proceeds as defined in <xref target="RFC9048" sectionFormat="of" section="3.3"/>.</t> <!--[rfced] We have some questions regarding the text below from Section3.36.3: i. This paragraph appears several paragraphs after the text it describes. Would it be helpful to have this paragraph appear closer to the notation it defines? Or to update from "of the notation used above" to instead use "of the notation used in Figure X" (and add a title to the text in the <figure> tags? ii. For readability, may we reformat the sentence as follows? Original: For readability, an explanation of<xref target="RFC9048"/>.</t>the notation used above is copied here: [n..m] denotes the substring from bit n to m. PRF' is a new pseudo-random function specified in [RFC9048]. K_encr is the encryption key, 128 bits, K_aut is the authentication key, 256 bits, K_re is the re-authentication key, 256 bits, MSK is the Master Session Key, 512 bits, and EMSK is the Extended Master Session Key, 512 bits. MSK and EMSK are outputs from a successful EAP method run [RFC3748]. Perhaps: For readability, an explanation of the notation used [in Figure X?] above is copied here: * [n..m] denotes the substring from bit n to m. * PRF' is a new pseudorandom function specified in [RFC9048]. * K_encr is the encryption key (128 bits). * K_aut is the authentication key (256 bits). * K_re is the re-authentication key (256 bits). * MSK is the Master Session Key (512 bits). * EMSK is the Extended Master Session Key (512 bits). Note: MSK and EMSK are outputs from a successful EAP method run [RFC3748]. --> <t>For readability, an explanation of the notation used above is copied here: [n..m] denotes the substring from bit n to m. PRF' is a newpseudo-randompseudorandom function specified in <xreftarget="RFC9048"/>.target="RFC9048" format="default"/>. K_encr is the encryption key, 128 bits, K_aut is the authentication key, 256 bits, K_re is the re-authentication key, 256 bits, MSK is the Master Session Key, 512 bits, and EMSK is the Extended Master Session Key, 512 bits. MSK and EMSK are outputs from a successful EAP method run <xreftarget="RFC3748"/>.</t>target="RFC3748" format="default"/>.</t> <t>CK and IK are produced by the AKA algorithm. IK' and CK' are derived as specified in <xreftarget="RFC9048"/>target="RFC9048" format="default"/> from IK and CK.</t> <t>The value "EAP-AKA'" is aneight-characters-longASCIIstring.string that is 8 characters long. It is used as is, without any trailing NUL characters. Similarly, "EAP-AKA' FS" is aneleven-characters-longASCIIstring,string that is 11 characters long, also used as is.</t> <t>Identity is the peer identity as specified inSection 7 of<xreftarget="RFC4187"/>.target="RFC4187" sectionFormat="of" section="7"/>. A privacy-friendly identifier <xreftarget="RFC9048"/> SHALLtarget="RFC9048" format="default"/> <bcp14>SHALL</bcp14> be used.</t> </section> <section anchor="groups"title="ECDHE Groups">numbered="true" toc="default"> <name>ECDHE Groups</name> <t>The selection of suitable groups for the elliptic curve computation is necessary. The choice of a group is made at the same time asdecidingthe decision to useofa particularkey derivation functionKDF inAT_KDF_FS.</t>the AT_KDF_FS attribute.</t> <t>For "EAP-AKA' with ECDHE andX25519"X25519", the group is the Curve25519 group specified in <xreftarget="RFC7748"/>.target="RFC7748" format="default"/>. The support for this group isREQUIRED.</t><bcp14>REQUIRED</bcp14>.</t> <t>For "EAP-AKA' with ECDHE andP-256"P-256", the group is the NIST P-256 group (SEC group secp256r1), specified in Section 3.2.1.3 of <xreftarget="SP-800-186"/>target="SP-800-186" format="default"/> oralternativelyalternatively, Section 2.4.2 of <xreftarget="SEC2"/>.target="SEC2" format="default"/>. The support for this group isREQUIRED.</t><bcp14>REQUIRED</bcp14>.</t> <t>The term "support" here means that the groupMUST<bcp14>MUST</bcp14> be implemented.</t> </section> <sectiontitle="Message Processing" anchor="secMessageProc">anchor="secMessageProc" numbered="true" toc="default"> <name>Message Processing</name> <t>This section specifies the changes related to message processing when this extension is used in EAP-AKA'. It specifies when a message may be transmitted or accepted, which attributes are allowed in a message, which attributes are required in a message, and other message-specific details, where those details are different for this extension than the base EAP-AKA' or EAP-AKA protocol. Unless otherwise specified here, the rules from <xreftarget="RFC9048"/>target="RFC9048" format="default"/> or <xreftarget="RFC4187"/>target="RFC4187" format="default"/> apply.</t> <sectiontitle="EAP-Request/AKA'-Identity"> <t>Nonumbered="true" toc="default"> <!--[rfced] Many of the subsections in Section 6.5 (Message Processing) start with "No changes" (see some examples below). For clarity, would it aid the reader to provide some additional context in these sections? Original: 6.5.1. EAP-Request/AKA'-Identity No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes MUST NOT be added to this message. 6.5.11. EAP-Response/AKA'-Notification No changes. Perhaps: 6.5.1. EAP-Request/AKA'-Identity There are no changes for the EAP-Request/AKA'-Identity, except that the... 6.5.11. EAP-Response/AKA'-Notification There are no changes for the EAP-Response/AKA'-Notification. --> <name>EAP-Request/AKA'-Identity</name> <t>No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributes <bcp14>MUST NOT</bcp14> be added to this message. The appearance of these attributes in a received messageMUST<bcp14>MUST</bcp14> be ignored.</t> </section> <sectiontitle="EAP-Response/AKA'-Identity">numbered="true" toc="default"> <name>EAP-Response/AKA'-Identity</name> <t>No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributesMUST NOT<bcp14>MUST NOT</bcp14> be added to this message. The appearance of these attributes in a received messageMUST<bcp14>MUST</bcp14> be ignored. The peer identifierSHALL<bcp14>SHALL</bcp14> comply with the privacy-friendly requirements of <xreftarget="RFC9190"/>.target="RFC9190" format="default"/>. An example of a compliant way of constructing a privacy-friendly peer identifier is using a non-NULL SUCI <xreftarget="TS.33.501"/>.target="TS.33.501" format="default"/>. </t> </section> <section anchor="procakachall"title="EAP-Request/AKA'-Challenge">numbered="true" toc="default"> <name>EAP-Request/AKA'-Challenge</name> <t>The server sends the EAP-Request/AKA'-Challenge on full authentication as specified by <xreftarget="RFC4187"/>target="RFC4187" format="default"/> and <xreftarget="RFC9048"/>.target="RFC9048" format="default"/>. The attributes AT_RAND, AT_AUTN, and AT_MACMUST<bcp14>MUST</bcp14> be included and checked on reception as specified in <xreftarget="RFC4187"/>.target="RFC4187" format="default"/>. They are also necessary for backwards compatibility.</t> <t>In the EAP-Request/AKA'-Challenge, there is no message-specific data covered by the MAC for the AT_MAC attribute. The AT_KDF_FS and AT_PUB_ECDHE attributesMUST<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 peerMUST<bcp14>MUST</bcp14> treat it as if neither one wassent,sent andtheassume that the extension defined in this document is not in use.</t> <t>The AT_RESULT_IND, AT_CHECKCODE, AT_IV, AT_ENCR_DATA, AT_PADDING, AT_NEXT_PSEUDONYM,AT_NEXT_REAUTH_IDAT_NEXT_REAUTH_ID, and other attributes may be included as specified inSection 9.3 of<xreftarget="RFC4187"/>.</t>target="RFC4187" sectionFormat="of" section="9.3"/>.</t> <t>When processing this message, the peerMUST<bcp14>MUST</bcp14> process AT_RAND, AT_AUTN, AT_KDF_FS, and AT_PUB_ECDHE before processing other attributes.OnlyThe peer derives keys and verifies AT_MAC only if these attributes are verified to bevalid, the peer derives keys and verifies AT_MAC.valid. If the peer is unable or unwilling to perform the extension specified in this document, it proceeds as defined in <xreftarget="RFC9048"/>.target="RFC9048" format="default"/>. Finally, if there is anerrorerror, seeSection 6.3.1. of<xreftarget="RFC4187"/>.</t>target="RFC4187" sectionFormat="of" section="6.3.1"/>.</t> </section> <section anchor="procakachallresp"title="EAP-Response/AKA'-Challenge">numbered="true" toc="default"> <name>EAP-Response/AKA'-Challenge</name> <t>The peer sends an EAP-Response/AKA'-Challenge in response to a valid EAP-Request/AKA'-Challenge message, as specified by <xreftarget="RFC4187"/>target="RFC4187" format="default"/> and <xreftarget="RFC9048"/>.target="RFC9048" format="default"/>. If the peer supports and is willing to perform the extension specified in this protocol, and the server had made a valid request involving the attributes specified in <xreftarget="procakachall"/>,target="procakachall" format="default"/>, the peer responds per the rules specified below. Otherwise, the peer responds as specified in <xreftarget="RFC4187"/>target="RFC4187" format="default"/> and <xreftarget="RFC9048"/>target="RFC9048" format="default"/> and ignores the attributes related to this extension. If the peer has not received attributes related to this extension from the Server, and has a policy that requires it to always use this extension, it behaves as if AUTNhad beenwere incorrect and fails the authentication.</t> <t>The AT_MAC attributeMUST<bcp14>MUST</bcp14> be included and checked as specified in <xreftarget="RFC9048"/>.target="RFC9048" format="default"/>. In the EAP-Response/AKA'-Challenge, there is no message-specific data covered by the MAC. The AT_PUB_ECDHE attributeMUST<bcp14>MUST</bcp14> beincluded,included and carries the peer's public Diffie-Hellman key.</t> <t>The AT_RES attributeMUST<bcp14>MUST</bcp14> be included and checked as specified in <xreftarget="RFC4187"/>.target="RFC4187" format="default"/>. When processing this message, the ServerMUST<bcp14>MUST</bcp14> process AT_RES before processing other attributes. The Server derives keys and verifies AT_MAC only when this attribute is verified to be valid.</t> <t>If the Server has proposed the use of the extension specified in this protocol, but the peer ignores and continues the basic EAP-AKA' authentication, the Server makes a policy decision of whether this is allowed. If this is allowed, it continues the EAP-AKA' authentication to completion. If it is not allowed, the ServerMUST<bcp14>MUST</bcp14> behave as if authentication failed.</t> <t>The AT_CHECKCODE, AT_RESULT_IND, AT_IV,AT_ENCR_DATAAT_ENCR_DATA, and other attributes may be included as specified inSection 9.4 of<xreftarget="RFC4187"/>.</t>target="RFC4187" sectionFormat="of" section="9.4"/>.</t> </section> <section anchor="reauth"title="EAP-Request/AKA'-Reauthentication">numbered="true" toc="default"> <name>EAP-Request/AKA'-Reauthentication</name> <t>No changes, but note that the re-authentication process uses the keys generated in the original EAP-AKA' authentication,which,which employs key material from the Diffie-Hellman procedure if the extension specified in this document is inuse, employs key material from the Diffie-Hellman procedure.</t>use.</t> </section> <sectiontitle="EAP-Response/AKA'-Reauthentication">numbered="true" toc="default"> <name>EAP-Response/AKA'-Reauthentication</name> <t>No changes, but as discussed in <xreftarget="reauth"/>,target="reauth" format="default"/>, re-authentication is based on the key material generated by EAP-AKA' and the extension defined in this document.</t> </section> <sectiontitle="EAP-Response/AKA'-Synchronization-Failure">numbered="true" toc="default"> <name>EAP-Response/AKA'-Synchronization-Failure</name> <t>No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributesMUST NOT<bcp14>MUST NOT</bcp14> be added to this message. The appearance of these attributes in a received messageMUST<bcp14>MUST</bcp14> be ignored.</t> </section> <sectiontitle="EAP-Response/AKA'-Authentication-Reject">numbered="true" toc="default"> <name>EAP-Response/AKA'-Authentication-Reject</name> <t>No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributesMUST NOT<bcp14>MUST NOT</bcp14> be added to this message. The appearance of these attributes in a received messageMUST<bcp14>MUST</bcp14> be ignored.</t> </section> <sectiontitle="EAP-Response/AKA'-Client-Error">numbered="true" toc="default"> <name>EAP-Response/AKA'-Client-Error</name> <t>No changes, except that the AT_KDF_FS or AT_PUB_ECDHE attributesMUST NOT<bcp14>MUST NOT</bcp14> be added to this message. The appearance of these attributes in a received messageMUST<bcp14>MUST</bcp14> be ignored.</t> </section> <sectiontitle="EAP-Request/AKA'-Notification">numbered="true" toc="default"> <name>EAP-Request/AKA'-Notification</name> <t>No changes.</t> </section> <sectiontitle="EAP-Response/AKA'-Notification">numbered="true" toc="default"> <name>EAP-Response/AKA'-Notification</name> <t>No changes.</t> </section> </section> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <!--[rfced] Is "changes to security considerations as they differ" clear to the reader? Maybe a rephrase of this paragraph would be helpful? Original: This section deals only with the changes to security considerations as they differ from EAP-AKA', or as new information has been gathered since the publication of [RFC9048]. Perhaps: This section deals only with changes to security considerations for EAP-AKA' or new information that has been gathered since the publication of [RFC9048]. --> <t>This section deals only with the changes to security considerations as they differ from EAP-AKA', or as new information has been gathered since the publication of <xreftarget="RFC9048"/>.</t>target="RFC9048" format="default"/>.</t> <t>As discussed in <xreftarget="sec:intro"/>, forward secrecytarget="sec_intro" format="default"/>, FS is an important countermeasure against adversaries who gain access tothelong-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 alreadyoccurred,occurred and that we need to minimize the impact of these breaches (see <xreftarget="NSA-ZT"/>target="NSA-ZT" format="default"/> and <xreftarget="NIST-ZT"/>.target="NIST-ZT" format="default"/>). One type of breach is key compromise or key exfiltration.</t><t>If<!--[rfced] FYI - For readability, we have updated the text below as follows. Please confirm that 5G-AKA and EAP-AKA' are two separate mechanisms and that the updates to "both" in the final sentence retain your meaning. Original: If a mechanism without ephemeral key exchange such as (5G-AKA,EAP-AKA')EAP- AKA') is used the effects of key compromise are devastating. There are serious consequences of not properly providing forward secrecy for the key establishment. For both control and user plane, and both directions:<list style="numbers">Current: 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 forward secrecy for the key establishment, for the control plane and the user plane, and for both directions: --> <t>If a mechanism without ephemeral key exchange (such as 5G-AKA or EAP-AKA') is used, the effects of key compromise are devastating. There are serious consequences to not properly providing FS for the key establishment, for the control plane and the user plane, and for both directions: </t> <ol spacing="normal" type="1"><li> <t>An attacker can decrypt 5G communication that they previously recorded.</t> </li> <li> <t>A passive attacker can eavesdrop (decrypt) all future 5G communication.</t> </li> <li> <t>An active attacker can impersonate theUEUser Equipment (UE) or the Network and inject messages in an ongoing 5G connection between the real UE and the real network.</t></list> </t> <t>Best</li> </ol> <t>At the time of writing, best practice securitytodayis to mandateforward secrecyFS (as is done inWPA3,Wi-Fi Protected Access 3 (WPA3), EAP-TLS 1.3, EAP-TTLS 1.3,IKEv2, SSH,Internet Key Exchange Protocol Version 2 (IKEv2), Secure Shell (SSH), QUIC, WireGuard, Signal, etc.).ItIn deployments, it is recommended thatin deployments,EAP-AKA methods withoutforward secrecyFS be phased out in the long term.</t><t>This<!--[rfced] We had a few questions/comments about the fifth paragraph of the Security Considerations section: a) This use of the slash character being clarified would be helpful to the reader as well as avoid subject/verb agreement issues. Original: This extensionprovideis most useful when used in a context where the MSK/EMSK are used in protocols not providing forward secrecy. Perhaps: This extension is most useful when implemented in a context where the MSK [and, or, and/or?] EMSK are used in protocols not providing FS. b) Clarifying what "this property" refers to might be helpufl to the reader. Also, rephrasing the clause that begins with "so better characteristics..." might avoid a possible need to re-read since "characteristics" seems not to match with "is" for subject/verb agreement. Original: For instance, if used with IKEv2 [RFC7296], the session keys produced by IKEv2 have this property, so better characteristics of the MSK and EMSK is not that useful. c) Please confirm this use of "forward secure" instead of "forward secrecy" there are two other similar instances in the document (we also see "forward secret"). We will assume they were intended unless we hear otherwise. Original: However, typical link layer usage of EAP does not involve running another, forward secure, key exchange. --> <t>The FS extension provides assistance against passive attacks from attackers that have compromised the key material on USIM cards. Passive attacks are attractive for attackers performinglarge scalelarge-scale pervasive monitoring as they requiremuch lessfar fewer resources and are much harder to detect. The extension also provides protection against active attacks as the attacker is forced to beon pathon-path during the AKA run and subsequent communication between the parties. Withoutforward secrecyFS, an active attacker that has compromised the long-term key can inject messages inana connection between the real Peer and the real server without beingon path.on-path. This extension is most useful whenusedimplemented in a context where the MSK/EMSK are used in protocols not providingforward secrecy.FS. For instance, if used with IKEv2 <xreftarget="RFC7296"/>,target="RFC7296" format="default"/>, the session keys produced by IKEv2 have this property, so better characteristics of the MSK and EMSK is not that useful. However, typicallink layerlink-layer usage of EAP does not involve running another, forward secure, key exchange. Therefore, using EAP to authenticate access to a network is one situation where the extension defined in this document can be helpful.</t><t>This<t>The FS extension generates keying 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 aredestroyed, evendestroyed. 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 abrute forcebrute-force search of the session key space.</t> <t>Even if a compromise of the long-term keys has occurred, FS is still provided for all future sessions, as long as the attacker does not become an active attacker.</t> <!--[rfced] How may we update this run-on sentence below? Original: The extension does not provide protection against active attackers with access to the long-term key that mount an on-path attack on future EAP-AKA' runs will be able to eavesdrop on the traffic protected by the resulting session key(s). Perhaps: 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). --> <t>The extension does not provide protection against active attackers with access to the long-term key that mount an on-path attack on future EAP-AKA' runs will be able to eavesdrop on the traffic protected by the resulting session key(s). Still, past sessions where FS was in use remain protected.</t> <t>Using EAP-AKA' FS once providesforward secrecy. Forward secrecyFS. FS limits the effect of key leakage in one direction (compromise of a key at time T2 does not compromise some key at time T1 where T1 < T2). Protection in the other direction (compromise at time T1 does not compromise keys at time T2) can be achieved by rerunning ECDHE frequently. If a long-term authentication key has been compromised, rerunning EAP-AKA' FS gives protection against passive attackers. Using the terms in <xreftarget="RFC7624"/>, forward secrecytarget="RFC7624" format="default"/>, FS without rerunning ECDHE does not stop an attacker from doing static key exfiltration. Frequently rerunning EC(DHE) forces an attacker to do dynamic key exfiltration (or content exfiltration).</t> <sectiontitle="Deployment Considerations">numbered="true" toc="default"> <name>Deployment Considerations</name> <t>Achieving FS requiresthatthat, when a connection is closed, each endpointMUST<bcp14>MUST</bcp14> destroy not only the ephemeral keys used by the connection but also any information that could be used to recompute those keys.</t> <t>Similarly, other parts of the system matter. For instance, when the keys generated by EAP are transported to a pass-through authenticator, such transport must also provide forward secure encryption with respect to the long-term keys used to establish its security. Otherwise, an adversary may attack the transport connection used to carry keys from EAP, and use this method to gain access to current and past keys from EAP,whichwhich, inturnturn, would lead to the compromise of anything protected by those EAP keys.</t> <t>Of course, these considerations apply to any EAP method, not only this one.</t> </section> <sectiontitle="Security Properties">numbered="true" toc="default"> <name>Security Properties</name> <t>The following security properties of EAP-AKA' are impacted through thisextension: <list style="hanging"> <t hangText="Protectedextension:</t> <dl newline="true" spacing="normal"> <dt>Protected ciphersuitenegotiation"><vspace blankLines="1"/> EAP-AKA'negotiation:</dt> <dd> <t>EAP-AKA' has a negotiation mechanism for selecting thekey derivation functions,KDFs, and this mechanism has been extended by the extension specified in this document. The resulting mechanism continues to be secure againstbidding down attacks. <vspace blankLines="1"/> Therebidding-down attacks.</t> <t>There are two specific needs in the negotiationmechanism: <list style="hanging"> <t hangText="Negotiating key derivation functionmechanism:</t> <dl newline="true" spacing="normal"> <dt>Negotiating KDFs within theextension"><vspace blankLines="1"/>extension:</dt> <dd> The negotiation mechanism allows changing the offeredkey derivation function,KDF, but the change is visible in the finalEAP- Request/AKA'-ChallengeEAP-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 offerwas.</t> <t hangText="Negotiatingwas.</dd> <dt>Negotiating the use of thisextension"><vspace blankLines="1"/>extension:</dt> <dd> <t> This extension is offered by the server through presenting the AT_KDF_FS and AT_PUB_ECDHE attributes in the EAP-Request/AKA'-Challenge message. These attributes are protected by AT_MAC, so attempts to change or omit them by an adversary will bedetected.<vspace blankLines="1"/>detected.</t> <!--[rfced] The sentence below introduces a new paragraph, but is missing a lead-in clause with a subject. How may we adjust? Original: Except of course, if the adversary holds the long-term key and is willing to engage in an active attack.SuchPerhaps: These attempts will be detected, except of course, if the adversary holds the long-term key and is willing to engage in anattack can, foractive attack. --> <t> 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 capabilitieswillwill, in anycasecase, 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 theintroduction,Introduction, even an attacker with access to the long-term keys is required to beon pathon-path on each AKA run and subsequent communication, which makes mass surveillance more laborious.<vspace blankLines="1"/></t> <t> The security properties of the extension also depend on a policy choice. As discussed in <xreftarget="procakachallresp"/>,target="procakachallresp" format="default"/>, both the peer and the server make a policy decision of what to do when it was willing to perform the extension specified in this protocol, but the other side does not wish to use the extension. Allowing this has the benefit of allowing backwards compatibility to equipment that did not yet support the extension. When the extension is not supported or negotiated by the parties, no FS can obviously be provided.<vspace blankLines="1"/></t> <t> If turning off the extension specified in this protocol is not allowed by policy, the use of legacy equipment that does not support this protocol is no longer possible. This may be appropriate when, for instance, support for the extension is sufficientlywidespread,widespread or required in a particular version of a mobilenetwork.</t> </list></t> <t hangText="Key derivation"><vspace blankLines="1"/>network. </t> </dd> </dl> </dd> <dt>Key derivation:</dt> <dd> This extension providesforward secrecy.FS. As described in several places in this specification, this can be roughly summarized asthatfollows: 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-Hellmankeys, and hencekeys; hence, they continue to be equally safe againstexposeexposure of the long-term key as the originalauthentication.</t> </list></t>authentication.</dd> </dl> </section> <sectiontitle="Denial-of-Service">numbered="true" toc="default"> <!--[rfced] Is it odd to begin a section with "In addition"? Please consider if further information should be added here. Original: 7.3. Denial-of-Service In addition, it is worthwhile to discuss Denial-of-Service attacks and their impact on this protocol. The calculations involved in public key cryptography require co --> <name>Denial of Service</name> <t>In addition, 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 ofDenial-of-ServiceDoS attacks are always possible, the following factors help mitigate the concerns relating to public key cryptography and EAP-AKA' FS.<list style="symbols"></t> <ul spacing="normal"> <li> <t>In a 5G context, other parts of the connection setup involve public key cryptography, so while performing additional operations in EAP-AKA' is an additional concern, it does not change the overall situation. As a result, the relevant system components need to be dimensioned appropriately, and detection and management mechanisms to reduce the effect of attacks need to be in place.</t> </li> <!--[rfced] Is this an accurate rephrase of this text? Original: * This specification is constructed so that a separation between the USIM and Peer on client side and the Server and AD on network side is possible. This ensures that the most sensitive (or legacy) system components cannot be the target of the attack. For instance, EAP-AKA' and public key cryptography takes place in the phone and not the low-power USIM card. Perhaps: * 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. --> <li> <t>This specification is constructed so that a separation between the USIM and Peer on the client side and the Server and AD on the network side is possible. This ensures that the most sensitive (or legacy) system components cannot be the target of the attack. For instance, EAP-AKA' and public key cryptography takes place in the phone and not the low-power USIM card.</t> </li> <li> <t>EAP-AKA' has been designed so that the first actual message in the authentication process comes from the Server, and that this message will not be sent unless the user has been identified as an active subscriber of the operator in question. While the initial identity can be spoofed before authentication has succeeded, this reduces the efficiency of an attack.</t> </li> <li> <t>Finally, this memo specifies an order in which computations and checks must occur.WhenFor instance, when processing the EAP-Request/AKA'-Challenge message,for instance,the AKA authentication must be checked and succeed before the peer proceeds to calculating or processing theFS relatedFS-related parameters (see <xreftarget="procakachallresp"/>).target="procakachallresp" format="default"/>). The same is true of an EAP-Response/AKA'-Challenge (see <xreftarget="procakachallresp"/>).target="procakachallresp" format="default"/>). This ensures that the parties need to show possession of the long-term key in some way, and only then will the FS calculations become active. This limits theDenial-of-ServiceDoS 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 attacksare (a) limitedare:</t> <ol type="a"><li>limited in terms of subscribers they control,and (b) identifiableand</li> <li>identifiable for the purposes of blocking the affectedsubscribers.</t> </list></t>subscribers.</li></ol> </li> </ul> </section> <sectiontitle="Identity Privacy">numbered="true" toc="default"> <name>Identity Privacy</name> <t>As specified in <xreftarget="secMessageProc"/>,target="secMessageProc" format="default"/>, the peer identity sent in the Identity Response message needs to follow the privacy-friendly requirements in <xreftarget="RFC9190"/>.</t>target="RFC9190" format="default"/>.</t> </section> <section anchor="unp"title="Unprotectednumbered="true" toc="default"> <name>Unprotected Data andPrivacy">Privacy</name> <t>Unprotected data and metadata can reveal sensitive information and need to be selected with care. In particular, this applies to AT_KDF, AT_KDF_FS, AT_PUB_ECDHE, and AT_KDF_INPUT. AT_KDF, AT_KDF_FS, and AT_PUB_ECDHE reveal the used cryptographicalgorithms,algorithms; if these depend on the peeridentityidentity, they leak information about the peer. AT_KDF_INPUT reveals the network name, although that is done on purpose to bind the authentication to a particular context.</t> <t>An attacker observing network traffic may use the above types of information for traffic flow analysis or to track an endpoint.</t> </section> <sectiontitle="Forwardnumbered="true" toc="default"> <name>Forward Secrecy withinAT_ENCR"> <t>TheyAT_ENCR</name> <t>The keys K_encr and K_aut are calculated and used before the shared secret from the ephemeral key exchange is available.</t> <!--[rfced] "MAC" appears to be used as a verb in the sentence below. Are any adjustments needed? Original: K_encr and K_aut are used to encrypt and MAC data in the EAP-Req/ AKA'-Challenge message... --> <t>K_encr and K_aut are used to encrypt and MAC data in the EAP-Req/AKA'-Challenge message, especially the DHg^xg<sup>x</sup> ephemeral pub key. At thatpointpoint, the server does not yet have the correspondingg^yg<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>For K_encr though,<t>However, for K_encr, none of the encrypted data sent in the EAP-Req/AKA'-Challenge message in the AT_ENCR attribute will be a forward secret. That data may include re-authentication pseudonyms, so an adversary compromising the long-term key would be able to link re-authenticationprotocol-runsprotocol 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 fullauthentactionauthentication runs. If thepseudonumpseudonym linkage risk is not acceptable, one way to avoid the linkage is to always require full EAP-AKA' authentication.</t> </section> <sectiontitle="Post-Quantum Considerations">numbered="true" toc="default"> <name>Post-Quantum Considerations</name> <t>As of the publication of this document, it is unclear when or even if a quantum computer of sufficient size and power to exploitelliptic curve cryptographyECC will exist. Deployments that need to consider risks decades into the future should transition toPost- QuantumPost-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 toElliptic Curve Cryptography (ECC)ECC, and the data sizes could be problematic for some constrained systems. If a Cryptographically Relevant Quantum Computer (CRQC) isbuiltbuilt, it could recover the SHARED_SECRET from the ECDHE public keys.</t><t>This<t>However, this would not affect the ability ofEAP-AKA' -EAP-AKA', with or without thisextension -extension, to authenticateproperly, however.properly. As symmetric key cryptography is safe even if CRQCs are built, an adversary still will not be able to disrupt authentication as it requires computing a correct AT_MAC value. This computation requires the K_autkeykey, which is based onMK and, ultimately, CK'MK, CK', and IK', but not SHARED_SECRET.</t> <t>Other output keys do include SHARED_SECRET via MK_ECDHE, but they still includealsoCK' andIK'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> <!--[rfced] Might the following rephrase be acceptable? Original: This document does not add such algorithms, but a future update can do that. Perhaps: Adding such algorithms is out of scope for this document. --> <t>However, if the adversary has also obtained knowledge of the long-term key, they could then compute CK', IK',andSHARED_SECRET, and any derived output keys. This means that the introduction of a powerful enough quantum computer would disable this protocol extension's ability to provide the forward security capability. This would make it necessary to update the current ECC algorithms in this document to PQC algorithms. This document does not add such algorithms, but a future update can do that. </t> <t>Symmetric algorithms used in EAP-AKA'FSFS, such as HMAC-SHA-256 and the algorithmsuseused to generate AT_AUTN andAT_RESAT_RES, are practically secure against evenlargelarge, 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), includingPost-Quantum Cryptography (PQC)PQC KEMs, can be specified in the future. While the key exchange is specified with terms of the Diffie-Hellman protocol, the key exchange adheres to a KEM interface. AT_PUB_ECDHE would then contain either the ephemeral public key of the server or the SHARED_SECRET encapsulated with the server's public key. Note that the use of a KEM might require otherchangeschanges, 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> <sectiontitle="IANA Considerations">numbered="true" toc="default"> <name>IANA Considerations</name> <t>This extension of EAP-AKA' shares its attribute space and subtypes withExtensiblethe "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules(EAP-SIM)(EAP-SIM)" <xreftarget="RFC4186"/>,target="RFC4186" format="default"/>, EAP-AKA <xreftarget="RFC4187"/>,target="RFC4187" format="default"/>, and EAP-AKA' <xreftarget="RFC9048"/>.</t> <t>Twotarget="RFC9048" format="default"/>.</t> <t>IANA has assigned two new values(TBA1, TBA2) in the skippable range need to be assigned for AT_PUB_ECDHE (<xref target="at_pub_dh"/>) and AT_KDF_FS (<xref target="at_kdf_dh"/>)in the "AttributeTypes"Types (Skippable Attributes 128-255)" registry under the "EAP-AKA and EAP-SIM Parameters"group.</t> <t>Also, IANA is requested to create a new registrygroup as follows:</t> <dl> <dt>152:</dt><dd>AT_PUB_ECDHE (<xref target="at_pub_dh" format="default"/>)</dd> <dt>153:</dt><dd>AT_KDF_FS (<xref target="at_kdf_dh" format="default"/>)</dd> </dl> <t>IANA has also created the "EAP-AKA' AT_KDF_FS Key Derivation Function Values" registry to represent FSKey Derivation FunctionKDF types. The "EAP-AKA' with ECDHE and X25519" and "EAP-AKA' with ECDHE and P-256" types (1 and 2, see <xreftarget="kdf2"/>) need to betarget="kdf2" format="default"/>) have been assigned, along with one reserved value. The initial contents of this registryisare illustrated in <xreftarget="iana-fs-values"/>;target="iana-fs-values" format="default"/>; new values can be created through the Specification Required policy <xreftarget="RFC8126"/>.target="RFC8126" format="default"/>. Expert reviewers should ensure that the referenced specification is clearly identified andstable,stable and that the proposed addition is reasonable for the given category of allocation. </t> <table anchor="iana-fs-values"><name>Initial Content of the EAP-AKA'<name>EAP-AKA' AT_KDF_FS Key Derivation Function ValuesRegistry</name>Registry Initial Contents</name> <thead> <tr> <th align="left">Value</th> <th align="left">Description</th> <th align="left">Reference</th> </tr> </thead> <tbody> <tr> <td align="left">0</td> <td align="left">Reserved</td> <tdalign="left">[TBD BY IANA: THIS RFC]</td>align="left">RFC 9678</td> </tr> <tr> <td align="left">1</td> <td align="left">EAP-AKA' with ECDHE and X25519</td> <tdalign="left">[TBD BY IANA: THIS RFC]</td>align="left">RFC 9678</td> </tr> <tr> <td align="left">2</td> <td align="left">EAP-AKA' with ECDHE and P-256</td> <tdalign="left">[TBD BY IANA: THIS RFC]</td>align="left">RFC 9678</td> </tr> <tr> <td align="left">3-65535</td> <td align="left">Unassigned</td> <tdalign="left">[TBD BY IANA: THIS RFC]</td>align="left">RFC 9678</td> </tr> </tbody> </table> </section> </middle> <back><references title="Normative References"> <?rfc include="reference.RFC.2119.xml"?> <?rfc include="reference.RFC.3748.xml"?> <?rfc include="reference.RFC.4187.xml"?> <?rfc include="reference.RFC.5448.xml"?> <?rfc include="reference.RFC.7624.xml"?> <?rfc include="reference.RFC.7748.xml"?> <?rfc include="reference.RFC.8126.xml"?> <?rfc include="reference.RFC.8174.xml"?> <?rfc include="reference.RFC.9048.xml"?><references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4187.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5448.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7624.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9048.xml"/> <referenceanchor="SP-800-186">anchor="SP-800-186" target="https://doi.org/10.6028/NIST.SP.800-186"> <front> <title>Recommendations for Discrete Logarithm-based Cryptography: Elliptic Curve Domain Parameters</title><author> <organization>NIST</organization><author initials="L." surname="Chen"> <organization>National Institute of Standards and Technology</organization> </author> <author initials="D." surname="Moody"/> <author initials="K." surname="Randall"/> <author initials="A." surname="Regenscheid"/> <author initials="A." surname="Robinson"/> <date month="February"year='2023'/>year="2023"/> </front> <seriesInfo name="NIST"value="Special Publicationvalue="SP 800-186"/><format type='HTML' target='https://doi.org/10.6028/NIST.SP.800-186'/><seriesInfo name="DOI" value="10.6028/NIST.SP.800-186"/> </reference> <referenceanchor="SEC1">anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf"> <front> <title>SEC 1: Elliptic Curve Cryptography</title> <author><organization>Certicom Research</organization><organization>Standards for Efficient Cryptography</organization> </author> <date month="May"year='2009'/>year="2009"/> </front><seriesInfo name="Standards for Efficient Cryptography 1 (SEC 1)" value="Version 2.0" /> <format type='HTML' target='https://www.secg.org/sec1-v2.pdf'/><refcontent>Version 2.0</refcontent> </reference> <referenceanchor="SEC2">anchor="SEC2" target="https://www.secg.org/sec2-v2.pdf"> <front> <title>SEC 2: Recommended Elliptic Curve Domain Parameters</title> <author><organization>Certicom Research</organization><organization>Standards for Efficient Cryptography</organization> </author> <date month="January"year='2010'/>year="2010"/> </front><seriesInfo name="Standards for Efficient Cryptography 2 (SEC 2)" value="Version 2.0" /> <format type='HTML' target='https://www.secg.org/sec2-v2.pdf'/><refcontent>Version 2.0</refcontent> </reference> <reference anchor="SP-800-56A" target="https://doi.org/10.6028/NIST.SP.800-56Ar3"> <front> <title>Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography</title> <author initials="E." surname="Barker"><organization></organization><organization>National Institute of Standards and Technology</organization> </author> <author initials="L." surname="Chen"><organization></organization><organization/> </author> <author initials="A." surname="Roginsky"><organization></organization><organization/> </author> <author initials="A." surname="Vassilev"><organization></organization><organization/> </author> <author initials="R." surname="Davis"><organization></organization><organization/> </author> <date year="2018" month="April"/> </front> <seriesInfo name="NIST"value="Special Publication 800-56A Revision 3"/>value="SP 800-56A"/> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar3"/> </reference> </references><references title="Informative References"> <?rfc include="reference.RFC.4186.xml"?> <?rfc include="reference.RFC.5216.xml"?> <?rfc include="reference.RFC.7258.xml"?> <?rfc include="reference.RFC.7296.xml"?> <?rfc include="reference.RFC.9190.xml"?><references> <name>Informative References</name> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4186.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5216.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7258.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7296.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9190.xml"/> <referenceanchor="TrustCom2015">anchor="TrustCom2015" target="https://doi.org/10.1109/Trustcom.2015.506"> <front> <title>A USIMcompatibleCompatible 5G AKAprotocolProtocol withperfect forward secrecy</title>Perfect Forward Secrecy</title> <author initials="J."surname="Arkko"></author>surname="Arkko"/> <author initials="K."surname="Norrman"></author>surname="Norrman"/> <author initials="M."surname="Näslund"></author>surname="Näslund"/> <author initials="B."surname="Sahlin"></author>surname="Sahlin"/> <datemonth='August' year='2015'/>month="August" year="2015"/> </front><seriesInfo name="Proceedings of IEEE<refcontent>IEEE International Conference on Trust, Security and Privacy in Computing and Communications(TrustCom)" value="2015" /> <format type='HTML' target='https://doi.org/10.1109/Trustcom.2015.506'/>(TrustCom)</refcontent> <seriesInfo name="DOI" value="10.1109/Trustcom.2015.506"/> </reference> <referenceanchor="Heist2015">anchor="Heist2015" target="https://theintercept.com/2015/02/19/great-sim-heist/"> <front> <title>The Great SIM Heist</title> <author initials="J."surname="Scahill"></author>surname="Scahill"/> <author initials="J."surname="Begley"></author>surname="Begley"/> <date month="February" year="2015"/> </front><format type='HTML' target='https://theintercept.com/2015/02/19/great-sim-heist/'/></reference> <referenceanchor="DOW1992">anchor="DOW1992" target="https://doi.org/10.1007/BF00124891"> <front> <title>Authentication andAuthenticated Key Exchanges</title>authenticated key exchanges</title> <author initials="W."surname="Diffie"></author>surname="Diffie"/> <authorinitials="P."initials="P. C." surname="VanOorschot"></author>Oorschot"/> <authorinitials="M." surname="Wiener"></author>initials="M. J." surname="Wiener"/> <date month="June" year="1992"/> </front><seriesInfo name="Designs,<refcontent>Designs, Codes andCryptography 2" value="pp. 107-125" /> <format type='HTML' target='https://doi.org/10.1007/BF00124891'/>Cryptography, vol. 2, pp. 107-125</refcontent> <seriesInfo name="DOI" value="10.1007/BF00124891"/> </reference> <reference anchor="TS.33.501"> <front> <title>Security architecture and procedures for 5G System</title> <author> <organization>3GPP</organization> </author> <date month="March"year="2023" />year="2023"/> </front> <seriesInfo name="3GPP TS"value="33.501 18.1.0" />value="33.501"/> <refcontent>Version 18.1.0</refcontent> </reference> <reference anchor="NIST-ZT" target="https://www.nccoe.nist.gov/sites/default/files/2022-12/zta-nist-sp-1800-35b-preliminary-draft-2.pdf"> <front> <title>Implementing a Zero Trust Architecture</title><author initials="" surname="National<author> <organization>National Institute of Standards andTechnology"> <organization/>Technology</organization> </author> <date year="2022" month="December"/> </front> <seriesInfo name="NIST" value="SP 1800-35B"/> </reference> <reference anchor="NSA-ZT" target="https://media.defense.gov/2021/Feb/25/2002588479/-1/-1/0/CSI_EMBRACING_ZT_SECURITY_MODEL_UOO115131-21.PDF"> <front> <title>Embracing a Zero Trust Security Model</title><author initials="" surname="National<author> <organization>National SecurityAgency"> <organization/>Agency</organization> </author> <date year="2021" month="February"/> </front> </reference> </references> </references> <sectiontitle="Change Log"> <t>RFC Editor: Please remove this appendix.</t> <t>The -12 version of the WG draft has the following changes, most due to IESG review comments in January 2023: <list style="symbols"> <t>Update the draft track to Standards Track.</t> <t>Clarified the calculation of the Length field in the AT_ECDHE attribute, along with padding requirements.</t> <t>Avoided the use of keywords in operational recommendations, e.g., about deployment.</t> <t>Changed the definition of what "supported" means to focus on feature being implemented, but not require that it is usable during a protocol run, because configuration, new security information, etc. might imply that a particular feature is implemented but disabled for policy reasons.</t> <t>Changed the MITM terminology to be on-path attacks.</t> <t>Corrected a reference typo in the IANA considerations section.</t> <t>Shortened the abstract and introduction to the key aspects and removed duplication.</t> <t>Several editorial changes.</t> </list></t> <t>The -11 version of the WG draft has the following changes: <list style="symbols"> <t>Addressed IETF Last Call comments from directorates, Security AD, Meiling Cheng, and a detailed review from the author Karl. In particular:</t> <t>Replaced the reference to the deprecated FIPS 186-4 with SP 800-186.</t> <t>Changed HSS (Home Subscriber Server) to Authentication Database (AD) as HSS is a 4G term.</t> <t>Explained difference between EAP-AKA and EAP-AKA'</t> <t>Explained that the emphemeral key exhange provide more that forward secrecy and how this is important to mitigate pervasive monitoring.</t> <t>Included links for the zero trust principles.</t> <t>Explained why K_encr and K_auth not being protected by the ECDHE addition.</t> <t>Added that a future introduction of KEM might require additional changes.</t> <t>Explained how ephemeral key exchange is linked to pervasive monitoring.</t> <t>Changed SIM to USIM everywhere. A USIM is required for AKA.</t> <t>Changed to long-term key instead of long-term secret or long-term shared secret.</t> <t>Reference updates.</t> <t>Various editorial improvements.</t> </list></t> <t>The -10 version of the WG draft has the following changes: <list style="symbols"> <t>Various nits found by Peter Yee.</t> </list></t> <t>The -09 version of the WG draft has the following changes: <list style="symbols"> <t>Scalable Vector Graphics (SVG) versions for all figures has been added and the figures has been slightly modified to render nicely with aasvg.</t> <t>A reference has been added to the Section in SEC1 describing how to do decompression.</t> <t>The strengthened identity protection requirements are now mentioned in the introduction.</t> <t>Corrections and clarifications were made in the IANA considerations. The table in the IANA section has been made into a proper xml table.</t> <t>Reference updates.</t> <t>Various editorial improvements.</t> </list></t> <t>The -08 version of the WG draft has the following changes: <list style="symbols"> <t>Further clarification of key calculation in <xref target="kdf2"/>.</t> <t>Support for the NIST P-256 group has been made mandatory in <xref target="groups"/>, in order to align the requirements with 3GPP SUCI encryption requirements.</t> <t>The interaction between AT_KDF and AT_KDF_FS has been specified more clearly, including specifying how future specifications need to specify the treatment of new combinations.</t> <t>Addition of a discussion about the impacts of potential future quantum computing attacks with specific impacts to this extension.</t> <t>Addition of a discussion about metadata/unprotected data in <xref target="unp"/>.</t> <t>Reference updates.</t> <t>Various editorial improvements.</t> </list></t> <t>The -07 version of the WG draft has the following changes: <list style="symbols"> <t>The impact of forward secrecy explanation has been improved in the abstract and security considerations.</t> <t>The draft now more forcefully explains why the authors believe it is important to migrate existing systems to use forward secrecy, and makes a recommendation for this migration.</t> <t>The draft does no longer refer to issues within the smart cards but rather the smart card supply chain.</t> <t>The rationale for chosen algorithms is explained.</t> <t>Also, the authors have checked the language relating to the public value encoding, and believe it is exactly according to the references (<xref target="RFC7748"/> Section 6.1 and <xref target="SEC2"/> Section 2.7.1)</t> </list></t> <t>The -06 version of the WG draft is a refresh and a reference update. However, the following should be noted: <list style="symbols"> <t>The draft now uses "forward secrecy" terminology and references RFC 7624 per recommendations on mailing list discussion.</t> <t>There's been mailing list discussion about the encoding of the public values; the current text requires confirmation from the working group that it is sufficient.</t> </list> </t> <t>The -05 version of the WG draft takes into account feedback from the working group list, about the number of bytes needed to encode P-256 values.</t> <t>The -04 version of the WG draft takes into account feedback from the May 2020 WG interim meeting, correcting the reference to the NIST P-256 specification.</t> <t>The -03 version of the WG draft is first of all a refresh; there are no issues that we think need addressing, beyond the one for which there is a suggestion in -03: The document now suggests an alternate group/curve as an optional one besides X25519. The specific choice of particular groups and algorithms is still up to the working group.</t> <t>The -02 version of the WG draft took into account additional reviews, and changed the document to update RFC 5448 (or rather, its successor, <xref target="RFC9048"/>), changed the wording of the recommendation with regards to the use of this extension, clarified the references to the definition of X25519 and Curve25519, clarified the distinction to ECDH methods that use partially static keys, and simplified the use of AKA and USIM card terminology. Some editorial changes were also made.</t> <t>The -00 and -01 versions of the WG draft made no major changes, only updates to some references.</t> <t>The -05 version is merely a refresh while the draft was waiting for WG adoption.</t> <t>The -04 version of this draft made only editorial changes.</t> <t>The -03 version of this draft changed the naming of various protocol components, values, and notation to match with the use of ECDH in ephemeral mode. The AT_KDF_FS negotiation process was clarified in that exactly one key is ever sent in AT_KDF_ECDHE. The option of checking for zero key values IN ECDHE was added. The format of the actual key in AT_PUB_ECDHE was specified. Denial-of-service considerations for the FS process have been updated. Bidding down attacks against this extension itself are discussed extensively. This version also addressed comments from reviewers, including the August review from Mohit Sethi, and comments made during IETF-102 discussion.</t> </section> <section numbered="no" title="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like to note that the technical solution in this document came out of the TrustCom paper <xreftarget="TrustCom2015"/>,target="TrustCom2015" format="default"/>, whose authors were <contact fullname="J. Arkko"/>, <contact fullname="K. Norrman"/>, <contact fullname="M. Näslund"/>, and <contact fullname="B. Sahlin"/>. This documentusesalso uses a lot of material from <xreftarget="RFC4187"/>target="RFC4187" format="default"/> by <contact fullname="J. Arkko"/> and <contact fullname="H.Haverinen"/>Haverinen"/>, as well as <xreftarget="RFC5448"/>target="RFC5448" format="default"/> by <contact fullname="J. Arkko"/>, <contact fullname="V. Lehtovirta"/>, and <contact fullname="P. Eronen"/>.</t> <t>The authors would also like to thank <contact fullname="Ben Campbell"/>, <contact fullname="Meiling Chen"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Linda Dunbar"/>, <contact fullname="Tim Evans"/>, <contact fullname="Zhang Fu"/>, <contact fullname="Russ Housley"/>, <contact fullname="Tero Kivinen"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Warren Kumari"/>, <contact fullname="Eliot Lear"/>, <contact fullname="Vesa Lehtovirta"/>, <contact fullname="Kathleen Moriarty"/>, <contact fullname="Prajwol Kumar Nakarmi"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Anand R. Prasad"/>, <contact fullname="Michael Richardson"/>, <contact fullname="Göran Rune"/>, <contact fullname="Bengt Sahlin"/>, <contact fullname="Joseph Salowey"/>, <contact fullname="Mohit Sethi"/>, <contact fullname="Orie Steele"/>, <contact fullname="Rene Struik"/>, <contact fullname="Vesa Torvinen"/>, <contact fullname="Sean Turner"/>, <contact fullname="Helena Vahidi Mazinani"/>, <contact fullname="Robert Wilton"/>, <contact fullname="Paul Wouters"/>, <contact fullname="Bo Wu"/>, <contact fullname="Peter Yee"/>, and many other people at the IETF,GSMAGSMA, and 3GPP groups for interesting discussions in this problem space.</t> </section> </back> <!--[rfced] We have the following questions and changes regarding the terminology used in this document. Please review and let us know any guidance or objections where necessary. a) How may we expand MAC in this document (as abbreviations should be expanded on first use per Section 3.6 of RFC 7322, "RFC Style Guide")? Please note that both MAC and KDF are first used in Figure 1 and within attribute names before they are expanded; would it benefit the reader to expand MAC and KDF before these instances for additional context? b) FYI - The terms below are capped differently throughout this document. Unless we hear objections, we plan to make these instances lowercase throughout. Server v. server Peer v. peer Network v. network c) We see the use of both "NUL" and "NULL". Please review and let us know if any updates are necessary. --> <!--[rfced] The terms RAND, AUTN, XRES, RES, IK, and CK appear with and without articles throughout this document (see an example below). How may we update for consistency? Original: The authentication vector contains a random part RAND, an authenticator part AUTN used for authenticating the network to the USIM, an expected result part XRES, a 128-bit session key for integrity check IK, and a 128-bit session key for encryption CK. If this process is successful (the AUTN is valid and the sequence number used to generate AUTN is within the correct range)... --> <!--[rfced] Regarding abbreviation use throughout the document: a) FYI - We have added expansions for abbreviations upon first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the document carefully to ensure correctness. Key Derivation Function (KDF) User Equipment (UE) Wi-Fi Protected Access 3 (WPA3) Internet Key Exchange Protocol Version 2 (IKEv2) Secure Shell (SSH) b) We have updated to use the abbreviated form after first in accordance with the guidance at https://www.rfc-editor.org/styleguide/part2/#exp_abbrev. This mostly affects FS and KDF. Please let us know any objections. --> <!--[rfced] Please review the <artwork> element in Section 6.3 and let us know if it should be updated to <sourcecode> or another element. --> <!--[rfced] The reference [NIST-ZT] has been obsoleted. Would you like to update this reference to its most recent version? Original: [NIST-ZT] National Institute of Standards and Technology, "Implementing a Zero Trust Architecture", December 2022, <https://www.nccoe.nist.gov/sites/default/files/2022-12/ zta-nist-sp-1800-35b-preliminary-draft-2.pdf>. Perhaps: [NIST-ZT] National Institute of Standards and Technology, "Implementing a Zero Trust Architecture", NIST SP 1800-35, July 2024, <https://www.nccoe.nist.gov/sites/ default/files/2024-07/zta-nist-sp-1800-35-preliminary-draft-4.pdf> --> <!--[rfced] As the authors are listed in the References section for each of the three docs pointed to in the Acknowledgments, should they also be listed in the Acknowledgments section? --> <!--[rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed. Updates of this nature typically result in more precise language, which is helpful for readers. For example, please consider whether "Master" should be updated in the instances below: 643: attribute is set to 1, the Master Key (MK) and accompanying keys are 686: K_re is the re-authentication key, 256 bits, MSK is the Master 687: Session Key, 512 bits, and EMSK is the Extended Master Session Key, --> </rfc>