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

This html diff was produced by rfcdiff 1.48.