rfc9820.original.xml   rfc9820.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.23 (Ruby 3.2. -ietf-ace-wg-coap-eap-15" number="9820" updates="" obsoletes="" category="std" c
3) --> onsensus="true" submissionType="IETF" tocDepth="3" tocInclude="true" sortRefs="t
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft rue" symRefs="true" version="3" xml:lang="en">
-ietf-ace-wg-coap-eap-15" category="std" consensus="true" submissionType="IETF"
tocDepth="3" tocInclude="true" sortRefs="true" symRefs="true" version="3"> <!-- [rfced] *AD, text was added to the Acknowledgements section after the
<!-- xml2rfc v2v3 conversion 3.27.0 --> document was approved for publication. Please review th changes and
let us know if you approve.
Diff between v14 and v15:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ace-wg-coap-eap-15
-->
<!-- [rfced] Please note that the title of the document has been updated as
follows. We expanded abbreviations per Section 3.6 of RFC 7322 ("RFC
Style Guide"), recast "-based" to avoid using a hyphen with an expansion,
and added "for Use with". Please review.
Original:
EAP-Based Authentication Service for CoAP
Current:
Authentication Service Based on the Extensible Authentication Protocol (EAP) f
or Use with the Constrained
Application Protocol (CoAP)
-->
<front> <front>
<title abbrev="CoAP-EAP">EAP-based Authentication Service for CoAP</title> <title abbrev="CoAP-EAP">Authentication Service Based on the Extensible Auth
<seriesInfo name="Internet-Draft" value="draft-ietf-ace-wg-coap-eap-15"/> entication Protocol (EAP) for Use with the Constrained Application Protocol (CoA
P)</title>
<seriesInfo name="RFC" value="9820"/>
<author initials="R." surname="Marin-Lopez" fullname="Rafa Marin-Lopez"> <author initials="R." surname="Marin-Lopez" fullname="Rafa Marin-Lopez">
<organization abbrev="University of Murcia">University of Murcia</organiza tion> <organization abbrev="University of Murcia">University of Murcia</organiza tion>
<address> <address>
<postal> <postal>
<street>Campus de Espinardo S/N, Faculty of Computer Science</street> <street>Campus de Espinardo S/N, Faculty of Computer Science</street>
<city>Murcia</city> <city>Murcia</city>
<region/>
<code>30100</code> <code>30100</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>rafa@um.es</email> <email>rafa@um.es</email>
</address> </address>
</author> </author>
<author initials="D." surname="Garcia-Carrillo" fullname="Dan Garcia-Carrill o"> <author initials="D." surname="Garcia-Carrillo" fullname="Dan Garcia-Carrill o">
<organization abbrev="University of Oviedo">University of Oviedo</organiza tion> <organization abbrev="University of Oviedo">University of Oviedo</organiza tion>
<address> <address>
<postal> <postal>
<street>Calle Luis Ortiz Berrocal S/N, Edificio Polivalente</street> <street>Calle Luis Ortiz Berrocal S/N, Edificio Polivalente</street>
<city>Gijon</city> <city>Gijon</city>
<region>Asturias</region> <region>Asturias</region>
<code>33203</code> <code>33203</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<email>garciadan@uniovi.es</email> <email>garciadan@uniovi.es</email>
</address> </address>
</author> </author>
<date year="2025" month="February" day="19"/> <date year="2025" month="July"/>
<area>SEC</area> <area>SEC</area>
<workgroup>ACE Working Group</workgroup> <workgroup>ace</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on <https://www.rfc-editor.org/search>. -->
<abstract> <abstract>
<?line 154?> <t>This document specifies an authentication service that uses the Extensible Au thentication Protocol (EAP) transported employing Constrained Application Protoc ol (CoAP) messages. As such, it defines an EAP lower layer based on CoAP called "CoAP-EAP". One of the main goals is to authenticate a CoAP-enabled Internet of Things (IoT) device (EAP peer) that intends to join a security domain managed by a Controller (EAP authenticator). Secondly, it allows deriving key material to protect CoAP messages exchanged between them based on Object Security for Constr ained RESTful Environments (OSCORE), enabling the establishment of a security as sociation between them.
<t>This document specifies an authentication service that uses the Extensible Au <!-- [rfced] Abstract: We had trouble following the meaning of
thentication Protocol (EAP) transported employing Constrained Application Protoc "transported" in this sentence. If the suggested text is not
ol (CoAP) messages. As such, it defines an EAP lower layer based on CoAP called correct, please provide clarifying text.
CoAP-EAP. One of the main goals is to authenticate a CoAP-enabled IoT device (EA
P peer) that intends to join a security domain managed by a Controller (EAP auth Original:
enticator). Secondly, it allows deriving key material to protect CoAP messages e This document specifies an authentication service that uses the
xchanged between them based on Object Security for Constrained RESTful Environme Extensible Authentication Protocol (EAP) transported employing
nts (OSCORE), enabling the establishment of a security association between them. Constrained Application Protocol (CoAP) messages.
</t>
Suggested:
This document specifies an authentication service that uses the
Extensible Authentication Protocol (EAP) as a transport method that
employs Constrained Application Protocol (CoAP) messages. -->
</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 159?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>This document specifies an authentication service (application) that us
es the Extensible Authentication Protocol (EAP) <xref target="RFC3748"/> and is <!-- [rfced] We found quite a few undefined abbreviations in this
built on top of the Constrained Application Protocol (CoAP)<xref target="RFC7252 document. For ease of the reader, we expanded as many of them as we
"/> called CoAP-EAP. CoAP-EAP is an application that allows authenticating two C could find. Most were straightforward (e.g., SAML per RFC 7833,
oAP endpoints by using EAP and establishing an Object Security for Constrained R PANA per RFC 5191), but please confirm that our expansions for MIC
ESTful Environments (OSCORE) security association between them. (currently "Message Integrity Check") and LoRa (currently "Long
More specifically, this document specifies how CoAP can be used as a constrained Range") are correct.
, link-layer independent, reliable EAP lower layer <xref target="RFC3748"/> to t
ransport EAP messages between a CoAP server (acting as EAP peer) and a CoAP clie Original:
nt (acting as EAP authenticator) using CoAP messages. The CoAP client has the op EAP relies on lower layer error
tion of contacting a backend AAA infrastructure to complete the EAP negotiation, detection (e.g., CRC, checksum, MIC, etc.).
as described in the EAP specification <xref target="RFC3748"/>.</t> ...
<t>The EAP methods that can be transported with CoAP-EAP <bcp14>MUST</bcp1 Given that EAP is also used for network access authentication, this
4> export cryptographic material <xref target="RFC5247"/> for this specification service can be adapted to other technologies. For instance, to
. Examples of such methods are EAP-GPSK <xref target="RFC5433"/>, EAP-SIM <xref provide network access control to very constrained technologies
target="RFC4186"/>, EAP-AKA' <xref target="RFC5448"/>, EAP-TLS 1.3 <xref target= (e.g., LoRa network).
"RFC9190"/>, EAP-EDHOC <xref target="I-D.ietf-emu-eap-edhoc"/>, etc. In general,
any EAP method designed in EMU Working Group that exports the Master Session Ke Currently (fixed the incomplete sentence in the "LoRa" text):
y (MSK) can be used with CoAP-EAP. The Master Session Key (MSK) is used as the b EAP relies on lower-layer error
asis for further cryptographic derivations. This way, CoAP messages are protecte detection (e.g., CRC, checksum, Message Integrity Check (MIC),
d after authentication. After CoAP-EAP's operation, an OSCORE security associati etc.).
on is established between the endpoints of the service. Using the keying materia ...
l from the authentication, other security associations could be generated. <xref Given that EAP is also used for network access authentication, this
target="flow-of-operation-dtls"/> shows how to establish a (D)TLS security asso service can be adapted to other technologies - for instance, to
ciation using the keying material from the EAP authentication.</t> provide network access control to very constrained technologies
<t>One of the main applications of CoAP-EAP is Internet of Things (IoT) ne (e.g., Long Range (LoRa) networks). -->
tworks, where we can find very constrained links (e.g., limited bandwidth) and d
evices with limited capabilities. In these IoT scenarios, we identify the IoT de <t>This document specifies an authentication service (application) that us
vice as the entity that wants to be authenticated by using EAP to join a domain es the Extensible Authentication Protocol (EAP) <xref target="RFC3748"/> and is
that is managed by a Controller. The IoT device is in these cases the EAP peer a built on top of the Constrained Application Protocol (CoAP) <xref target="RFC725
nd the Controller, the entity steering the authentication, the EAP authenticator 2"/>; it is called "CoAP-EAP". CoAP-EAP is an application that allows authentica
. From now on, the IoT device is referred to as the EAP peer and the Controller ting two CoAP endpoints by using EAP and establishing an Object Security for Con
as the EAP authenticator. In these cases, EAP methods with fewer exchanges, shor strained RESTful Environments (OSCORE) security association between them.
ter messages, and cryptographic algorithms suitable for constrained devices are More specifically, this document specifies how CoAP can be used as a constrained
preferable. The benefits of the EAP framework in IoT are highlighted in <xref ta , link-layer-independent, reliable EAP lower layer <xref target="RFC3748"/> to t
rget="EAP-framework-IoT"/>.</t> ransport EAP messages between a CoAP server (acting as an EAP peer) and a CoAP c
lient (acting as an EAP authenticator) using CoAP messages. The CoAP client has
the option of contacting a backend Authentication, Authorization, and Accounting
(AAA) infrastructure to complete the EAP negotiation, as described in the EAP s
pecification <xref target="RFC3748"/>.</t>
<t>In the case of this specification, the EAP methods that can be transpor
ted with CoAP-EAP <bcp14>MUST</bcp14> export cryptographic material <xref target
="RFC5247"/>. Examples of such methods are the EAP Generalized Pre-Shared Key (E
AP-GPSK) <xref target="RFC5433"/>, the EAP Method for Global System for Mobile C
ommunications (GSM)
Subscriber Identity Modules (EAP-SIM) <xref target="RFC4186"/>, the EAP Method f
or 3rd Generation Authentication and Key Agreement (EAP-AKA') <xref target="RFC5
448"/>,
EAP-TLS 1.3 <xref target="RFC9190"/>, EAP with Ephemeral Diffie-Hellman over
CBOR Object Signing and Encryption (EAP-EDHOC) <xref target="I-D.ietf-emu-eap-ed
hoc"/>, etc. ("CBOR" stands for "Concise Binary Object Representation".) In gene
ral, any EAP method
designed in the EAP Method Update (EMU) Working Group that exports the Master Se
ssion Key (MSK) can be used with CoAP-EAP. The MSK is used as the basis for furt
her cryptographic derivations. This way, CoAP messages are protected after authe
ntication. After the CoAP-EAP operation, an OSCORE security association is estab
lished between the endpoints of the service. Using the keying material from the
authentication, other security associations could be generated. <xref target="fl
ow-of-operation-dtls"/> shows how to establish a (D)TLS security association usi
ng the keying material from the EAP authentication.</t>
<t>One of the main applications of CoAP-EAP involves Internet of Things (I
oT) networks, where we can find very constrained links (e.g., limited bandwidth)
and devices with limited capabilities. In these IoT scenarios, we identify the
IoT device as the entity that wants to be authenticated by using EAP to join a d
omain that is managed by a Controller. In these cases, the IoT device is the EAP
peer and the Controller is the entity steering the authentication (i.e., the EA
P authenticator); from now on, the IoT device will be referred to as the EAP pee
r and the Controller will be referred to as the EAP authenticator. In these case
s, EAP methods with fewer exchanges, shorter messages, and cryptographic algorit
hms suitable for constrained devices are preferable. The benefits of the EAP fra
mework in IoT networks are highlighted in <xref target="EAP-Framework-IoT"/>.</t
>
<section anchor="requirements-language"> <section anchor="requirements-language">
<name>Requirements Language</name> <name>Requirements Language</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and are to be interpreted as described in BCP&nbsp;14
only when, they <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
appear in all capitals, as shown here.</t> when, they appear in all capitals, as shown here.</t>
<?line -18?>
<t>Readers are expected to be familiar with the terms and concepts described in CoAP <xref target="RFC7252"/>, EAP <xref target="RFC3748"/> <xref target="RFC524 7"/> and OSCORE <xref target="RFC8613"/>.</t> <t>Readers are expected to be familiar with the terms and concepts described in CoAP <xref target="RFC7252"/>, EAP <xref target="RFC3748"/> <xref target="RFC524 7"/>, and OSCORE <xref target="RFC8613"/>.</t>
</section> </section>
</section> </section>
<section anchor="general-architecture"> <section anchor="general-architecture">
<name>General Architecture</name> <name>General Architecture</name>
<t><xref target="arch"/> illustrates the architecture defined in this docu <t><xref target="arch"/> illustrates the architecture defined in this docu
ment. In this architecture, the Extensible Authentication Protocol (EAP) peer w ment. In this architecture, the EAP peer will act as a CoAP server for this
ill act as a CoAP server for this service, and the domain EAP authenticator as a service and the domain EAP authenticator will act as a CoAP client. The rational
CoAP client. The rationale behind this decision is that EAP requests direction e behind this decision is that EAP requests will always travel from the EAP serv
is always from the EAP server to the EAP peer. Accordingly, EAP responses direct er to the EAP peer. Accordingly, EAP responses will always travel from the EAP p
ion is always from the EAP peer to the EAP server.</t> eer to the EAP server.
<!-- [rfced] Section 2: These sentences did not parse. We updated
the text. If this is incorrect, please provide clarifying text.
Original:
The rationale behind this decision
is that EAP requests direction is always from the EAP server to the
EAP peer. Accordingly, EAP responses direction is always from the
EAP peer to the EAP server.
Currently:
The rationale behind this decision is that EAP requests will always
travel from the EAP server to the EAP peer. Accordingly, EAP
responses will always travel from the EAP peer to the EAP server. -->
</t>
<t>It is worth noting that the EAP authenticator <bcp14>MAY</bcp14> intera ct with a backend AAA infrastructure when EAP pass-through mode is used, which w ill place the EAP server in the AAA server that contains the information require d to authenticate the EAP peer.</t> <t>It is worth noting that the EAP authenticator <bcp14>MAY</bcp14> intera ct with a backend AAA infrastructure when EAP pass-through mode is used, which w ill place the EAP server in the AAA server that contains the information require d to authenticate the EAP peer.</t>
<t>The protocol stack is described in <xref target="stack"/>. CoAP-EAP is <t>The protocol stack is described in <xref target="stack"/>. CoAP-EAP is
an application built on top of CoAP. On top of the application, there is an EAP an application built on top of CoAP. On top of the application, there is an EAP
state machine that can run any EAP method. For this specification, the EAP metho state machine that can run any EAP method. In the case of this specification, th
d <bcp14>MUST</bcp14> support key derivation and export, as specified in <xref t e EAP method <bcp14>MUST</bcp14> support key derivation and export as specified
arget="RFC5247"/>, a Master Session Key (MSK) of at least 64 octets, and an Exte in <xref target="RFC5247"/>: an MSK of at least 64 octets and an Extended Master
nded Master Session Key (EMSK) of at least 64 octets. CoAP-EAP also relies on Co Session Key (EMSK) of at least 64 octets. CoAP-EAP also relies on CoAP reliabil
AP reliability mechanisms in CoAP to transport EAP: CoAP over UDP with Confirmab ity mechanisms in CoAP to transport EAP: CoAP over UDP with Confirmable messages
le messages (<xref target="RFC7252"/>) or CoAP over TCP, TLS, or WebSockets <xre <xref target="RFC7252"/> or CoAP over TCP, TLS, or WebSockets <xref target="RFC
f target="RFC8323"/>.</t> 8323"/>.</t>
<!-- [rfced] Please review each artwork element. Should any artwork
element be tagged as sourcecode? If the current list of preferred
values for "type" on
<https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>
does not contain an applicable type, please let us know. Also, it is
acceptable to leave the "type" attribute unset. -->
<figure anchor="arch"> <figure anchor="arch">
<name>CoAP-EAP Architecture</name> <name>CoAP-EAP Architecture</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="144" width="480" viewBox="0 0 480 144" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="144" width="480" viewBox="0 0 480 144" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
<path d="M 8,32 L 8,80" fill="none" stroke="black"/> <path d="M 8,32 L 8,80" fill="none" stroke="black"/>
<path d="M 80,32 L 80,80" fill="none" stroke="black"/> <path d="M 80,32 L 80,80" fill="none" stroke="black"/>
<path d="M 152,32 L 152,80" fill="none" stroke="black"/> <path d="M 152,32 L 152,80" fill="none" stroke="black"/>
<path d="M 272,32 L 272,80" fill="none" stroke="black"/> <path d="M 272,32 L 272,80" fill="none" stroke="black"/>
<path d="M 384,32 L 384,80" fill="none" stroke="black"/> <path d="M 384,32 L 384,80" fill="none" stroke="black"/>
<path d="M 472,32 L 472,80" fill="none" stroke="black"/> <path d="M 472,32 L 472,80" fill="none" stroke="black"/>
skipping to change at line 109 skipping to change at line 204
<polygon class="arrowhead" points="152,64 140,58.4 140,69.6" fill= "black" transform="rotate(0,144,64)"/> <polygon class="arrowhead" points="152,64 140,58.4 140,69.6" fill= "black" transform="rotate(0,144,64)"/>
<polygon class="arrowhead" points="96,64 84,58.4 84,69.6" fill="bl ack" transform="rotate(180,88,64)"/> <polygon class="arrowhead" points="96,64 84,58.4 84,69.6" fill="bl ack" transform="rotate(180,88,64)"/>
<polygon class="arrowhead" points="16,112 4,106.4 4,117.6" fill="b lack" transform="rotate(180,8,112)"/> <polygon class="arrowhead" points="16,112 4,106.4 4,117.6" fill="b lack" transform="rotate(180,8,112)"/>
<g class="text"> <g class="text">
<text x="40" y="52">EAP</text> <text x="40" y="52">EAP</text>
<text x="192" y="52">EAP</text> <text x="192" y="52">EAP</text>
<text x="428" y="52">AAA/</text> <text x="428" y="52">AAA/</text>
<text x="44" y="68">peer</text> <text x="44" y="68">peer</text>
<text x="216" y="68">authenticator</text> <text x="216" y="68">authenticator</text>
<text x="400" y="68">EAP</text> <text x="400" y="68">EAP</text>
<text x="444" y="68">Server</text> <text x="444" y="68">server</text>
<text x="116" y="84">CoAP</text> <text x="116" y="84">CoAP</text>
<text x="328" y="84">AAA</text> <text x="328" y="84">AAA</text>
<text x="332" y="100">(Optional)</text> <text x="332" y="100">(optional)</text>
<text x="72" y="116">SCOPE</text> <text x="72" y="116">SCOPE</text>
<text x="108" y="116">OF</text> <text x="108" y="116">OF</text>
<text x="140" y="116">THIS</text> <text x="140" y="116">THIS</text>
<text x="196" y="116">DOCUMENT</text> <text x="196" y="116">DOCUMENT</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
+--------+ +--------------+ +----------+ +--------+ +--------------+ +----------+
| EAP | | EAP | | AAA/ | | EAP | | EAP | | AAA/ |
| peer |<------>| authenticator|<----------->|EAP Server| | peer |<------>| authenticator|<----------->|EAP server|
+--------+ CoAP +--------------+ AAA +----------+ +--------+ CoAP +--------------+ AAA +----------+
(Optional) (optional)
<----(SCOPE OF THIS DOCUMENT)----> <----(SCOPE OF THIS DOCUMENT)---->
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<!-- [rfced] Figure 1: We see "(SCOPE OF THIS DOCUMENT)" in the
ASCII art but "SCOPE OF THIS DOCUMENT" in the SVG. If you prefer the
parentheses, please correct the SVG in the edited copy of the XML.
If you prefer that the parentheses be removed, let us know, and we
will update the ASCII art accordingly. -->
<figure anchor="stack"> <figure anchor="stack">
<name>CoAP-EAP Stack</name> <name>CoAP-EAP Stack</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="224" width="432" viewBox="0 0 432 224" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="224" width="432" viewBox="0 0 432 224" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
<path d="M 8,32 L 8,192" fill="none" stroke="black"/> <path d="M 8,32 L 8,192" fill="none" stroke="black"/>
<path d="M 264,32 L 264,192" fill="none" stroke="black"/> <path d="M 264,32 L 264,192" fill="none" stroke="black"/>
<path d="M 8,32 L 264,32" fill="none" stroke="black"/> <path d="M 8,32 L 264,32" fill="none" stroke="black"/>
<path d="M 8,64 L 264,64" fill="none" stroke="black"/> <path d="M 8,64 L 264,64" fill="none" stroke="black"/>
<path d="M 280,80 L 296,80" fill="none" stroke="black"/> <path d="M 280,80 L 296,80" fill="none" stroke="black"/>
<path d="M 8,96 L 264,96" fill="none" stroke="black"/> <path d="M 8,96 L 264,96" fill="none" stroke="black"/>
<path d="M 8,128 L 264,128" fill="none" stroke="black"/> <path d="M 8,128 L 264,128" fill="none" stroke="black"/>
<path d="M 8,160 L 264,160" fill="none" stroke="black"/> <path d="M 8,160 L 264,160" fill="none" stroke="black"/>
<path d="M 8,192 L 264,192" fill="none" stroke="black"/> <path d="M 8,192 L 264,192" fill="none" stroke="black"/>
<polygon class="arrowhead" points="288,80 276,74.4 276,85.6" fill= "black" transform="rotate(180,280,80)"/> <polygon class="arrowhead" points="288,80 276,74.4 276,85.6" fill= "black" transform="rotate(180,280,80)"/>
<g class="text"> <g class="text">
<text x="64" y="52">EAP</text> <text x="64" y="52">EAP</text>
<text x="104" y="52">State</text> <text x="104" y="52">State</text>
<text x="160" y="52">Machine</text> <text x="160" y="52">Machine</text>
<text x="120" y="84">Application(CoAP-EAP)</text> <text x="120" y="84">Application (CoAP-EAP)</text>
<text x="324" y="84">This</text> <text x="324" y="84">This</text>
<text x="380" y="84">Document</text> <text x="380" y="84">Document</text>
<text x="128" y="116">Request/Responses/Signaling</text> <text x="128" y="116">Request / Responses / Signaling</text>
<text x="288" y="116">RFC</text> <text x="288" y="116">RFC</text>
<text x="324" y="116">7252</text> <text x="324" y="116">7252</text>
<text x="352" y="116">/</text> <text x="352" y="116">/</text>
<text x="376" y="116">RFC</text> <text x="376" y="116">RFC</text>
<text x="412" y="116">8323</text> <text x="412" y="116">8323</text>
<text x="48" y="148">Message</text> <text x="48" y="148">Message</text>
<text x="88" y="148">/</text> <text x="88" y="148">/</text>
<text x="128" y="148">Message</text> <text x="128" y="148">Message</text>
<text x="192" y="148">Framing</text> <text x="192" y="148">Framing</text>
<text x="288" y="148">RFC</text> <text x="288" y="148">RFC</text>
skipping to change at line 179 skipping to change at line 281
<text x="224" y="180">Transport</text> <text x="224" y="180">Transport</text>
<text x="288" y="180">RFC</text> <text x="288" y="180">RFC</text>
<text x="324" y="180">7252</text> <text x="324" y="180">7252</text>
<text x="352" y="180">/</text> <text x="352" y="180">/</text>
<text x="376" y="180">RFC</text> <text x="376" y="180">RFC</text>
<text x="412" y="180">8323</text> <text x="412" y="180">8323</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
+-------------------------------+ +---------------------------------+
| EAP State Machine | | EAP State Machine |
+-------------------------------+ +---------------------------------+
| Application(CoAP-EAP) | <-- This Document | Application (CoAP-EAP) | <-- This Document
+-------------------------------+ +---------------------------------+
| Request/Responses/Signaling | RFC 7252 / RFC 8323 | Request / Responses / Signaling | RFC 7252 / RFC 8323
+-------------------------------+ +---------------------------------+
| Message / Message Framing | RFC 7252 / RFC 8323 | Message / Message Framing | RFC 7252 / RFC 8323
+-------------------------------+ +---------------------------------+
|Unreliable / Reliable Transport| RFC 7252 / RFC 8323 | Unreliable / Reliable Transport | RFC 7252 / RFC 8323
+-------------------------------+ +---------------------------------+
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<!-- [rfced] Figure 2: We changed "Request/Responses/Signaling" to
"Request / Responses / Signaling", to match the spacing style of the
other entries in the figure. However, the "Request / Responses /
Signaling" line now looks a bit crowded in the SVG renderings in the
HTML and PDF output files. We cannot determine where in the SVG a
coordinate should be modified to correct the spacing. Please correct
the SVG in the edited copy of the XML. -->
</section> </section>
<section anchor="sec_coap-eap-operation"> <section anchor="sec_coap-eap-operation">
<name>CoAP-EAP Operation</name> <name>CoAP-EAP Operation</name>
<t>Because CoAP-EAP uses reliable delivery defined in CoAP (<xref target=" RFC7252"/>, <xref target="RFC8323"/>), EAP retransmission time is set to infinit e as mentioned in <xref target="RFC3748"/>. To keep the ordering guarantee, CoAP -EAP uses Hypermedia as the Engine of Application State (HATEOAS). Each step dur ing the EAP authentication accesses a new resource in the CoAP server (EAP peer) . The previous resource is removed once the new resource is created, indicating the resource that will process the next step of the EAP authentication.</t> <t>Because CoAP-EAP uses reliable delivery as defined in CoAP <xref target ="RFC7252"/> <xref target="RFC8323"/>, EAP retransmission time is set to an infi nite value, as mentioned in <xref target="RFC3748"/>. To maintain ordering guara ntees, CoAP-EAP uses Hypermedia as the Engine of Application State (HATEOAS). Ea ch step during the EAP authentication accesses a new resource in the CoAP server (EAP peer). The previous resource is removed once the new resource is created, indicating the resource that will process the next step of the EAP authenticatio n.</t>
<t>One of the benefits of using EAP is that we can choose from a large var iety of authentication methods.</t> <t>One of the benefits of using EAP is that we can choose from a large var iety of authentication methods.</t>
<t>In CoAP-EAP, the EAP peer will only have one authentication session wit h a specific EAP authenticator, and it will not process any other EAP authentica tion in parallel (with the same EAP authenticator). That is, a single ongoing EA P authentication is permitted for the same EAP peer and the same EAP authenticat or. It may be worth noting that the EAP authenticator may have parallel EAP sess ions with multiple EAP peers.</t> <t>In CoAP-EAP, the EAP peer will only have one authentication session wit h a specific EAP authenticator, and it will not process any other EAP authentica tion in parallel (with the same EAP authenticator). That is, a single ongoing EA P authentication is permitted for the same EAP peer and the same EAP authenticat or. It may be worth noting that the EAP authenticator may have parallel EAP sess ions with multiple EAP peers.</t>
<t>To access the authentication service, this document defines the well-kn
own URI "coap-eap" (to be assigned by IANA). The /.well-known/coap-eap URI is u <t>To access the authentication service, this document defines the well-kn
sed with "coap", "coap+tcp" or "coap+ws".</t> own URI "coap-eap" (see <xref target="wellknown"/>). The /.well-known/coap-eap
URI is used with "coap", "coap+tcp", or "coap+ws".</t>
<section anchor="discovery-section"> <section anchor="discovery-section">
<name>Discovery</name> <name>Discovery</name>
<t>Before the CoAP-EAP exchange takes place, the EAP peer needs to disco <t>Before the CoAP-EAP exchange takes place, the EAP peer needs to disco
ver the EAP authenticator or the entity that will enable the CoAP-EAP exchange ( ver the EAP authenticator or the entity that will enable the CoAP-EAP exchange (
e.g., an intermediary proxy). The discovery process is out of the scope of this e.g., an intermediary proxy). The discovery process is outside the scope of this
document.</t> document.
<!-- [rfced] Sections 3.1 and subsequent: We see phrases such as
"an intermediary proxy", "intermediary (i.e., proxy)", and
"intermediaries such as proxies" in this document. Will the
distinction regarding whether or not intermediaries are sometimes or
always proxies be clear to readers? -->
</t>
<t>The CoAP-EAP application can be accessed through the URI "coap-eap" f or the trigger message (see <xref target="flow-of-operation"/>, Step 0). The CoA P-EAP service can be discovered by asking directly about the services offered. T his information can also be available in the resource directory <xref target="RF C9176"/>.</t> <t>The CoAP-EAP application can be accessed through the URI "coap-eap" f or the trigger message (see <xref target="flow-of-operation"/>, Step 0). The CoA P-EAP service can be discovered by asking directly about the services offered. T his information can also be available in the resource directory <xref target="RF C9176"/>.</t>
<t>Implementation Notes: There are different methods to discover the IPv <t>Implementation notes: There are different methods for discovering the
6 address of the EAP authenticator or intermediary entity. For example, on a 6Lo IPv6 address of the EAP authenticator or intermediary entity. For example, in a
WPAN network, the Border Router will typically act as the EAP authenticator henc 6LoWPAN network, the Border Router will typically act as the EAP authenticator
e, after receiving the Router Advertisement (RA) messages from the Border Router hence, after receiving the Router Advertisement (RA) messages from the Border Ro
, the EAP peer may engage on the CoAP-EAP exchange.</t> uter, the EAP peer may engage in the CoAP-EAP exchange.
<!-- [rfced] Section 3.1: This sentence does not parse. If neither
suggestion below is correct, please clarify the meaning of "hence".
Original:
For
example, on a 6LoWPAN network, the Border Router will typically act
as the EAP authenticator hence, after receiving the Router
Advertisement (RA) messages from the Border Router, the EAP peer may
engage on the CoAP-EAP exchange.
Suggestion #1:
For
example, in a 6LoWPAN network, the Border Router will henceforth
typically act as the EAP authenticator. After receiving the Router
Advertisement (RA) messages from the Border Router, the EAP peer may
engage in the CoAP-EAP exchange.
Suggestion #2:
For
example, in a 6LoWPAN network, the Border Router will typically act
as the EAP authenticator. Hence, after receiving the Router
Advertisement (RA) messages from the Border Router, the EAP peer may
engage in the CoAP-EAP exchange. -->
</t>
</section> </section>
<section anchor="flow-of-operation"> <section anchor="flow-of-operation">
<name>Flow of operation (OSCORE establishment)</name> <name>Flow of Operation (OSCORE Establishment)</name>
<t><xref target="figure1"/> shows the general flow of operation for CoAP <t><xref target="figure3"/> shows the general flow of operation for CoAP
-EAP to authenticate using EAP and establish an OSCORE security context. The flo -EAP to authenticate using EAP and establish an OSCORE security context. The flo
w does not show a specific EAP method. Instead, the chosen EAP method is represe w does not show a specific EAP method. Instead, the chosen EAP method is represe
nted by using a generic name (EAP-X). The flow assumes that the EAP peer knows nted by using a generic name (EAP-X). The flow assumes that the EAP peer knows
the EAP authenticator implements the CoAP-EAP service. A CoAP-EAP message has a the EAP authenticator implements the CoAP-EAP service. A CoAP-EAP message has th
media type application/coap-eap, See <xref target="mediatypes"/>.</t> e media type "application/coap-eap". See <xref target="mediatypes"/>.</t>
<t>The steps of the operation are as follows:</t> <t>The steps for this flow of operation are as follows:</t>
<ul spacing="normal">
<li>
<t>Step 0. The EAP peer <bcp14>MUST</bcp14> start the CoAP-EAP proce
ss by sending a "POST /.well-known/coap-eap" request (trigger message). This mes
sage carries the 'No-Response' <xref target="RFC7967"/> CoAP option to avoid wa
iting for a response that is not needed. This is the only message where the EAP
authenticator acts as a CoAP server and the EAP peer as a CoAP client. The messa
ge also includes a URI in the payload of the message to indicate the resource wh
ere the EAP authenticator <bcp14>MUST</bcp14> send the next message. The name of
the resource is selected by the CoAP server.</t>
</li>
</ul>
<t>Implementation notes:
When generating the URI for a resource of a step of the authentication, the reso
urce could have the following format as an example "path/eap/counter", where:</t
>
<ul spacing="normal">
<li>
<t>"path" is some local path on the device to make the path unique.
This could be omitted if desired.</t>
</li>
<li>
<t>"eap" is the name that indicates the URI is for the EAP peer. Th
is has no meaning for the protocol but helps with debugging.</t>
</li>
<li>
<t>"counter' which is an incrementing unique number for every new EA
P request.</t>
</li>
</ul>
<t>So, in <xref target="figure1"/> for example, the URI for the first re
source would be “a/eap/1"</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li><t>Step 0. The EAP peer <bcp14>MUST</bcp14> start the CoAP-EAP
<t>Step 1. The EAP authenticator sends a POST message to the resourc process by sending a "POST /.well-known/coap-eap" request (trigger
e indicated in Step 0 (e.g., '/a/eap/1'). The payload in this message contains t message). This message carries the 'No-Response' CoAP option <xref
he first EAP message (EAP Request/Identity), the Recipient ID of the EAP authent target="RFC7967"/> to avoid waiting for a response that
icator (RID-C) for OSCORE, and <bcp14>MAY</bcp14> contain a CBOR array with a li is not needed. This is the only message where the EAP authenticator
st of proposed cipher suites (CS-C) for OSCORE. If the cipher suite list is not acts as a CoAP server and the EAP peer acts as a CoAP client. The mess
included, the default cipher suite for OSCORE is used. The details of the cipher age
suite negotiation are discussed in <xref target="crypto-negotiation"/>.</t> also includes a URI in the payload of the message to indicate the
</li> resource where the EAP authenticator <bcp14>MUST</bcp14> send the
<li> next message. The name of the resource is selected by the CoAP
<t>Step 2. The EAP peer processes the POST message sending the EAP r server.</t></li>
equest (EAP-Req/Id) to the EAP peer state machine, which returns an EAP response </ul>
(EAP Resp/Id). Then, assigns a new resource to the ongoing authentication proce <t>Implementation notes: When generating the URI for a resource during
ss (e.g., '/a/eap/2'), and deletes the previous one ('/a/eap/1'). Finally, sends a
a '2.01 Created' response with the new resource identifier in the Location-Path step of the authentication, the resource could have the following
(and/or Location-Query) options for the next step. The EAP response, the Recipi format as an example "path/eap/counter", where:</t>
ent ID of the EAP peer (RID-I) and the selected cipher suite for OSCORE (CS-I) a <ul spacing="normal">
re included in the payload. In this step, the EAP peer may create an OSCORE secu <li>"path" is some local path on the device to make the path unique.
rity context (see <xref target="OSCORE"/>). The required Master Session Key (MSK This could be omitted if desired.</li>
) will be available once the EAP authentication is successful in step 7.</t> <li>"eap" is the name that indicates that the URI is for the EAP pee
</li> r.
<li> This has no meaning for the protocol but helps with
<t>Steps 3-6. From now on, the EAP authenticator and the EAP peer wi debugging.</li>
ll exchange EAP packets related to the EAP method (EAP-X), transported in the Co <li>"counter" is an incrementing unique number for every new EAP req
AP message payload. The EAP authenticator will use the POST method to send EAP r uest.</li>
equests to the EAP peer. The EAP peer will use a response to carry the EAP respo </ul>
nse in the payload. EAP requests and responses are represented in <xref target="
figure1"/> using the nomenclature (EAP-X-Req and EAP-X-Resp, respectively). Whe <!-- [rfced] Section 3.2: Please confirm that the "Implementation
n a POST message arrives (e.g., '/a/eap/1') carrying an EAP request message, if notes" paragraph and bullet list should remain independent of Step 0
processed correctly by the EAP peer state machine, returns an EAP Response. Alon (i.e., should not be indented so that it is part of Step 0). We see
g with each EAP Response, a new resource is created (e.g., '/a/eap/3') for proce "resource of a step of the authentication" in the text, which seems
ssing the next EAP request and the ongoing resource (e.g., '/a/eap/2') is erased to indicate that this information applies to all steps and not just
. This way, ordering guarantee is achieved. Finally, an EAP response is sent in Step 0, but we would still like you to confirm that the current
the payload of a CoAP response that will also indicate the new resource in the L indentation levels are correct.
ocation-Path (and/or Location-Query) Options. In case there is an error processi
ng a legitimate message, the server will return a (4.00 Bad Request). There is a Original:
discussion about error handling in <xref target="error-handling"/>.</t> * Step 0. The EAP peer MUST start the CoAP-EAP process by sending a
</li> "POST /.well-known/coap-eap" request (trigger message). This
<li> message carries the 'No-Response' [RFC7967] CoAP option to avoid
<t>Step 7. When the EAP authentication ends successfully, the EAP au waiting for a response that is not needed. This is the only
thenticator obtains the Master Session Key (MSK) exported by the EAP method, an message where the EAP authenticator acts as a CoAP server and the
EAP Success message, and some authorization information (e.g., session lifetime) EAP peer as a CoAP client. The message also includes a URI in the
<xref target="RFC5247"/>. The EAP authenticator creates the OSCORE security con payload of the message to indicate the resource where the EAP
text using the MSK and Recipient ID of both entities exchanged in Steps 1 and 2. authenticator MUST send the next message. The name of the
The establishment of the OSCORE Security Context is defined in <xref target="OS resource is selected by the CoAP server.
CORE"/>. Then, the EAP authenticator sends the POST message protected with OSCOR
E for key confirmation including the EAP Success. The EAP authenticator <bcp14>M Implementation notes: When generating the URI for a resource of a
AY</bcp14> also send a Session Lifetime, in seconds, which is represented with a step of the authentication, the resource could have the following
n unsigned integer in a CBOR object (see <xref target="cbor-coap-eap"/>). If thi format as an example "path/eap/counter", where:
s Session Lifetime is not sent, the EAP peer assumes a default value of 8 hours,
as <bcp14>RECOMMENDED</bcp14> in <xref target="RFC5247"/>. The reception of the * "path" is some local path on the device to make the path unique.
OSCORE-protected POST message is considered by the EAP peer as an alternate ind This could be omitted if desired.
ication of success (<xref target="RFC3748"/>). The EAP peer state machine in the
EAP peer interprets the alternate indication of success (similarly to the arriv * "eap" is the name that indicates the URI is for the EAP peer.
al of an EAP Success) and returns the MSK, which is used to create the OSCORE se This has no meaning for the protocol but helps with debugging.
curity context in the EAP peer to process the protected POST message received fr
om the EAP authenticator.</t> * "counter' which is an incrementing unique number for every new EAP
</li> request.
<li>
<t>Step 8. If the EAP authentication and the verification of the OSC So, in Figure 3 for example, the URI for the first resource would be
ORE-protected POST in Step 7 is successful, then the EAP peer answers with an OS “a/eap/1"
CORE-protected '2.04 Changed'. From this point on, communication with the last
resource (e.g., '/a/eap/(n)') <bcp14>MUST</bcp14> be protected with OSCORE. If * Step 1. ... -->
allowed by application policy, the same OSCORE security context <bcp14>MAY</bcp1
4> be used to protect communication to other resources between the same endpoint <t>So, per <xref target="figure3"/>, the URI for the first resource wo
s.</t> uld be "a/eap/1".</t>
</li> <ul spacing="normal">
<li>Step 1. The EAP authenticator sends a POST message to the
resource indicated in Step 0 (e.g., '/a/eap/1'). The payload in this
message contains the first EAP message (EAP Request/Identity) and the
Recipient ID of the EAP authenticator (RID-C) for OSCORE, and
<bcp14>MAY</bcp14> contain a CBOR array with a list of proposed
cipher suites (CS-C) for OSCORE. If the cipher suite list is not
included, the default cipher suite for OSCORE is used. The details
of the cipher suite negotiation are discussed in <xref
target="crypto-negotiation"/>.</li>
<li>Step 2. The EAP peer processes the POST message sending the EAP
request (EAP-Req/Id) to the EAP peer state machine, which returns an
EAP response (EAP Resp/Id). Then, assigns a new resource to the
ongoing authentication process (e.g., '/a/eap/2') and deletes the
previous one ('/a/eap/1'). Finally, sends a '2.01 Created' response
with the new resource identifier in the Location-Path (and/or
Location-Query) options for the next step. The EAP response, the
Recipient ID of the EAP peer (RID-I), and the selected cipher suite
for OSCORE (CS-I) are included in the payload. In this step, the EAP
peer may create an OSCORE security context (see <xref
target="OSCORE"/>). The required MSK will be
available once the EAP authentication is successful (Step 7).</li>
<!-- [rfced] Section 3.2: Do "assigns" and "sends" refer to the
EAP peer or the EAP peer state machine? If the suggested text is not
correct, please provide clarifying text.
Original (previous text is included for context):
* Step 2. The EAP peer processes the POST message sending the EAP
request (EAP-Req/Id) to the EAP peer state machine, which returns
an EAP response (EAP Resp/Id). Then, assigns a new resource to
the ongoing authentication process (e.g., '/a/eap/2'), and deletes
the previous one ('/a/eap/1'). Finally, sends a '2.01 Created'
response with the new resource identifier in the Location-Path
(and/or Location-Query) options for the next step.
Suggested (guessing the EAP peer state machine):
* Step 2. The EAP peer processes the POST message, sending the EAP
request (EAP-Req/Id) to the EAP peer state machine, which returns
an EAP response (EAP Resp/Id). Then, the EAP peer state machine
assigns a new resource to the ongoing authentication process
(e.g., '/a/eap/2') and deletes the previous one ('/a/eap/1').
Finally, the EAP peer state machine sends a '2.01 Created'
response with the new resource identifier in the Location-Path
(and/or Location-Query) options for the next step. -->
<li>Steps 3-6. From now on, the EAP authenticator and the EAP peer
will exchange EAP packets related to the EAP method (EAP-X),
transported in the CoAP message payload. The EAP authenticator will
use the POST method to send EAP requests to the EAP peer. The EAP
peer will use a response to carry the EAP response in the
payload. EAP requests and responses are represented in <xref
target="figure3"/> using the nomenclature "EAP-X-Req" and "EAP-X-Resp"
,
respectively. When a POST message arrives (e.g., '/a/eap/1')
carrying an EAP request message, if processed correctly by the EAP
peer state machine, it returns an EAP Response. Along with each EAP
Response, a new resource is created (e.g., '/a/eap/3') for
processing the next EAP request and the ongoing resource (e.g.,
'/a/eap/2') is erased. This way, ordering guarantees are
achieved. Finally, an EAP response is sent in the payload of a CoAP
response that will also indicate the new resource in the
Location-Path (and/or Location-Query) Options. If an
error occurs while processing a legitimate message, the server will re
turn a
"4.00 Bad Request". Error handling is discussed in
<xref target="error-handling"/>.</li>
<!-- [rfced] Section 3.2: Please clarify the meaning of "response to
carry the EAP response" in this sentence.
Original:
The EAP peer will use a response to carry the EAP response in the
payload. -->
<li>Step 7. When the EAP authentication ends successfully, the EAP
authenticator obtains the MSK exported by the
EAP method, an EAP Success message, and some authorization
information (e.g., session lifetime) <xref target="RFC5247"/>. The
EAP authenticator creates the OSCORE security context using the MSK
and Recipient ID of both entities exchanged in Steps 1 and 2. The
establishment of the OSCORE Security Context is defined in <xref
target="OSCORE"/>. Then, the EAP authenticator sends the POST
message protected with OSCORE for key confirmation, including the EAP
Success. The EAP authenticator <bcp14>MAY</bcp14> also send a
Session Lifetime, in seconds, which is represented by an unsigned
integer in a CBOR object (see <xref target="cbor-coap-eap"/>). If
this Session Lifetime is not sent, the EAP peer assumes a default
value of 8 hours, as <bcp14>RECOMMENDED</bcp14> in <xref
target="RFC5247"/>. The reception of the OSCORE-protected POST
message is considered by the EAP peer as an alternate indication of
success <xref target="RFC3748"/>. The EAP peer state machine in
the EAP peer interprets the alternate indication of success
(similarly to the arrival of an EAP Success) and returns the MSK,
which is used to create the OSCORE security context in the EAP peer
to process the protected POST message received from the EAP
authenticator.</li>
<li>Step 8. If the EAP authentication and the verification of the
OSCORE-protected POST (Step 7) are successful, then the EAP peer
answers with an OSCORE-protected '2.04 Changed'. From this point
on, communication with the last resource (e.g., '/a/eap/(n)')
<bcp14>MUST</bcp14> be protected with OSCORE. If allowed by
application policy, the same OSCORE security context
<bcp14>MAY</bcp14> be used to protect communication to other
resources between the same endpoints.</li>
</ul> </ul>
<figure anchor="figure1"> <figure anchor="figure3">
<name>CoAP-EAP flow of operation with OSCORE</name> <name>CoAP-EAP Flow of Operation with OSCORE</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="592" width="464" viewBox="0 0 464 592" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="592" width="464" viewBox="0 0 464 592" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 16,512 L 16,528" fill="none" stroke="black"/> <path d="M 16,512 L 16,528" fill="none" stroke="black"/>
<path d="M 64,56 L 64,304" fill="none" stroke="black"/> <path d="M 64,56 L 64,304" fill="none" stroke="black"/>
<path d="M 64,336 L 64,560" fill="none" stroke="black"/> <path d="M 64,336 L 64,560" fill="none" stroke="black"/>
<path d="M 400,56 L 400,304" fill="none" stroke="black"/> <path d="M 400,56 L 400,304" fill="none" stroke="black"/>
<path d="M 400,336 L 400,560" fill="none" stroke="black"/> <path d="M 400,336 L 400,560" fill="none" stroke="black"/>
<path d="M 432,448 L 432,464" fill="none" stroke="black"/> <path d="M 432,448 L 432,464" fill="none" stroke="black"/>
<path d="M 24,48 L 120,48" fill="none" stroke="black"/> <path d="M 24,48 L 120,48" fill="none" stroke="black"/>
<path d="M 344,48 L 432,48" fill="none" stroke="black"/> <path d="M 344,48 L 432,48" fill="none" stroke="black"/>
skipping to change at line 387 skipping to change at line 663
| | | | | |
| | 2.04 Changed | | | 2.04 Changed |
OSCORE | OSCORE | OSCORE | OSCORE |
CTX 8)|---------------------------------------->| CTX 8)|---------------------------------------->|
*Session-Lifetime is optional *Session-Lifetime is optional
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="re-authentication"> <section anchor="re-authentication">
<name>Reauthentication</name> <name>Re-Authentication</name>
<t>When the CoAP-EAP state is close to expiring, the EAP peer may want t <t>When the CoAP-EAP state is close to expiring, the EAP peer may want t
o start a new authentication process (re-authentication) to renew the state. The o start a new authentication process (re-authentication) to renew the state. The
main goal is to obtain new and fresh keying material (MSK/EMSK) that, in turn, main goal is to obtain new and fresh keying material (MSK/EMSK) that, in turn,
allows deriving a new OSCORE security context, increasing the protection against allows deriving a new OSCORE security context, increasing the protection against
key leakage. The keying material <bcp14>MUST</bcp14> be renewed before the expi key leakage. The keying material <bcp14>MUST</bcp14> be renewed before the expi
ration of the Session-Lifetime. By default, the EAP Key Management Framework est ration of the Session-Lifetime. By default, the EAP key management framework <xr
ablishes a default value of 8 hours to refresh the keying material. Certain EAP ef target="RFC5247"/> establishes a default value of 8 hours to refresh the keyi
methods such as EAP-NOOB <xref target="RFC9140"/> or EAP-AKA' <xref target="RFC5 ng material. Certain EAP methods such as
448"/> provide fast reconnect for quicker re-authentication. The EAP re-authenti Nimble Out-of-Band Authentication for EAP (EAP-NOOB) <xref target="RFC9140"/> or
cation protocol (ERP) <xref target="RFC6696"/> <bcp14>MAY</bcp14> also be used t EAP-AKA' <xref target="RFC5448"/> provide fast reconnect for quicker re-authent
o avoid the repetition of the entire EAP exchange.</t> ication. The EAP Re-authentication Protocol (ERP) <xref target="RFC6696"/> <bcp1
<t>The re-authentication message flow will be the same as the one shown 4>MAY</bcp14> also be used to avoid the repetition of the entire EAP exchange.</
in <xref target="figure1"/>. Nevertheless, two different CoAP-EAP states will be t>
active during the re-authentication: the current CoAP-EAP state and the new CoA <t>The re-authentication message flow will be the same as that shown in
P-EAP state, which will be created once the re-authentication has finished succe <xref target="figure3"/>. Nevertheless, two different CoAP-EAP states will be ac
ssfully. Once the re-authentication is completed successfully, the current CoAP- tive during the re-authentication: the current CoAP-EAP state and the new CoAP-E
EAP state is deleted and replaced by the new CoAP-EAP state. If, for any reason, AP state, which will be created once the re-authentication has finished successf
the re-authentication fails, the current CoAP-EAP state will be available until ully. Once the re-authentication is completed successfully, the current CoAP-EAP
it expires, or it is renewed in another try of re-authentication.</t> state is deleted and replaced by the new CoAP-EAP state. If for any reason the
re-authentication fails, the current CoAP-EAP state will be available until it e
xpires, or it will be renewed during a subsequent re-authentication attempt.</t>
<t>If the re-authentication fails, it is up to the EAP peer to decide wh en to start a new re-authentication before the current EAP state expires.</t> <t>If the re-authentication fails, it is up to the EAP peer to decide wh en to start a new re-authentication before the current EAP state expires.</t>
</section> </section>
<section anchor="managing_boot_state"> <section anchor="managing_boot_state">
<name>Managing the State of the Service</name> <name>Managing the State of the Service</name>
<t>The EAP peer and the EAP authenticator keep state during the CoAP-EAP negotiation. The CoAP-EAP state includes several important parts:</t> <t>The EAP peer and the EAP authenticator keep state during the CoAP-EAP negotiation. The CoAP-EAP state includes several important parts:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>A reference to an instance of the EAP (peer or authenticator/serv er) state machine.</t> <t>A reference to an instance of the EAP (peer or authenticator/serv er) state machine.</t>
</li> </li>
<li> <li>
<t>The resource for the next message in the negotiation (e.g., '/a/e ap/2')</t> <t>The resource for the next message in the negotiation (e.g., '/a/e ap/2').</t>
</li> </li>
<li> <li>
<t>The MSK is exported when the EAP authentication is successful. Co AP-EAP can access the different variables by the EAP state machine (i.e., <xref target="RFC4137"/>).</t> <t>The MSK, which is exported when the EAP authentication is success ful. CoAP-EAP can access the different variables via the EAP state machine (see <xref target="RFC4137"/>).</t>
</li> </li>
<li> <li>
<t>A reference to the OSCORE context.</t> <t>A reference to the OSCORE context.</t>
</li> </li>
</ul> </ul>
<t>Once created, the EAP authenticator <bcp14>MAY</bcp14> choose to dele te the state as described in <xref target="figure4"/>. Conversely, the EAP peer may need to renew the CoAP-EAP state because the key material is close to expiri ng, as mentioned in <xref target="re-authentication"/>.</t> <t>Once created, the EAP authenticator <bcp14>MAY</bcp14> choose to dele te the state as described in <xref target="figure4"/>. Conversely, the EAP peer may need to renew the CoAP-EAP state because the key material is close to expiri ng, as mentioned in <xref target="re-authentication"/>.</t>
<t>There are situations where the current CoAP-EAP state might need to b <t>There are situations where the current CoAP-EAP state might need to b
e removed. For instance, due to its expiration or forced removal, the EAP peer h e removed. For instance, due to its expiration or forced removal, the EAP peer h
as to be expelled from the security domain. This exchange is illustrated in <xre as to be expelled from the security domain. Such an exchange is illustrated in <
f target="figure4"/>.</t> xref target="figure4"/>.</t>
<t>If the EAP authenticator deems it necessary to remove the CoAP-EAP st <t>If the EAP authenticator deems it necessary to remove the CoAP-EAP st
ate from the EAP peer before it expires, it can send a DELETE command in a reque ate from the EAP peer before it expires, it can send a DELETE command in a reque
st to the EAP peer, referencing the last CoAP-EAP state resource given by the Co st to the EAP peer, referencing the last CoAP-EAP state resource given by the Co
AP server, whose identifier will be the last one received (e.g., '/a/eap/(n)' in AP server, whose identifier will be the last one received (e.g., '/a/eap/(n)' in
<xref target="figure1"/>). This message is protected by the OSCORE security ass <xref target="figure3"/>). This message is protected by the OSCORE security ass
ociation to prevent forgery. Upon reception of this message, the CoAP server sen ociation to prevent forgery. Upon reception of this message, the CoAP server sen
ds a response to the EAP authenticator with the Code '2.02 Deleted', which is al ds a response to the EAP authenticator with the code '2.02 Deleted', which is al
so protected by the OSCORE security association. If a response from the EAP peer so protected by the OSCORE security association. If a response from the EAP peer
does not arrive after EXCHANGE_LIFETIME the EAP authenticator will remove the s does not arrive after EXCHANGE_LIFETIME, the EAP authenticator will remove the
tate.</t> state.</t>
<figure anchor="figure4"> <figure anchor="figure4">
<name>Deleting state</name> <name>Deleting State</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="192" width="432" viewBox="0 0 432 192" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="192" width="432" viewBox="0 0 432 192" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 56,56 L 56,176" fill="none" stroke="black"/> <path d="M 56,56 L 56,176" fill="none" stroke="black"/>
<path d="M 376,56 L 376,176" fill="none" stroke="black"/> <path d="M 376,56 L 376,176" fill="none" stroke="black"/>
<path d="M 8,48 L 104,48" fill="none" stroke="black"/> <path d="M 8,48 L 104,48" fill="none" stroke="black"/>
<path d="M 312,48 L 408,48" fill="none" stroke="black"/> <path d="M 312,48 L 408,48" fill="none" stroke="black"/>
<path d="M 64,112 L 368,112" fill="none" stroke="black"/> <path d="M 64,112 L 368,112" fill="none" stroke="black"/>
<path d="M 64,176 L 368,176" fill="none" stroke="black"/> <path d="M 64,176 L 368,176" fill="none" stroke="black"/>
<polygon class="arrowhead" points="376,176 364,170.4 364,181.6" fill="black" transform="rotate(0,368,176)"/> <polygon class="arrowhead" points="376,176 364,170.4 364,181.6" fill="black" transform="rotate(0,368,176)"/>
<polygon class="arrowhead" points="72,112 60,106.4 60,117.6" fil l="black" transform="rotate(180,64,112)"/> <polygon class="arrowhead" points="72,112 60,106.4 60,117.6" fil l="black" transform="rotate(180,64,112)"/>
skipping to change at line 454 skipping to change at line 731
|<--------------------------------------| |<--------------------------------------|
| | | |
| 2.02 Deleted | | 2.02 Deleted |
| OSCORE | | OSCORE |
|-------------------------------------->| |-------------------------------------->|
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
<section anchor="error-handling"> <section anchor="error-handling">
<name>Error handling</name> <name>Error Handling</name>
<t>This section elaborates on how different errors are handled. From EAP <t>This section elaborates on how different errors are handled: EAP auth
authentication failure, a non-responsive endpoint lost messages, or an initial entication failure (<xref target="eap-authentication-failure"/>), a non-responsi
POST message arriving out of place.</t> ve endpoint (<xref target="non-responsive-endpoint"/>), and duplicated messages
(<xref target="duplicated-message-with-well-knowncoap-eap"/>).
<!-- [rfced] Section 3.5: The second sentence was incomplete and
difficult to follow. Per Sections 3.5.1 through 3.5.3, we updated
this section as noted below. If this is incorrect, please clarify.
Original:
This section elaborates on how different errors are handled. From
EAP authentication failure, a non-responsive endpoint lost messages,
or an initial POST message arriving out of place.
Currently:
This section elaborates on how different errors are handled: EAP
authentication failure (Section 3.5.1), a non-responsive endpoint
(Section 3.5.2), and duplicated messages (Section 3.5.3). -->
</t>
<section anchor="eap-authentication-failure"> <section anchor="eap-authentication-failure">
<name>EAP authentication failure</name> <name>EAP Authentication Failure</name>
<t>The EAP authentication may fail in different situations (e.g., wron <t>The EAP authentication may fail in different situations (e.g., wron
g credentials). The result is that the EAP authenticator will send an EAP Failur g credentials). The result is that the EAP authenticator will send an EAP Failur
e message because of the EAP authentication (Step 7 in <xref target="figure1"/>) e message because of a failed EAP authentication (Step 7 in <xref target="figure
. In this case, the EAP peer <bcp14>MUST</bcp14> send a response '4.01 Unauthori 3"/>). In this case, the EAP peer <bcp14>MUST</bcp14> send a response '4.01 Unau
zed' in Step 8. Therefore, Step 7 and Step 8 are not protected in this case beca thorized' in Step 8. Therefore, Steps 7 and 8 are not protected in this case bec
use no Master Session Key (MSK) is exported and the OSCORE security context is n ause no MSK is exported and the OSCORE security context is not yet generated.</t
ot yet generated.</t> >
<t>If the EAP authentication fails during the re-authentication and th <t>If the EAP authentication fails during the re-authentication and th
e EAP authenticator sends an EAP failure, the current CoAP-EAP state will be sti e EAP authenticator sends an EAP failure, the current CoAP-EAP state will still
ll usable until it expires.</t> be usable until it expires.</t>
</section> </section>
<section anchor="non-responsive-endpoint"> <section anchor="non-responsive-endpoint">
<name>Non-responsive endpoint</name> <name>Non-Responsive Endpoint</name>
<t>If, for any reason, one of the entities becomes non-responsive, the <t>If for any reason one of the entities becomes non-responsive, the C
CoAP-EAP state <bcp14>SHOULD</bcp14> be removed after a stipulated amount of ti oAP-EAP state <bcp14>SHOULD</bcp14> be removed after a stipulated amount of time
me. The amount of time can be adjusted according to the policies established by . The amount of time can be adjusted according to the policies established by th
the application or use case where CoAP-EAP is used. As a default value, the CoAP e application or use case where CoAP-EAP is used. As a default value, the CoAP E
EXCHANGE_LIFETIME parameter, as defined in CoAP<xref target="RFC7252"/> will be XCHANGE_LIFETIME parameter, as defined in CoAP <xref target="RFC7252"/>, will be
used.</t> used.</t>
<t>The removal of the CoAP-EAP state in the EAP authenticator assumes that the EAP peer will need to authenticate again.</t> <t>The removal of the CoAP-EAP state in the EAP authenticator assumes that the EAP peer will need to authenticate again.</t>
<t>According to CoAP, EXCHANGE_LIFETIME considers the time it takes un til a client stops expecting a response to a request. A timer is reset every tim e a message is sent. <t>According to CoAP, EXCHANGE_LIFETIME considers the time it takes un til a client stops expecting a response to a request. A timer is reset every tim e a message is sent.
By default, CoAP-EAP adopts the value of EXCHANGE_LIFETIME as a timer in the EAP By default, CoAP-EAP adopts the value of EXCHANGE_LIFETIME as a timer in the EAP
peer and Authenticator to remove the CoAP-EAP state if the authentication proce peer and authenticator to remove the CoAP-EAP state if the authentication proce
ss has not progressed in that time, in consequence, it has not been completed.</ ss has not progressed in that time, in consequence, it has not been completed.
t>
<t>The EAP peer will remove the CoAP-EAP state either if the EXCHANGE_ <!-- [rfced] Section 3.5.2: We could not follow the meaning of this
LIFETIME is triggered, or the EAP peer state machine returns an eapFail.</t> run-on sentence. If the suggested text is not correct, please
<t>The EAP authenticator will remove the CoAP-EAP state either if the provide clarifying text.
EXCHANGE_LIFETIME is triggered, or, when the EAP authenticator is acting in pass
-through mode (i.e., the EAP authentication is performed against a AAA server), Original:
the EAP authenticator state machine returns an aaaTimemout.</t> By default, CoAP-EAP adopts the
value of EXCHANGE_LIFETIME as a timer in the EAP peer and
Authenticator to remove the CoAP-EAP state if the authentication
process has not progressed in that time, in consequence, it has not
been completed.
Suggested:
By default, CoAP-EAP adopts the
value of EXCHANGE_LIFETIME as a timer in the EAP peer and
authenticator to remove the CoAP-EAP state if the authentication
process has not progressed to completion during that time. -->
</t>
<t>The EAP peer will remove the CoAP-EAP state if either the EXCHANGE_
LIFETIME is triggered or the EAP peer state machine returns an eapFail.</t>
<t>The EAP authenticator will remove the CoAP-EAP state if either the
EXCHANGE_LIFETIME is triggered or, when the EAP authenticator is operating in pa
ss-through mode (i.e., the EAP authentication is performed against a AAA server)
, the EAP authenticator state machine returns "aaaTimeout" <xref target="RFC4137
"/>.</t>
</section> </section>
<section anchor="duplicated-message-with-well-knowncoap-eap"> <section anchor="duplicated-message-with-well-knowncoap-eap">
<name>Duplicated message with /.well-known/coap-eap</name> <name>Duplicated Message with /.well-known/coap-eap</name>
<t>The reception of the trigger message in Step 0 containing the URI / <t>The reception of the trigger message in Step 0 containing the URI /
coap-eap needs some additional considerations, as the resource is always availab coap-eap needs some additional considerations, as the resource is always availab
le in the EAP authenticator.</t> le in the EAP authenticator.
<!-- [rfced] Section 3.5.3: Does "Step 0" here refer to Step 0 in
Figure 3 or Step 0 in Figure 5? For ease of the reader, we suggest
adding a citation for the appropriate figure.
Original:
The reception of the trigger message in Step 0 containing the URI
/coap-eap needs some additional considerations, as the resource is
always available in the EAP authenticator. -->
</t>
<t>If a trigger message (Step 0) arrives at the EAP authenticator duri ng an ongoing authentication with the same EAP peer, the EAP authenticator <bcp1 4>MUST</bcp14> silently discard this trigger message.</t> <t>If a trigger message (Step 0) arrives at the EAP authenticator duri ng an ongoing authentication with the same EAP peer, the EAP authenticator <bcp1 4>MUST</bcp14> silently discard this trigger message.</t>
<t>If an old "POST /.well-known/coap-eap" (Step 0) arrives at the EAP <t>If an old "POST /.well-known/coap-eap" (Step 0) arrives at the EAP
authenticator and there is no authentication ongoing, the EAP authenticator may authenticator and there is no authentication ongoing, the EAP authenticator may
understand that a new authentication process is requested. Consequently, the EAP understand that a new authentication process is requested. Consequently, the EAP
authenticator will start a new EAP authentication. However, if the EAP peer did authenticator will start a new EAP authentication. However, if the EAP peer did
not start any authentication and therefore, it did not select any resource for not start any authentication and therefore, it did not select any resource for
the EAP authentication. Thus, the EAP peer sends a '4.04 Not found' in the respo the EAP authentication. Thus, the EAP peer sends a '4.04 Not Found' in the respo
nse (<xref target="figure9"/>).</t> nse (<xref target="figure5"/>).
<figure anchor="figure9">
<name>/.well-known/coap-eap with no ongoing authentication from the <!-- [rfced] Section 3.5.3: The "However, if ..." sentence is
EAP authenticator</name> incomplete; it appears that some words are missing. Please clarify
this text.
Original (the previous and next sentences are included for context):
Consequently, the EAP authenticator will start a new EAP
authentication. However, if the EAP peer did not start any
authentication and therefore, it did not select any resource for the
EAP authentication. Thus, the EAP peer sends a '4.04 Not found' in
the response (Figure 5). -->
</t>
<figure anchor="figure5">
<name>/.well-known/coap-eap with No Ongoing Authentication from the
EAP Authenticator</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="256" width="432" viewBox="0 0 432 256" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="256" width="432" viewBox="0 0 432 256" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 32,56 L 32,208" fill="none" stroke="black"/> <path d="M 32,56 L 32,208" fill="none" stroke="black"/>
<path d="M 368,56 L 368,208" fill="none" stroke="black"/> <path d="M 368,56 L 368,208" fill="none" stroke="black"/>
<path d="M 8,48 L 80,48" fill="none" stroke="black"/> <path d="M 8,48 L 80,48" fill="none" stroke="black"/>
<path d="M 328,48 L 400,48" fill="none" stroke="black"/> <path d="M 328,48 L 400,48" fill="none" stroke="black"/>
<path d="M 160,112 L 360,112" fill="none" stroke="black"/> <path d="M 160,112 L 360,112" fill="none" stroke="black"/>
<path d="M 40,160 L 360,160" fill="none" stroke="black"/> <path d="M 40,160 L 360,160" fill="none" stroke="black"/>
<path d="M 40,208 L 360,208" fill="none" stroke="black"/> <path d="M 40,208 L 360,208" fill="none" stroke="black"/>
<path d="M 276,152 L 292,120" fill="none" stroke="black"/> <path d="M 276,152 L 292,120" fill="none" stroke="black"/>
skipping to change at line 509 skipping to change at line 845
<text x="128" y="100">Payload("/a/eap/1")</text> <text x="128" y="100">Payload("/a/eap/1")</text>
<text x="260" y="132">POST</text> <text x="260" y="132">POST</text>
<text x="320" y="132">a/eap/1</text> <text x="320" y="132">a/eap/1</text>
<text x="176" y="148">Payload</text> <text x="176" y="148">Payload</text>
<text x="228" y="148">(EAP</text> <text x="228" y="148">(EAP</text>
<text x="264" y="148">Req</text> <text x="264" y="148">Req</text>
<text x="320" y="148">Id||CS-C)</text> <text x="320" y="148">Id||CS-C)</text>
<text x="12" y="164">1)</text> <text x="12" y="164">1)</text>
<text x="60" y="196">4.04</text> <text x="60" y="196">4.04</text>
<text x="96" y="196">Not</text> <text x="96" y="196">Not</text>
<text x="136" y="196">found</text> <text x="136" y="196">Found</text>
<text x="196" y="228">*Old</text> <text x="196" y="228">*Old</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
EAP peer EAP authenticator EAP peer EAP authenticator
---------- ---------- ---------- ----------
| *POST /.well-known/coap-eap | | *POST /.well-known/coap-eap |
0) | No-Response | 0) | No-Response |
| Payload("/a/eap/1") | | Payload("/a/eap/1") |
| ------------------------->| | ------------------------->|
| POST /a/eap/1 | | POST /a/eap/1 |
| Payload (EAP Req/Id||CS-C) | | Payload (EAP Req/Id||CS-C) |
1) |<----------------------------------------| 1) |<----------------------------------------|
| | | |
| 4.04 Not found | | 4.04 Not Found |
|---------------------------------------->| |---------------------------------------->|
*Old *Old
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="proxy"> <section anchor="proxy">
<name>Proxy operation in CoAP-EAP</name> <name>Proxy Operation in CoAP-EAP</name>
<t>The CoAP-EAP operation is intended to be compatible with the use of i ntermediary entities between the EAP peer and the EAP authenticator when direct communication is not possible. In this context, CoAP proxies can be used as enab lers of the CoAP-EAP exchange.</t> <t>The CoAP-EAP operation is intended to be compatible with the use of i ntermediary entities between the EAP peer and the EAP authenticator when direct communication is not possible. In this context, CoAP proxies can be used as enab lers of the CoAP-EAP exchange.</t>
<t>This specification is limited to using standard CoAP <xref target="RF C7252"/> as well as standardized CoAP options <xref target="RFC8613"/>. It does not specify any addition in the form of CoAP options. This is expected to ease t he integration of CoAP intermediaries in the CoAP-EAP exchange.</t> <t>This specification is limited to using standard CoAP <xref target="RF C7252"/> as well as standardized CoAP options <xref target="RFC8613"/>. It does not specify any addition in the form of CoAP options. This is expected to ease t he integration of CoAP intermediaries in the CoAP-EAP exchange.</t>
<t>When using proxies in the CoAP-EAP, it should be considered that the <t>When using proxies in the CoAP-EAP exchange, it should be considered
exchange contains a role-reversal process at the beginning of the exchange. In t that the exchange contains a role-reversal process at the beginning of the excha
he first message, the EAP peer acts as a CoAP client and the EAP authenticator a nge. In the first message, the EAP peer acts as a CoAP client and the EAP authen
s the CoAP server. After that, in the remaining exchanges the roles are reversed ticator acts as the CoAP server. After that, in the remaining exchanges the role
, being the EAP peer, the CoAP server, and the EAP authenticator, the CoAP clien s are reversed, being the EAP peer, the CoAP server, and the EAP authenticator,
t. When using a proxy in the exchange, for message 0, the proxy will act as forw the CoAP client. When using a proxy in the exchange, for Message 0, the proxy wi
ard, and as reverse for the rest. Additionally, in the first exchange, the EAP p ll act as forward, and as reverse for the rest. Additionally, in the first excha
eer, as a CoAP client, sends the URI for the next CoAP message in the payload of nge, the EAP peer, as a CoAP client, sends the URI for the next CoAP message in
a request. This is not the typical behavior, as URIs referring to new services/ the payload of a request. This is not the typical behavior, as URIs referring to
resources appear in Location-Path and/or Location-Query Options in CoAP response new services/resources appear in Location-Path and/or Location-Query Options in
s. Hence, the proxy will have to treat the payload of message 0, as if it were a CoAP responses. Hence, the proxy will have to treat the payload of Message 0 as
Location-Path Option of a CoAP response.</t> if it were a Location-Path Option of a CoAP response.
<!-- [rfced] Section 3.6: The following sentences do not parse.
If the suggested text for the first sentence is not correct, please
provide clarifying text.
We cannot follow the meaning of the second sentence. Please clarify
"the proxy will act as forward, and as reverse for the rest".
Original (the first sentence is included for context):
After that, in the
remaining exchanges the roles are reversed, being the EAP peer, the
CoAP server, and the EAP authenticator, the CoAP client. When using
a proxy in the exchange, for message 0, the proxy will act as
forward, and as reverse for the rest.
Suggested (first sentence):
In the remaining exchanges, the roles are reversed (i.e., the EAP
peer acts as the CoAP server, and the EAP authenticator acts as the
CoAP client). -->
</t>
</section> </section>
</section> </section>
<section anchor="coap-eap-media-type"> <section anchor="coap-eap-media-type">
<name>CoAP-EAP Media type format</name> <name>CoAP-EAP Media Type Format</name>
<t>In the CoAP-EAP exchange, the following format will be used. This is th <t>In the CoAP-EAP exchange, the format specified by the "application/coap
e format is specified by application/coap-eap media type, see <xref target="medi -eap" media type will be used. See <xref target="mediatypes"/>.</t>
atypes"/>.</t> <t>In CoAP-EAP, there are two different elements that can be sent over the
<t>In CoAP-EAP there are two different elements that can be sent over the payload. The first one is a relative URI. This payload will be present for the
payload. The first one is a relative URI. This payload will be present for the f first message (0) in <xref target="figure3"/>.</t>
irst message (0) in <xref target="figure1"/>.</t> <t>In all the other cases, an EAP message will be followed by the CBOR Obj
<t>In all the other cases, an EAP message will be followed by the CBOR Obj ect specified in <xref target="cbor-coap-eap"/>. A visual example of the second
ect specified in <xref target="cbor-coap-eap"/>. A visual example of the second case can be found in <xref target="figure7"/> (<xref target="crypto-negotiation"
case can be found in <xref target="figure5"/>.</t> />).</t>
</section> </section>
<section anchor="cbor-coap-eap"> <section anchor="cbor-coap-eap">
<name>CBOR Objects in CoAP-EAP</name> <name>CBOR Objects in CoAP-EAP</name>
<t>In the CoAP-EAP exchange, there is information that needs to be exchang <t>In the CoAP-EAP exchange, there is information that needs to be exchang
ed between the two entities. Examples of this information are the cipher suites ed between the two entities. Examples of this information are the cipher suites
that need to be negotiated or authorization information (Session-lifetime). Ther that need to be negotiated or authorization information (Session-lifetime). Ther
e may also be a need to extend the information that has to be exchanged in the f e may also be a need to extend the information that has to be exchanged in the f
uture. This section specifies the CBOR <xref target="RFC8949"/> data structure t uture. This section specifies the CBOR data structure <xref target="RFC8949"/> t
o exchange information between the EAP peer and the EAP authenticator in the CoA o exchange information between the EAP peer and the EAP authenticator in the CoA
P payload.</t> P payload.
<t><xref target="figure11"/> shows the specification of the CBOR Object to
exchange information in CoAP-EAP</t> <!-- [rfced] Section 5: We found this sentence confusing, because
<figure anchor="figure11"> the plural "Examples" is used but the text that follows shows an
<name>CBOR data structure for CoAP-EAP</name> "either-or" relationship ("cipher suites that need to be negotiated
or ..."). If the suggested text is not correct, please provide
clarifying text.
Original (the previous sentence is included for context):
In the CoAP-EAP exchange, there is information that needs to be
exchanged between the two entities. Examples of this information are
the cipher suites that need to be negotiated or authorization
information (Session-lifetime).
Suggested:
In the CoAP-EAP exchange, information needs to be exchanged between
the two entities - for example, the cipher suites that need to be
negotiated, or authorization information (Session-lifetime). -->
</t>
<t><xref target="figure6"/> shows the specification of the CBOR Object to
exchange information in CoAP-EAP.</t>
<figure anchor="figure6">
<name>CBOR Data Structure for CoAP-EAP</name>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
CoAP-EAP_Info = { CoAP-EAP_Info = {
? 1 : [+ int], ; Cipher Suite (CS-C or CS-I) ? 1 : [+ int], ; Cipher Suite (CS-C or CS-I)
? 2 : bstr, ; RID-C ? 2 : bstr, ; RID-C
? 3 : bstr, ; RID-I ? 3 : bstr, ; RID-I
? 4 : uint ; Session-Lifetime ? 4 : uint ; Session-Lifetime
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t>The parameters contain the following information:</t> <t>The parameters contain the following information:</t>
<ol spacing="normal" type="1"><li> <ol spacing="normal">
<t>Cipher Suite: Is an array with the list of proposed, or selected, C <li>Cipher Suite: An array with the list of proposed, or selected,
OSE algorithms for OSCORE. If the field is carried over a request, the meaning i CBOR Object Signing and Encryption (COSE) algorithms for OSCORE. If the
s the proposed cipher suite, if it is carried over a response, corresponds to th field is carried over a request,
e agreed-upon cipher suite.</t> a proposed cipher suite is indicated; if it is carried over a
</li> response, it corresponds to the agreed-upon cipher suite.</li>
<li> <li>RID-C: The Recipient ID of the EAP authenticator. The EAP peer
<t>RID-I: Is the Recipient ID of the EAP peer. The EAP authenticator u uses this value as the Sender ID for its OSCORE Sender Context. The EAP
ses this value as a Sender ID for its OSCORE Sender Context. The EAP peer uses t authenticator uses this value as the Recipient ID for its Recipient
his value as Recipient ID for its Recipient Context.</t> Context.</li>
</li> <li>RID-I: The Recipient ID of the EAP peer. The EAP authenticator
<li> uses this value as the Sender ID for its OSCORE Sender Context. The EAP
<t>RID-C: Is the Recipient ID of the EAP authenticator. The EAP peer u peer uses this value as the Recipient ID for its Recipient Context.</li>
ses this value as a Sender ID for its OSCORE Sender Context. The EAP authenticat <li>Session-Lifetime: The time that the session is valid, in seconds.</l
or uses this value as Recipient ID for its Recipient Context.</t> i>
</li>
<li>
<t>Session-Lifetime: Is time the session is valid, in seconds.</t>
</li>
</ol> </ol>
<!-- [rfced] Section 5: Per Figure 6, Table 4, and
<https://www.iana.org/assignments/coap-eap/>, we moved the RID-I item
so that it is the third item (Label 3, per Figure 6, Table 4, and
IANA) instead of the second; RID-C is now the second item.
Please let us know any objections.
Original:
2. RID-I: Is the Recipient ID of the EAP peer. The EAP
authenticator uses this value as a Sender ID for its OSCORE
Sender Context. The EAP peer uses this value as Recipient ID for
its Recipient Context.
3. RID-C: Is the Recipient ID of the EAP authenticator. The EAP
peer uses this value as a Sender ID for its OSCORE Sender
Context. The EAP authenticator uses this value as Recipient ID
for its Recipient Context.
Currently:
2. RID-C: The Recipient ID of the EAP authenticator. The EAP peer
uses this value as the Sender ID for its OSCORE Sender Context.
The EAP authenticator uses this value as the Recipient ID for its
Recipient Context.
3. RID-I: The Recipient ID of the EAP peer. The EAP authenticator
uses this value as the Sender ID for its OSCORE Sender Context.
The EAP peer uses this value as the Recipient ID for its
Recipient Context. -->
<t>Other indexes can be used to carry additional values as needed, like sp ecific authorization parameters.</t> <t>Other indexes can be used to carry additional values as needed, like sp ecific authorization parameters.</t>
<t>The indexes from 65001 to 65535 are reserved for experimentation.</t> <t>The indexes from 65001 to 65535 are reserved for experimentation.</t>
</section> </section>
<section anchor="key_deriv"> <section anchor="key_deriv">
<name>Cipher suite negotiation and key derivation</name> <name>Cipher Suite Negotiation and Key Derivation</name>
<section anchor="crypto-negotiation"> <section anchor="crypto-negotiation">
<name>Cipher suite negotiation</name> <name>Cipher Suite Negotiation</name>
<t>OSCORE runs after the EAP authentication, using the cipher suite sele <t>OSCORE runs after the EAP authentication, using the cipher suite sele
cted in the cipher suite negotiation (Steps 1 and 2). To negotiate the cipher su cted in the cipher suite negotiation (Steps 1 and 2). To negotiate the cipher su
ite, CoAP-EAP follows a simple approach: the EAP authenticator sends a list, in ite, CoAP-EAP follows a simple approach: The EAP authenticator sends a list, in
decreasing order of preference, with the identifiers of the supported cipher sui decreasing order of preference, with the identifiers of the supported cipher sui
tes (Step 1). In the response to that message (Step 2), the EAP peer sends a res tes (Step 1). In the response to that message (Step 2), the EAP peer sends its c
ponse with the choice.</t> hoice.
<t>This list is included in the payload after the EAP message through a
CBOR array. An example of how the fields are arranged in the CoAP payload can be <!-- [rfced] Section 6.1: Does "Steps 1 and 2" here refer to
seen in <xref target="figure5"/>. An example of the exchange with the cipher su Steps 1 and 2 in Figure 3 or Steps 1 and 2 in Figure 8?
ite negotiation is shown in <xref target="figure6"/>, where it can be appreciate For ease of the reader, we suggest adding a citation for the
d the disposition of both EAP-Request/Identity and EAP-Response/Identity, follow appropriate figure.
ed by the CBOR object defined in <xref target="cbor-coap-eap"/>, containing the
cipher suite field for the cipher suite negotiation.</t> Original:
<figure anchor="figure5"> OSCORE runs after the EAP authentication, using the cipher suite
<name>cipher suites are in the CoAP payload</name> selected in the cipher suite negotiation (Steps 1 and 2). -->
</t>
<t>This list is included in the payload after the EAP message through a
CBOR array. An example of how the fields are arranged in the CoAP payload can be
seen in <xref target="figure7"/>. An example exchange for the cipher suite nego
tiation is shown in <xref target="figure8"/>, where it can be
appreciated the disposition of both the EAP-Request/Identity and EAP-Response/Id
entity, followed by the CBOR object defined in <xref target="cbor-coap-eap"/>, c
ontaining the cipher suite field for the cipher suite negotiation.
<!-- [rfced] Section 6.1: We had trouble following this sentence.
If the suggested text is not correct, please clarify "where it can be
appreciated the disposition".
Original:
An example of the exchange with the
cipher suite negotiation is shown in Figure 8, where it can be
appreciated the disposition of both EAP-Request/Identity and EAP-
Response/Identity, followed by the CBOR object defined in Section 5,
containing the cipher suite field for the cipher suite negotiation.
Suggested:
An example exchange for the
cipher suite negotiation is shown in Figure 8. The
EAP request (EAP-Request/Identity) and EAP response
(EAP-Response/Identity) are sent; both messages include the CBOR
object (Section 5) containing the cipher suite field for the cipher
suite negotiation. -->
</t>
<!-- [rfced] Figure 7: We note that the ASCII art has two pipes (with "+"
above each) between the "Data" and "cipher suites" fields, while the SVG
has vertical lines along with curved lines that intersect each
other. Please review and correct the edited copy of the XML if needed.
-->
<figure anchor="figure7">
<name>Cipher Suites in the CoAP Payload</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="112" width="400" viewBox="0 0 400 112" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="112" width="400" viewBox="0 0 400 112" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 8,32 L 8,64" fill="none" stroke="black"/> <path d="M 8,32 L 8,64" fill="none" stroke="black"/>
<path d="M 56,32 L 56,64" fill="none" stroke="black"/> <path d="M 56,32 L 56,64" fill="none" stroke="black"/>
<path d="M 152,32 L 152,64" fill="none" stroke="black"/> <path d="M 152,32 L 152,64" fill="none" stroke="black"/>
<path d="M 216,32 L 216,64" fill="none" stroke="black"/> <path d="M 216,32 L 216,64" fill="none" stroke="black"/>
<path d="M 272,32 L 272,64" fill="none" stroke="black"/> <path d="M 272,32 L 272,64" fill="none" stroke="black"/>
<path d="M 280,32 L 280,64" fill="none" stroke="black"/> <path d="M 280,32 L 280,64" fill="none" stroke="black"/>
<path d="M 392,32 L 392,64" fill="none" stroke="black"/> <path d="M 392,32 L 392,64" fill="none" stroke="black"/>
<path d="M 8,32 L 392,32" fill="none" stroke="black"/> <path d="M 8,32 L 392,32" fill="none" stroke="black"/>
skipping to change at line 609 skipping to change at line 1056
<path d="M 264,64 C 272.83064,64 280,56.83064 280,48" fill="none " stroke="black"/> <path d="M 264,64 C 272.83064,64 280,56.83064 280,48" fill="none " stroke="black"/>
<path d="M 288,64 C 279.16936,64 272,56.83064 272,48" fill="none " stroke="black"/> <path d="M 288,64 C 279.16936,64 272,56.83064 272,48" fill="none " stroke="black"/>
<g class="text"> <g class="text">
<text x="28" y="52">Code</text> <text x="28" y="52">Code</text>
<text x="100" y="52">Identifier</text> <text x="100" y="52">Identifier</text>
<text x="180" y="52">Length</text> <text x="180" y="52">Length</text>
<text x="244" y="52">Data</text> <text x="244" y="52">Data</text>
<text x="308" y="52">cipher</text> <text x="308" y="52">cipher</text>
<text x="364" y="52">suites</text> <text x="364" y="52">suites</text>
<text x="80" y="84">EAP</text> <text x="80" y="84">EAP</text>
<text x="124" y="84">Packet</text> <text x="124" y="84">packet</text>
<text x="316" y="84">CBOR</text> <text x="316" y="84">CBOR</text>
<text x="360" y="84">array</text> <text x="360" y="84">array</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
+-----+-----------+-------+------++-------------+ +-----+-----------+-------+------++-------------+
|Code |Identifier |Length | Data ||cipher suites| |Code |Identifier |Length | Data ||cipher suites|
+-----+-----------+-------+------++-------------+ +-----+-----------+-------+------++-------------+
EAP Packet CBOR array EAP packet CBOR array
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<figure anchor="figure6"> <figure anchor="figure8">
<name>cipher suite negotiation</name> <name>Cipher Suite Negotiation</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="256" width="424" viewBox="0 0 424 256" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/200 0/svg" version="1.1" height="256" width="424" viewBox="0 0 424 256" class="diagr am" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap ="round">
<path d="M 32,72 L 32,208" fill="none" stroke="black"/> <path d="M 32,72 L 32,208" fill="none" stroke="black"/>
<path d="M 368,72 L 368,208" fill="none" stroke="black"/> <path d="M 368,72 L 368,208" fill="none" stroke="black"/>
<path d="M 8,64 L 104,64" fill="none" stroke="black"/> <path d="M 8,64 L 104,64" fill="none" stroke="black"/>
<path d="M 320,64 L 416,64" fill="none" stroke="black"/> <path d="M 320,64 L 416,64" fill="none" stroke="black"/>
<path d="M 40,112 L 360,112" fill="none" stroke="black"/> <path d="M 40,112 L 360,112" fill="none" stroke="black"/>
<path d="M 40,160 L 360,160" fill="none" stroke="black"/> <path d="M 40,160 L 360,160" fill="none" stroke="black"/>
<path d="M 40,208 L 360,208" fill="none" stroke="black"/> <path d="M 40,208 L 360,208" fill="none" stroke="black"/>
<polygon class="arrowhead" points="368,208 356,202.4 356,213.6" fill="black" transform="rotate(0,360,208)"/> <polygon class="arrowhead" points="368,208 356,202.4 356,213.6" fill="black" transform="rotate(0,360,208)"/>
<polygon class="arrowhead" points="368,112 356,106.4 356,117.6" fill="black" transform="rotate(0,360,112)"/> <polygon class="arrowhead" points="368,112 356,106.4 356,117.6" fill="black" transform="rotate(0,360,112)"/>
<polygon class="arrowhead" points="48,160 36,154.4 36,165.6" fil l="black" transform="rotate(180,40,160)"/> <polygon class="arrowhead" points="48,160 36,154.4 36,165.6" fil l="black" transform="rotate(180,40,160)"/>
<g class="text"> <g class="text">
<text x="24" y="36">EAP</text> <text x="24" y="36">EAP</text>
<text x="60" y="36">peer</text> <text x="60" y="36">peer</text>
<text x="328" y="36">EAP</text> <text x="328" y="36">EAP</text>
<text x="368" y="36">Auth.</text> <text x="368" y="36">auth.</text>
<text x="24" y="52">(CoAP</text> <text x="24" y="52">(CoAP</text>
<text x="80" y="52">server)</text> <text x="80" y="52">server)</text>
<text x="336" y="52">(CoAP</text> <text x="336" y="52">(CoAP</text>
<text x="392" y="52">client)</text> <text x="392" y="52">client)</text>
<text x="168" y="100">...</text> <text x="168" y="100">...</text>
<text x="260" y="132">POST</text> <text x="260" y="132">POST</text>
<text x="316" y="132">/a/eap/1</text> <text x="316" y="132">/a/eap/1</text>
<text x="80" y="148">Payload</text> <text x="80" y="148">Payload</text>
<text x="132" y="148">(EAP</text> <text x="132" y="148">(EAP</text>
<text x="184" y="148">Req/Id,</text> <text x="184" y="148">Req/Id,</text>
skipping to change at line 669 skipping to change at line 1115
<text x="72" y="196">Payload</text> <text x="72" y="196">Payload</text>
<text x="124" y="196">(EAP</text> <text x="124" y="196">(EAP</text>
<text x="180" y="196">Resp/Id,</text> <text x="180" y="196">Resp/Id,</text>
<text x="272" y="196">CBORArray[0])</text> <text x="272" y="196">CBORArray[0])</text>
<text x="12" y="212">2)</text> <text x="12" y="212">2)</text>
<text x="200" y="228">...</text> <text x="200" y="228">...</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
EAP peer EAP Auth. EAP peer EAP auth.
(CoAP server) (CoAP client) (CoAP server) (CoAP client)
------------- ------------- ------------- -------------
| | | |
| ... | | ... |
|---------------------------------------->| |---------------------------------------->|
| POST /a/eap/1 | | POST /a/eap/1 |
| Payload (EAP Req/Id, CBORArray[0,1,2]) | | Payload (EAP Req/Id, CBORArray[0,1,2]) |
1) |<----------------------------------------| 1) |<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/2] | | 2.01 Created Location-Path [/a/eap/2] |
| Payload (EAP Resp/Id, CBORArray[0]) | | Payload (EAP Resp/Id, CBORArray[0]) |
2) |---------------------------------------->| 2) |---------------------------------------->|
... ...
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>In case there is no CBOR array stating the cipher suites, the default <t>If there is no CBOR array specifying the cipher suites, the default c
cipher suites are applied. If the EAP authenticator sends a restricted list of ipher suites are applied. If the EAP authenticator sends a restricted list of ci
cipher suites that are willing to accept, it <bcp14>MUST</bcp14> include the def pher suites that can be accepted, it <bcp14>MUST</bcp14> include the default val
ault value 0 since it is mandatory to implement. The EAP peer will have at least ue 0, since it is mandatory to implement. The EAP peer will have at least that o
that option available.</t> ption available.</t>
<t>The cipher suite requirements are inherited from the ones established <t>The cipher suite requirements are inherited from those established by
by OSCORE <xref target="RFC8613"/>, which are COSE algorithms <xref target="RFC OSCORE <xref target="RFC8613"/>, which are COSE algorithms <xref target="RFC905
9053"/>. By default, the HMAC-based Extract-and-Expand Key Derivation Function ( 3"/>. By default, the HMAC-based Extract-and-Expand Key Derivation Function (HKD
HKDF) algorithm is SHA-256 and the AEAD algorithm is AES-CCM-16-64-128 <xref tar F) algorithm is SHA-256 and the Authenticated Encryption with Associated Data (A
get="RFC9053"/>. Both are mandatory to implement. The other supported and negoti EAD) algorithm is AES-CCM-16-64-128 <xref target="RFC9053"/>. ("HMAC" stands for
ated cipher suites are the following:</t> "Hashed Message Authentication Code".) Both are mandatory to implement. The oth
er supported and negotiated cipher suites are as follows:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>0) AES-CCM-16-64-128, SHA-256 (default)</t> <t>0) AES-CCM-16-64-128, SHA-256 (default)</t>
</li> </li>
<li> <li>
<t>1) A128GCM, SHA-256</t> <t>1) A128GCM, SHA-256</t>
</li> </li>
<li> <li>
<t>2) A256GCM, SHA-384</t> <t>2) A256GCM, SHA-384</t>
</li> </li>
<li> <li>
<t>3) ChaCha20/Poly1305, SHA-256</t> <t>3) ChaCha20/Poly1305, SHA-256</t>
</li> </li>
<li> <li>
<t>4) ChaCha20/Poly1305, SHAKE256</t> <t>4) ChaCha20/Poly1305, SHAKE256</t>
</li> </li>
</ul> </ul>
<t>This specification uses the HKDF defined in <xref target="RFC5869"/>
to derive the necessary key material. Since the key derivation process uses the <!-- [rfced] Sections 6.1 and Appendix A: Do these algorithms need
Master Session Key (MSK), which is considered fresh key material, the HKDF-Expan to be numbered? If yes, will this numbering scheme be clear to
d function will be used (shortened here as KDF). Why the use of this function is readers?
enough, and it is not necessary to use KDF-Extract is explained in <xref target
="limit_eap_medhods"/>.</t> Original:
* 0) AES-CCM-16-64-128, SHA-256 (default)
* 1) A128GCM, SHA-256
* 2) A256GCM, SHA-384
* 3) ChaCha20/Poly1305, SHA-256
* 4) ChaCha20/Poly1305, SHAKE256
...
* 5) TLS_SHA256
* 6) TLS_SHA384
* 7) TLS_SHA512
Perhaps:
* AES-CCM-16-64-128, SHA-256 (default)
* A128GCM, SHA-256
* A256GCM, SHA-384
* ChaCha20/Poly1305, SHA-256
* ChaCha20/Poly1305, SHAKE256
...
* TLS_SHA256
* TLS_SHA384
* TLS_SHA512
-->
<t>This specification uses the HKDF as defined in <xref target="RFC5869"
/> to derive the necessary key material. Since the key derivation process uses t
he MSK, which is considered fresh key material, the HKDF-Expand function (shorte
ned here as "KDF") will be used. See <xref target="limit_eap_medhods"/> regardin
g why the use of this function is enough and it is not necessary to use KDF-Extr
act.</t>
</section> </section>
<section anchor="OSCORE"> <section anchor="OSCORE">
<name>Deriving the OSCORE Security Context</name> <name>Deriving the OSCORE Security Context</name>
<t>The derivation of the security context for OSCORE allows securing the <t>The derivation of the OSCORE security context allows securing the com
communication between the EAP peer and the EAP authenticator once the MSK has b munication between the EAP peer and the EAP authenticator once the MSK has been
een exported, providing confidentiality, integrity, key confirmation (Steps 7 an exported, providing confidentiality, integrity, key confirmation (Steps 7 and 8)
d 8), and downgrading attack detection.</t> , and detection of downgrading attacks.
<t>Once Master Secret and Master Salt are derived, they can be used to d
erive the rest of the OSCORE Security Context (see Section 3.2.1 of <xref target <!-- [rfced] Section 6.2: Does "Steps 7 and 8" here refer to
="RFC8613"/>). It should be noted that ID Context is not provided for the OSCORE Steps 7 and 8 in Figure 3? If yes, for ease of the reader we suggest
Security Context derivation.</t> adding a citation for Figure 3.
Original:
The derivation of the security context for OSCORE allows securing the
communication between the EAP peer and the EAP authenticator once the
MSK has been exported, providing confidentiality, integrity, key
confirmation (Steps 7 and 8), and downgrading attack detection. -->
</t>
<t>Once the Master Secret and Master Salt are derived, they can be used
to derive the rest of the OSCORE Security Context (see <xref target="RFC8613" se
ctionFormat="of" section="3.2.1"/>). It should be noted that the ID Context is n
ot provided for the OSCORE Security Context derivation.</t>
<t>The Master Secret can be derived by using the chosen cipher suite and the KDF as follows:</t> <t>The Master Secret can be derived by using the chosen cipher suite and the KDF as follows:</t>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length) Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length)
]]></artwork> ]]></artwork>
<t>where:</t> <t>where:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The MSK exported by the EAP method. Discussion about the use of t he MSK for key derivation is done in <xref target="security_considerations"/>.</ t> <t>The MSK is exported by the EAP method. The use of the MSK for key derivation is discussed in <xref target="security_considerations"/>.</t>
</li> </li>
<li> <li>
<t>CS is the concatenation of the content of the cipher suite negoti <t>CS is the concatenation of the content of the cipher suite negoti
ation, that is, the concatenation of two CBOR arrays CS-C and CS-I (with CBOR in ation -- that is, the concatenation of two CBOR arrays CS-C and CS-I (with CBOR
ts as elements), as defined in <xref target="cbor-coap-eap"/>. If CS-C or CS-I w ints as elements), as defined in <xref target="cbor-coap-eap"/>. If neither CS-C
ere not sent, (i.e., default algorithms are used) the value used to generate CS nor CS-I was sent (i.e., default algorithms are used), the value used to genera
will be the same as if the default algorithms were explicitly sent in CS-C or CS te CS will be the same as if the default algorithms were explicitly sent in CS-C
-I (i.e., a CBOR array with the cipher suite 0).</t> or CS-I (i.e., a CBOR array with the cipher suite value of 0).
<!-- [rfced] Section 6.2: We clarified these sentences as noted
below. If these updates are incorrect, please clarify "the cipher
suite 0".
Original:
If CS-C or CS-I were not sent, (i.e., default algorithms are used)
the value used to generate CS will be the same as if the default
algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR
array with the cipher suite 0).
...
If CS-C or CS-I were not sent, (i.e., default algorithms are used)
the value used to generate CS will be the same as if the default
algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR
array with the cipher suite 0).
Currently:
If neither CS-C nor CS-I was sent (i.e., default algorithms are
used), the value used to generate CS will be the same as if the
default algorithms were explicitly sent in CS-C or CS-I (i.e., a
CBOR array with the cipher suite value of 0).
...
If neither CS-C nor CS-I was sent (i.e., default algorithms are
used), the value used to generate CS will be the same as if the
default algorithms were explicitly sent in CS-C or CS-I (i.e., a
CBOR array with the cipher suite value of 0). -->
</t>
</li> </li>
<li> <li>
<t>"COAP-EAP OSCORE MASTER SECRET" is the ASCII code representation <t>"COAP-EAP OSCORE MASTER SECRET" is the ASCII code representation
of the non-NULL terminated string (excluding the double quotes around it).</t> of the non-NULL-terminated string (excluding the double quotes around it).</t>
<!-- [rfced] Please review instances of the term "NULL" as used in this
document and let us know if any updates are needed. We believe that
"NULL" should be updated to either "NUL" (that is, referring to the
specific ASCII control code) or "null". -->
</li> </li>
<li> <li>
<t>CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated.</t> <t>CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated.</t>
</li> </li>
<li> <li>
<t>length is the size of the output key material.</t> <t>length is the size of the output key material.</t>
</li> </li>
</ul> </ul>
<t>The Master Salt, similarly to the Master Secret, can be derived as fo
llows:</t> <t>Similarly to the Master Secret, the Master Salt can be derived as fol
lows:</t>
<artwork align="center"><![CDATA[ <artwork align="center"><![CDATA[
Master Salt = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SALT", length) Master Salt = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SALT", length)
]]></artwork> ]]></artwork>
<t>where:</t> <t>where:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>The MSK is exported by the EAP method. Discussion about the use o f the MSK for the key derivation is done in <xref target="security_consideration s"/>.</t> <t>The MSK is exported by the EAP method. The use of the MSK for key derivation is discussed in <xref target="security_considerations"/>.</t>
</li> </li>
<li> <li>
<t>CS is the concatenation of the content of the cipher suite negoti ation, that is, the concatenation of two CBOR arrays CS-C and CS-I (with CBOR in ts as elements), as defined in <xref target="cbor-coap-eap"/>. If CS-C or CS-I w ere not sent, (i.e., default algorithms are used) the value used to generate CS will be the same as if the default algorithms were explicitly sent in CS-C or CS -I (i.e., a CBOR array with the cipher suite 0).</t> <t>CS is the concatenation of the content of the cipher suite negoti ation -- that is, the concatenation of two CBOR arrays CS-C and CS-I (with CBOR ints as elements), as defined in <xref target="cbor-coap-eap"/>. If neither CS-C nor CS-I was sent (i.e., default algorithms are used), the value used to genera te CS will be the same as if the default algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR array with the cipher suite value of 0).</t>
</li> </li>
<li> <li>
<t>"COAP-EAP OSCORE MASTER SALT" is the ASCII code representation of the non-NULL-terminated string (excluding the double quotes around it).</t> <t>"COAP-EAP OSCORE MASTER SALT" is the ASCII code representation of the non-NULL-terminated string (excluding the double quotes around it).</t>
</li> </li>
<li> <li>
<t>CS and "COAP-EAP OSCORE MASTER SALT" are concatenated.</t> <t>CS and "COAP-EAP OSCORE MASTER SALT" are concatenated.</t>
</li> </li>
<li> <li>
<t>length is the size of the output key material.</t> <t>length is the size of the output key material.</t>
</li> </li>
</ul> </ul>
<t>Since the MSK is used to derive the Master Key, the correct verificat
ion of the OSCORE protected request (Step 7) and response (Step 8) confirms the <t>Since the MSK is used to derive the Master Key, the correct verificat
EAP authenticator and the EAP peer have the same Master Secret, achieving key co ion of the OSCORE-protected request (Step 7) and response (Step 8) confirms that
nfirmation.</t> the EAP authenticator and the EAP peer have the same Master Secret, achieving k
<t>To prevent a downgrading attack, the content of the cipher suite nego ey confirmation.</t>
tiation (which is referred to here as CS) is embedded in the Master Secret deriv <t>To prevent a downgrading attack, the content of the cipher suite
ation. If an attacker changes the value of the cipher suite negotiation, the res (referred to here as "CS") negotiation is embedded in the Master Secret derivati
ult will be different OSCORE security contexts, which ends up with a failure in on. If an attacker changes the value of the cipher suite negotiation, the result
Steps 7 and 8.</t> will be different OSCORE security contexts, which in turn will result in failur
<t>The EAP authenticator will use the Recipient ID of the EAP peer (RID- e in Steps 7 and 8.</t>
I) as the Sender ID for its OSCORE Sender Context. The EAP peer will use this va <t>The EAP authenticator will use the Recipient ID of the EAP peer (RID-
lue as Recipient ID for its Recipient Context.</t> I) as the Sender ID for its OSCORE Sender Context. The EAP peer will use this va
<t>The EAP peer will use the Recipient ID of the EAP authenticator (RID- lue as the Recipient ID for its Recipient Context.</t>
C) as the Sender ID for its OSCORE Sender Context. The EAP authenticator will us <t>The EAP peer will use the Recipient ID of the EAP authenticator (RID-
e this value as Recipient ID for its Recipient Context.</t> C) as the Sender ID for its OSCORE Sender Context. The EAP authenticator will us
e this value as the Recipient ID for its Recipient Context.</t>
</section> </section>
</section> </section>
<section anchor="implementation_considerations"> <section anchor="implementation_considerations">
<name>Discussion</name> <name>Discussion</name>
<section anchor="coap-as-eap-lower-layer"> <section anchor="coap-as-eap-lower-layer">
<name>CoAP as EAP lower layer</name> <name>CoAP as the EAP Lower Layer</name>
<t>This section discusses the suitability of the CoAP protocol as EAP lo <t>This section discusses the suitability of CoAP as the EAP lower layer
wer layer and reviews the requisites imposed by EAP on any protocol transporting and reviews the requisites imposed by EAP on any protocol transporting EAP. Wha
EAP. What EAP expects from its lower layers can be found in Section 3.1 of <xre t EAP expects from its lower layers can be found in <xref target="RFC3748" secti
f target="RFC3748"/>, which is elaborated next:</t> onFormat="of" section="3.1"/>, which is elaborated next:</t>
<t>Unreliable transport. EAP does not assume that lower layers are relia <dl spacing="normal" newline="false">
ble, but it can benefit from a reliable lower layer. In this sense, CoAP provide <dt>Unreliable transport:</dt><dd>EAP does not assume that lower layers
s a reliability mechanism (e.g., using Confirmable messages).</t> are reliable, but it can benefit from a reliable lower layer. In this sense, CoA
<t>Lower layer error detection. EAP relies on lower layer error detectio P provides a reliability mechanism (e.g., using Confirmable messages).</dd>
n (e.g., CRC, checksum, MIC, etc.). For simplicity, CoAP-EAP delegates error det <dt>Lower-layer error detection:</dt><dd>EAP relies on lower-layer error
ection to the lower layers, such as the link layer or transport layer (e.g., UDP detection (e.g., CRC, checksum, Message Integrity Check (MIC), etc.). For simpl
over IPv6 or TCP).</t> icity, CoAP-EAP delegates error detection to the lower layers, such as the link
<t>Lower layer security. EAP does not require security services from the layer or transport layer (e.g., UDP over IPv6 or TCP).</dd>
lower layers.</t> <dt>Lower-layer security:</dt><dd>EAP does not require security services
<t>Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 oc from the lower layers.</dd>
tets or greater. CoAP assumes an upper bound of 1024 octets for its payload, whi <dt>Minimum MTU:</dt><dd>Lower layers need to provide an EAP MTU size of
ch covers the EAP requirements when in the CoAP payload only the EAP message is 1020 octets or greater. CoAP assumes an upper bound of 1024 octets for its payl
sent. In the case of Messages 1 and 2 in <xref target="figure1"/>, those message oad, which covers the EAP requirements when only the EAP message is sent in the
s have extra information apart from EAP. Nevertheless, the EAP Req/Id has a fixe CoAP payload. In the case of Messages 1 and 2 in <xref target="figure3"/>, those
d length of 5 bytes. Message 2 with the EAP Resp/Id, would limit the length of t messages have extra information apart from EAP. Nevertheless, the EAP Req/Id ha
he identity being used to the CoAP payload maximum size (1024) - len( CS-I || RI s a fixed length of 5 bytes. Message 2, with the EAP Resp/Id, would limit the le
D-I ) - EAP Response header (5 bytes), which leaves enough space for sending eve ngth of the identity being used to the CoAP payload maximum size (1024) - len( C
n lengthy identities. Nevertheless, this limitation can be overcome by using CoA S-I || RID-I ) - EAP Response header (5 bytes), which leaves enough space for se
P block-wise transfer<xref target="RFC7959"/>. nding even lengthy identities. Nevertheless, this limitation can be overcome by
Note: When EAP is proxied over an AAA framework, the Access-Request packets in R using CoAP block-wise transfers <xref target="RFC7959"/>.
ADIUS <bcp14>MUST</bcp14> contain a Framed-MTU attribute with the value 1024, an Note: When EAP is proxied over a AAA framework, the Access-Request packets in RA
d the Framed-MTU AVP to 1024 in DIAMETER This attribute signals the AAA server t DIUS <bcp14>MUST</bcp14> contain a Framed-MTU attribute with a value of 1024 and
hat it should limit its responses to 1024 octets.</t> , in
<t>Ordering guarantees. EAP relies on lower layer ordering guarantees fo Diameter, the Framed-MTU Attribute-Value Pair (AVP) with a value of 1024. This i
r correct operation. Regarding message ordering, every time a new message arrive nformation signals the AAA server that it should limit its responses to 1024 oct
s at the authentication service hosted by the EAP peer, a new resource is create ets.
d, and this is indicated in a "2.01 Created" response code along with the name o
f the new resource via Location-Path or Location-Query options. This way, the ap <!-- [rfced] Section 7.1: We changed this text as noted below.
plication shows that its state has advanced.</t> Please review carefully (including our expansion of "AVP" for ease of
<t>Although the <xref target="RFC3748"/> states: "EAP provides its own s the reader), and let us know if anything is incorrect.
upport for duplicate elimination and retransmission", EAP is also reliant on low
er layer ordering guarantees. In this regard, <xref target="RFC3748"/> talks abo Original:
ut possible duplication and says: "Where the lower layer is reliable, it will pr Note: When EAP
ovide the EAP layer with a non-duplicated stream of packets. However, while it i is proxied over an AAA framework, the Access-Request packets in
s desirable that lower layers provide for non-duplication, this is not a require RADIUS MUST contain a Framed-MTU attribute with the value 1024, and
ment". CoAP provides a non-duplicated stream of packets and accomplishes the des the Framed-MTU AVP to 1024 in DIAMETER This attribute signals the AAA
irable non-duplication. In addition, <xref target="RFC3748"/> says that when EAP server that it should limit its responses to 1024 octets.
runs over a reliable lower layer "the authenticator retransmission timer <bcp14
>SHOULD</bcp14> be set to an infinite value, so that retransmissions do not occu Currently:
r at the EAP layer."</t> Note: When EAP is proxied over a AAA framework, the
Access-Request packets in RADIUS MUST contain a Framed-MTU
attribute with a value of 1024 and, in Diameter, the Framed-MTU
Attribute-Value Pair (AVP) with a value of 1024. This information
signals the AAA server that it should limit its responses to 1024
octets. -->
</dd>
<dt>Ordering guarantees:</dt><dd>EAP relies on lower-layer ordering guar
antees for correct operation. Regarding message ordering, every time a new messa
ge arrives at the authentication service hosted by the EAP peer, a new resource
is created, and this is indicated in a "2.01 Created" response code along with t
he name of the new resource via Location-Path or Location-Query options. This wa
y, the application shows that its state has advanced.</dd>
</dl>
<!-- Quoted text is DNE; [LB] verified all three quoted excerpts. -->
<t>Although <xref target="RFC3748"/> states that "EAP provides its own s
upport for duplicate elimination and retransmission," EAP is also reliant on
lower-layer ordering guarantees. In this regard, <xref target="RFC3748"/> talks
about possible duplication and says, "Where the lower layer is reliable, it will
provide the EAP layer with a non-duplicated stream of packets. However, while i
t is desirable that lower layers provide for non-duplication, this is not a requ
irement." CoAP provides a non-duplicated stream of packets and accomplishes the
desirable non-duplication. In addition, <xref target="RFC3748"/> says that when
EAP runs over a reliable lower layer "the authenticator retransmission timer <bc
p14>SHOULD</bcp14> be set to an infinite value, so that retransmissions do not o
ccur at the EAP layer."</t>
</section> </section>
<section anchor="size-of-the-eap-lower-layer-vs-eap-method-size"> <section anchor="size-of-the-eap-lower-layer-vs-eap-method-size">
<name>Size of the EAP lower layer vs EAP method size</name> <name>Size of the EAP Lower Layer vs. EAP Method Size</name>
<t>Regarding the impact that an EAP lower layer will have on the number <t>Regarding the impact that an EAP lower layer will have on the number
of bytes of the whole authentication exchange, there is a comparison with anothe of bytes of the whole authentication exchange, <xref target="CoAP-EAP"/> provide
r network layer-based EAP lower layer, PANA <xref target="RFC5191"/>, in <xref t s a comparison with another network-layer-based EAP lower layer, the Protocol fo
arget="coap-eap"/>.</t> r Carrying Authentication for Network Access (PANA) as defined in <xref target="
<t>The EAP method being transported will take most of the exchange, howe RFC5191"/>.</t>
ver, the impact of the EAP lower layer cannot be ignored, especially in very con <t>The EAP method being transported will take most of the exchange. Howe
strained communication technologies, such as the ones found in IoT, with limited ver, the impact of the EAP lower layer cannot be ignored, especially in very con
capabilities.</t> strained communication technologies such as those with limited capabilities (e.g
<t>Note: For constrained devices and network scenarios, the use of the l ., as can be found in IoT networks).</t>
atest versions of EAP methods (e.g., EAP-AKA' <xref target="RFC5448"/>, EAP-TLS <t>Note: For scenarios involving constrained devices and networks, the u
1.3 <xref target="RFC9190"/>) is recommended in favor of older versions with the se of the latest versions of EAP methods (e.g., EAP-AKA' <xref target="RFC5448"/
goal of economization, or EAP methods more adapted for IoT (e.g., EAP-NOOB <xre >, EAP-TLS 1.3 <xref target="RFC9190"/>) is recommended in favor of older versio
f target="RFC9140"/>, EAP-EDHOC <xref target="I-D.ietf-emu-eap-edhoc"/>, etc.).< ns with the goal of economizing, or EAP methods more adapted for IoT networks (e
/t> .g., EAP-NOOB <xref target="RFC9140"/>, EAP-EDHOC <xref target="I-D.ietf-emu-eap
-edhoc"/>, etc.).</t>
<!-- [rfced] Section 7.2: This sentence is difficult to parse. If
the suggested text is not correct, please rephrase "constrained
devices and network scenarios" and "older versions with the goal of
economization".
Also, please review and let us know whether this "Note:" item that is
set off in a separate paragraph should be in the <aside> element.
<aside> is defined as "a container for content that is semantically
less important or tangential to the content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
Original:
Note: For constrained devices and network scenarios, the use of the
latest versions of EAP methods (e.g., EAP-AKA' [RFC5448], EAP-TLS 1.3
[RFC9190]) is recommended in favor of older versions with the goal of
economization, or EAP methods more adapted for IoT (e.g., EAP-NOOB
[RFC9140], EAP-EDHOC [I-D.ietf-emu-eap-edhoc], etc.).
Suggested:
Note: To improve efficiency in environments with
constrained devices and networks, the latest versions of EAP methods
(e.g., EAP-AKA' [RFC5448], EAP-TLS 1.3 [RFC9190]) are recommended over
older versions. EAP methods more adapted for IoT networks (e.g.,
EAP-NOOB [RFC9140], EAP-EDHOC [EAP-EDHOC], etc.) are also
recommended. -->
</section> </section>
</section> </section>
<section anchor="security_considerations"> <section anchor="security_considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>There are some security aspects to be considered, such as how authoriza tion is managed, the use of Master Session Key (MSK) as key material, and how tr ust in the EAP authenticator is established. Additional considerations such as E AP channel binding as per <xref target="RFC6677"/> are also discussed here.</t> <t>Security aspects to be considered include how authorization is managed, the use of the MSK as key material, and how trust in the EAP authenticator is e stablished. Additional considerations such as EAP channel binding as per <xref t arget="RFC6677"/> are also discussed here.</t>
<section anchor="limit_eap_medhods"> <section anchor="limit_eap_medhods">
<name>Use of EAP Methods</name> <name>Use of EAP Methods</name>
<t>This document limits the use of EAP methods to the ones compliant wit h <xref target="RFC4017"/> specification, yielding strong and fresh session keys such as the MSK. By this assumption, the HKDF-Expand function is used directly, as clarified in <xref target="RFC5869"/>.</t> <t>This document limits the use of EAP methods to those compliant with < xref target="RFC4017"/>, yielding strong and fresh session keys such as the MSK. By this assumption, the HKDF-Expand function is used directly, as clarified in <xref target="RFC5869"/>.</t>
</section> </section>
<section anchor="authorization"> <section anchor="authorization">
<name>Authorization</name> <name>Authorization</name>
<t>Authorization is part of bootstrapping. It serves to establish whethe <t>Authorization is part of bootstrapping. It serves to establish whethe
r the EAP peer can join and the set of conditions it must adhere to. The authori r the EAP peer can join and the set of conditions it must adhere to. The authori
zation data will be gathered from the organization that is responsible for the E zation data will be gathered from the organization that is responsible for the E
AP peer and sent to the EAP authenticator in case AAA infrastructure is deployed AP peer and sent to the EAP authenticator if a AAA infrastructure is deployed.</
.</t> t>
<t>In standalone mode, the authorization information will be in the EAP <t>In standalone mode, the authorization information will be in the EAP
authenticator. If the pass-through mode is used, authorization data received fro authenticator. If pass-through mode is used, authorization data received from th
m the AAA server can be delivered by the AAA protocol (e.g., RADIUS or Diameter) e AAA server can be delivered by the AAA protocol (e.g., RADIUS or Diameter). P
. Providing more fine-grained authorization data can be with the transport of S roviding more fine-grained authorization data can be done by transporting the da
AML in RADIUS <xref target="RFC7833"/>. ta using the Security Assertion Markup Language (SAML) in RADIUS <xref target="R
After bootstrapping, additional authorization information may be needed to opera FC7833"/>.
te in the security domain. This can be taken care of by the solutions proposed i After bootstrapping, additional authorization information may be needed to opera
n the ACE WG, such as the use of OAuth <xref target="RFC9200"/>, among other sol te in the security domain. This can be taken care of by the solutions proposed i
utions, to provide Authentication and Authorization for Constrained Environments n the Authentication and Authorization for Constrained Environments (ACE) WG, su
.</t> ch as the use of OAuth <xref target="RFC9200"/>, among other solutions, to provi
de ACE.
<!-- [rfced] Section 8.2: This sentence did not parse. We updated
it as noted below. If this update is incorrect, please clarify
"can be with the transport of SAML".
Original:
Providing more fine-grained
authorization data can be with the transport of SAML in RADIUS
[RFC7833].
Currently:
Providing more fine-grained
authorization data can be done by transporting the data using the
Security Assertion Markup Language (SAML) in RADIUS [RFC7833]. -->
</t>
</section> </section>
<section anchor="allowing-coap-eap-traffic-to-perform-authentication"> <section anchor="allowing-coap-eap-traffic-to-perform-authentication">
<name>Allowing CoAP-EAP traffic to perform authentication</name> <name>Allowing CoAP-EAP Traffic to Perform Authentication</name>
<t>Since CoAP is an application protocol, CoAP-EAP assumes certain IP co <t>Since CoAP is an application protocol, CoAP-EAP assumes certain IP co
nnectivity in the link between the EAP peer and the EAP authenticator to run. Th nnectivity in the link between the EAP peer and the EAP authenticator to run. Th
is link <bcp14>MUST</bcp14> authorize exclusively unprotected IP traffic to be s is link <bcp14>MUST</bcp14> authorize exclusively unprotected IP traffic to be s
ent between the EAP peer and the EAP authenticator during the authentication wit ent between the EAP peer and the EAP authenticator during the authentication wit
h CoAP-EAP. Once the authentication is successful, the key material generated by h CoAP-EAP. Once the authentication is successful, the key material generated by
the EAP authentication (MSK) and any other traffic can be authorized if it is p the EAP authentication (MSK) and any other traffic can be authorized if it is p
rotected. It is worth noting that if the EAP authenticator is not in the same li rotected. It is worth noting that if the EAP authenticator is not in the same li
nk as the EAP peer and an intermediate entity helps with this process (i.e., CoA nk as the EAP peer and an intermediate entity (i.e., a CoAP proxy) helps with th
P proxy) and the same comment applies to the communication between the EAP peer is process, this
and the intermediary.</t> concept also applies to the communication between the EAP peer and the intermedi
<t>Alternatively, the link-layer <bcp14>MAY</bcp14> provide support to t ary.
ransport CoAP-EAP without an IP address by using link-layer frames (e.g. by defi
ning a new Key Management Protocol ID in IEEE 802.15.9 <xref target="ieee802159" <!-- [rfced] Section 8.3:
/>).</t>
a) To what does "exclusively" refer in this sentence? If the
suggested text is not correct, please clarify.
Original (the previous sentence is included for context):
Since CoAP is an application protocol, CoAP-EAP assumes certain IP
connectivity in the link between the EAP peer and the EAP
authenticator to run. This link MUST authorize exclusively
unprotected IP traffic to be sent between the EAP peer and the EAP
authenticator during the authentication with CoAP-EAP.
Suggested:
This link MUST only authorize
unprotected IP traffic to be sent between the EAP peer and the EAP
authenticator during the authentication with CoAP-EAP.
b) This sentence did not parse. We updated it to make a complete
sentence. Please review this update carefully; if it is incorrect,
please clarify.
Original:
It is worth noting that if the EAP authenticator is not
in the same link as the EAP peer and an intermediate entity helps
with this process (i.e., CoAP proxy) and the same comment applies to
the communication between the EAP peer and the intermediary.
Currently:
It is worth noting that if the EAP authenticator is not
in the same link as the EAP peer and an intermediate entity (i.e., a
CoAP proxy) helps with this process, this concept also applies to the
communication between the EAP peer and the intermediary. -->
</t>
<t>Alternatively, the link layer <bcp14>MAY</bcp14> provide support to t
ransport CoAP-EAP without an IP address by using link-layer frames (e.g., by def
ining a new Key Management Protocol ID per IEEE 802.15.9 <xref target="IEEE80215
9"/>).</t>
</section> </section>
<section anchor="freshness-of-the-key-material"> <section anchor="freshness-of-the-key-material">
<name>Freshness of the key material</name> <name>Freshness of the Key Material</name>
<t>In CoAP-EAP there is no nonce exchange to provide freshness to the ke <t>In CoAP-EAP, there is no nonce exchange to provide freshness to the k
ys derived from the MSK. The MSK and Extended Master Session Key (EMSK) keys acc eys derived from the MSK. The MSKs and EMSKs are fresh key material per <xref ta
ording to the EAP Key Management Framework <xref target="RFC5247"/> are fresh ke rget="RFC5247"/>. Since only one authentication is established per EAP authentic
y material. Since only one authentication is established per EAP authenticator, ator, there is no need to generate additional key material. If a new MSK is requ
there is no need to generate additional key material. In case a new MSK is requi ired, a re-authentication can be done by running the process again or using a mo
red, a re-authentication can be done, by running the process again or using a mo re lightweight EAP method to derive additional key material as elaborated in <xr
re lightweight EAP method to derive additional key material as elaborated in <xr ef target="re-authentication"/>.</t>
ef target="re-authentication"/>.</t>
</section> </section>
<section anchor="channel-binding-support"> <section anchor="channel-binding-support">
<name>Channel Binding support</name> <name>Channel-Binding Support</name>
<t>According to the <xref target="RFC6677"/>, channel binding, related t <t>According to <xref target="RFC6677"/>, channel binding, as related to
o EAP, is sent through the EAP method supporting it.</t> EAP, is sent through the EAP method supporting it.</t>
<t>To satisfy the requirements of the document, the EAP lower layer iden
tifier (To be assigned by IANA) needs to be sent, in the EAP Lower-Layer Attribu <t>To satisfy the requirements of the document, the EAP lower-layer iden
te if RADIUS is used.</t> tifier (assigned by IANA) needs to be sent, in the EAP Lower-Layer Attribute if
RADIUS is used.
<!-- [rfced] Section 8.5: Does "the document" refer to RFC 6677 or
this document? Also, how may we update "(To be assigned by IANA)"?
Original (the previous paragraph is included for context):the d
According to the [RFC6677], channel binding, related to EAP, is sent
through the EAP method supporting it.
To satisfy the requirements of the document, the EAP lower layer
identifier (To be assigned by IANA) needs to be sent, in the EAP
Lower-Layer Attribute if RADIUS is used.
Perhaps:
To satisfy the requirements of this document, the EAP lower-layer
identifier for CoAP-EAP (10) needs to be sent, in the EAP
Lower-Layer Attribute if RADIUS is used.
Or:
To satisfy the requirements of this document, the EAP lower-layer
identifier assigned by IANA (see Section 9.4) needs to be sent, in the EAP
Lower-Layer Attribute if RADIUS is used.
-->
</t>
</section> </section>
<section anchor="additional-security-considerations"> <section anchor="additional-security-considerations">
<name>Additional Security Considerations</name> <name>Additional Security Considerations</name>
<t>In the authentication process, there is a possibility of an entity fo <t>In the authentication process, it is possible for an entity to forge
rging messages to generate denial of service (DoS) attacks on any of the entitie messages to generate denial-of-service (DoS) attacks on any of the entities invo
s involved. For instance, an attacker can forge multiple initial messages to sta lved. For instance, an attacker can forge multiple initial messages to start an
rt an authentication (Step 0) with the EAP authenticator as if they were sent by authentication (Step 0) with the EAP authenticator as if they were sent by diffe
different EAP peers. Consequently, the EAP authenticator will start an authenti rent EAP peers. Consequently, the EAP authenticator will start an authentication
cation process for each message received in Step 0, sending the EAP Request/Id ( process for each message received in Step 0, sending the EAP Request/Id (Step 1
Step 1).</t> ).
<t>To minimize the effects of this DoS attack, it is <bcp14>RECOMMENDED<
/bcp14> that the EAP authenticator limits the rate at which it processes incomin <!-- [rfced] Section 8.6: Does "Step 0" here refer to Step 0 in
g messages in Step 0 to provide robustness against denial of service (DoS) attac Figure 3 or Step 0 in Figure 5? For ease of the reader, we suggest
ks. The details of rate limiting are outside the scope of this specification. Ne adding a citation for the appropriate figure.
vertheless, the rate of these messages is also limited by the bandwidth availabl
e between the EAP peer and the EAP authenticator. This bandwidth will be especia Original:
lly limited in constrained links (e.g., LPWAN). Lastly, it is also <bcp14>RECOMM For instance, an attacker can forge
ENDED</bcp14> to reduce at a minimum the state in the EAP authenticator at least multiple initial messages to start an authentication (Step 0) with
until the EAP Response/Id is received by the EAP authenticator.</t> the EAP authenticator as if they were sent by different EAP peers. -->
<t>Another security-related concern is how to ensure that the EAP peer j
oining the security domain can trust the EAP authenticator. This issue is elabor </t>
ated in the EAP Key Management Framework <xref target="RFC5247"/>. In particular <t>To minimize the effects of this DoS attack, it is <bcp14>RECOMMENDED<
, the EAP peer knows it can trust the EAP authenticator because the key that is /bcp14> that the EAP authenticator limit the rate at which it processes incoming
used to establish the security association is derived from the MSK. If the EAP a messages in Step 0 to provide robustness against DoS attacks. The details of ra
uthenticator has the MSK, it is because the AAA Server of the EAP peer trusted t te limiting are outside the scope of this specification. Nevertheless, the rate
he EAP authenticator.</t> of these messages is also limited by the bandwidth available between the EAP pee
r and the EAP authenticator. This bandwidth will be especially limited in constr
ained links (e.g., Low-Power WANs (LPWANs)). Lastly, it is also <bcp14>RECOMMEND
ED</bcp14> to reduce at a minimum the state in the EAP authenticator at least un
til the EAP Response/Id is received by the EAP authenticator.</t>
<t>Another security-related concern is how to ensure that the EAP peer j
oining the security domain can trust the EAP authenticator. This issue is elabor
ated in <xref target="RFC5247"/>. In particular, the EAP peer knows it can trust
the EAP authenticator because the key that is used to establish the security as
sociation is derived from the MSK. If the EAP authenticator has the MSK, it is b
ecause the AAA server of the EAP peer trusted the EAP authenticator.</t>
</section> </section>
</section> </section>
<section anchor="IANA"> <section anchor="IANA">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This section provides guidance to the Internet Assigned Numbers Authori ty (IANA) regarding the registration of values related to CoAP-EAP.</t>
<section anchor="ciphersuite"> <section anchor="ciphersuite">
<name>CoAP-EAP Cipher Suites</name> <name>CoAP-EAP Cipher Suites</name>
<t>IANA has created a new registry titled "CoAP-EAP Cipher Suites" under
the new group name "CoAP-EAP protocol". The registration procedures are "Speci <!-- [IANA FLAG] Took out the extra "Specification Required" in the
fication Required", "Private Use", "Standards Action with Expert Review" and "Sp text here (Section 9.1) and in Sections 9.2 and 9.8; it's a list
ecification Required" following the indications in <xref target="ciphersute-regi of the categories, so no need to list "Specification Required"
stration-ranges"/>.</t> twice in each sentence. -->
<t>IANA has created a new registry titled "CoAP-EAP Cipher Suites" under
a new registry group named "CoAP-EAP Protocol". The registration procedures ar
e "Specification
Required", "Private Use", and "Standards Action with Expert Review" (see <xref t
arget="RFC8126"/>), as shown in <xref target="ciphersute-registration-ranges"/>.
<!-- [rfced] Sections 9.1 and 9.2: The name "CoAP-EAP protocol" for the new
registry group reads oddly, as it means "Constrained Application
Protocol-Extensible Authentication Protocol protocol". May we change the
name of the new registry group to "CoAP-EAP"?
If yes, we will ask IANA to update the registry group name on
<https://www.iana.org/assignments/coap-eap/coap-eap.xhtml>.
(We could not find an existing IANA registry with the name "CoAP-EAP",
so this name would be unique (but we would confirm this with IANA).)
Original:
IANA has created a new registry titled "CoAP-EAP Cipher Suites" under
the new group name "CoAP-EAP protocol".
...
IANA has created a new registry titled "CoAP-EAP Information element"
under the new group name "CoAP-EAP protocol". -->
</t>
<table anchor="ciphersute-registration-ranges"> <table anchor="ciphersute-registration-ranges">
<name>CoAP-EAP Cipher Suites Registration Procedures</name> <name>Registration Procedures for CoAP-EAP Cipher Suites</name>
<thead> <thead>
<tr> <tr>
<th align="center">Range</th> <th>Range</th>
<th align="center">Registration Procedures</th> <th>Registration Procedures</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">-65536 to -25</td> <td>-65536 to -25</td>
<td align="center">Specification Required</td> <td>Specification Required</td>
</tr> </tr>
<tr> <tr>
<td align="center">-24 to -21</td> <td>-24 to -21</td>
<td align="center">Private Use</td> <td>Private Use</td>
</tr> </tr>
<tr> <tr>
<td align="center">-20 to 23</td> <td>-20 to 23</td>
<td align="center">Standards Action with Expert Review</td> <td>Standards Action with Expert Review</td>
</tr> </tr>
<tr> <tr>
<td align="center">24 to 65535</td> <td>24 to 65535</td>
<td align="center">Specification Required</td> <td>Specification Required</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The columns of the registry are Value, Algorithms, Description and Re ference, where Value is an integer, and the other columns are text strings. The initial contents of the registry are shown in <xref target="ciphersute-initial- value"/>.</t> <t>The columns of the registry are Value, Algorithms, Description, and R eference, where Value is an integer and the other columns are text strings. The initial registrations are shown in <xref target="ciphersute-initial-value"/>.</ t>
<table anchor="ciphersute-initial-value"> <table anchor="ciphersute-initial-value">
<name>CoAP-EAP Cipher Suites initial values</name> <name>CoAP-EAP Cipher Suites: Initial Registrations</name>
<thead> <thead>
<tr> <tr>
<th align="left">Value</th> <th align="left">Value</th>
<th align="left">Algorithms</th> <th align="left">Algorithms</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">10, -16</td> <td align="left">10, -16</td>
<td align="left">AES-CCM-16-64-128, SHA-256</td> <td align="left">AES-CCM-16-64-128, SHA-256</td>
<td align="left">[[this document]]</td> <td align="left">RFC 9820</td>
</tr> </tr>
<tr> <tr>
<td align="left">1</td> <td align="left">1</td>
<td align="left">1, -16</td> <td align="left">1, -16</td>
<td align="left">A128GCM, SHA-256</td> <td align="left">A128GCM, SHA-256</td>
<td align="left">[[this document]]</td> <td align="left">RFC 9820</td>
</tr> </tr>
<tr> <tr>
<td align="left">2</td> <td align="left">2</td>
<td align="left">3, -43</td> <td align="left">3, -43</td>
<td align="left">A256GCM, SHA-384</td> <td align="left">A256GCM, SHA-384</td>
<td align="left">[[this document]]</td> <td align="left">RFC 9820</td>
</tr> </tr>
<tr> <tr>
<td align="left">3</td> <td align="left">3</td>
<td align="left">24, -16</td> <td align="left">24, -16</td>
<td align="left">ChaCha20/Poly1305, SHA-256</td> <td align="left">ChaCha20/Poly1305, SHA-256</td>
<td align="left">[[this document]]</td> <td align="left">RFC 9820</td>
</tr> </tr>
<tr> <tr>
<td align="left">4</td> <td align="left">4</td>
<td align="left">24, -45</td> <td align="left">24, -45</td>
<td align="left">ChaCha20/Poly1305, SHAKE256</td> <td align="left">ChaCha20/Poly1305, SHAKE256</td>
<td align="left">[[this document]]</td> <td align="left">RFC 9820</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="llid"> <section anchor="llid">
<name>CDDL in CoAP-EAP Information elements</name> <name>CDDL in CoAP-EAP Information Elements</name>
<t>IANA has created a new registry titled "CoAP-EAP Information element" <t>IANA has created a new registry titled "CoAP-EAP Information Elements
under the new group name "CoAP-EAP protocol". The registration procedure are " " under a new registry group named "CoAP-EAP Protocol". The registration proced
Specification Required", "Private Use", "Standards Action with Expert Review" an ures are "Standards Action with Expert Review", "Private Use", "Specification Re
d "Specification Required" following the indications in <xref target="coap-eap- quired", and "Experimental Use" (see <xref target="RFC8126"/>),
ie-registration-ranges"/>.</t> as shown in <xref target="coap-eap-ie-registration-ranges"/>.
</t>
<table anchor="coap-eap-ie-registration-ranges"> <table anchor="coap-eap-ie-registration-ranges">
<name>CoAP-EAP Information Elements Registration Procedures</name> <name>Registration Procedures for CoAP-EAP Information Elements</name>
<thead> <thead>
<tr> <tr>
<th align="center">Range</th> <th>Range</th>
<th align="center">Registration Procedures</th> <th>Registration Procedures</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">0 to 23</td> <td>0 to 23</td>
<td align="center">Standards Action with Expert Review</td> <td>Standards Action with Expert Review</td>
</tr> </tr>
<tr> <tr>
<td align="center">24 to 49</td> <td>24 to 49</td>
<td align="center">Private Use</td> <td>Private Use</td>
</tr> </tr>
<tr> <tr>
<td align="center">50 to 65000</td> <td>50 to 65000</td>
<td align="center">Specification Required</td> <td>Specification Required</td>
</tr> </tr>
<tr> <tr>
<td align="center">65001 to 65535</td> <td>65001 to 65535</td>
<td align="center">Experimental Use</td> <td>Experimental Use</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t>The columns of the registry are Name, Label, CBOR Type, Description a <t>The columns of the registry are Name, Label, CBOR Type, Description,
nd Reference, where Value is an integer, and the other columns are text strings. and Reference, where Label is an integer and the other columns are text strings.
The initial contents of the registry are described in <xref target="coap-eap-i The initial registrations are shown in <xref target="coap-eap-ie-values"/>.
e-values"/>.</t>
<!-- [rfced] Section 9.2: Because there is no "Value" entity in the
"CoAP-EAP Information Elements" registry, we changed "Value" to
"Label" per <https://www.iana.org/assignments/coap-eap/>. If this is
incorrect, please clarify the list of columns in the "CoAP-EAP
Information Elements" registry.
Original:
The columns of the registry are Name, Label, CBOR Type, Description
and Reference, where Value is an integer, and the other columns are
text strings.
Currently:
The columns of the registry are Name, Label, CBOR Type, Description,
and Reference, where Label is an integer and the other columns are
text strings. -->
</t>
<table anchor="coap-eap-ie-values"> <table anchor="coap-eap-ie-values">
<name>CoAP-EAP Information Elements initial content</name> <name>CoAP-EAP Information Elements: Initial Registrations</name>
<thead> <thead>
<tr> <tr>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Label</th> <th align="left">Label</th>
<th align="left">CBOR Type</th> <th align="left">CBOR Type</th>
<th align="left">Description</th> <th align="left">Description</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">Cipher Suite</td> <td align="left">Cipher Suite</td>
<td align="left">1</td> <td align="left">1</td>
<td align="left">CBOR Array</td> <td align="left">CBOR Array</td>
<td align="left">List of the proposed or selected COSE algorithms for OSCORE</td> <td align="left">List of the proposed or selected COSE algorithms for OSCORE</td>
<td align="left">[[this document]]</td> <td align="left">RFC 9820</td>
</tr> </tr>
<tr> <tr>
<td align="left">RID-C</td> <td align="left">RID-C</td>
<td align="left">2</td> <td align="left">2</td>
<td align="left">Byte String</td> <td align="left">Byte String</td>
<td align="left">It contains the Recipient ID of the EAP authentic <td align="left">Contains the Recipient ID of the EAP authenticato
ator</td> r</td>
<td align="left">[[this document]]</td> <td align="left">RFC 9820</td>
</tr> </tr>
<tr> <tr>
<td align="left">RID-I</td> <td align="left">RID-I</td>
<td align="left">3</td> <td align="left">3</td>
<td align="left">Byte String</td> <td align="left">Byte String</td>
<td align="left">It contains the Recipient ID of the EAP peer</td> <td align="left">Contains the Recipient ID of the EAP peer</td>
<td align="left">[[this document]]</td> <td align="left">RFC 9820</td>
</tr> </tr>
<tr> <tr>
<td align="left">Session-Lifetime</td> <td align="left">Session-Lifetime</td>
<td align="left">4</td> <td align="left">4</td>
<td align="left">uint</td> <td align="left">uint</td>
<td align="left">Contains the time the session is valid in seconds <td align="left">Contains the time that the session is valid, in s
</td> econds</td>
<td align="left">[[this document]]</td> <td align="left">RFC 9820</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="wellknown"> <section anchor="wellknown">
<name>The Well-Known URI Registry</name> <name>The Well-Known URIs Registry</name>
<t>IANA has added the well-known URI "coap-eap" to the "Well-Known URIs" <t>IANA has added the well-known URI "coap-eap" to the "Well-Known URIs"
registry under the group name "Well-Known URIs" defined by <xref target="RFC86 registry under the "Well-Known URIs" registry group defined by <xref target="RF
15"/>.</t> C8615"/>.</t>
<ul spacing="normal"> <dl spacing="compact" newline="false">
<li> <dt>URI Suffix:</dt><dd>coap-eap</dd>
<t>URI suffix: coap-eap</t> <dt>Reference:</dt><dd>RFC 9820</dd>
</li> <dt>Status:</dt><dd>permanent</dd>
<li> <dt>Change Controller:</dt><dd>IETF</dd>
<t>Change controller: IETF</t> </dl>
</li>
<li>
<t>Specification document(s): [[this document]]</t>
</li>
<li>
<t>Related information: None</t>
</li>
<li>
<t>Status: permanent</t>
</li>
</ul>
</section> </section>
<section anchor="lowerlayer"> <section anchor="lowerlayer">
<name>The EAP lower layer identifier registry</name> <name>The EAP Lower Layers Registry</name>
<t>IANA has added the identifier of CoAP-EAP to the registry "EAP Lower <t>IANA has added the identifier "CoAP-EAP" to the "EAP Lower Layers" re
Layer" under the Extensible Authentication Protocol (EAP) Registry defined by <x gistry (defined by <xref target="RFC6677"/>) under the "Extensible Authenticatio
ref target="RFC6677"/>.</t> n Protocol (EAP) Registry".</t>
<ul spacing="normal"> <dl spacing="compact" newline="false">
<li> <dt>Value:</dt><dd>10</dd>
<t>Value: TBD.</t> <dt>Lower Layer:</dt><dd>CoAP-EAP</dd>
</li> <dt>Reference:</dt><dd>RFC 9820</dd>
<li> </dl>
<t>Lower Layer: CoAP-EAP</t>
</li>
<li>
<t>Specification document(s): [[this document]]</t>
</li>
</ul>
</section> </section>
<section anchor="mediatypes"> <section anchor="mediatypes">
<name>Media Types Registry</name> <name>Media Types Registry</name>
<t>IANA has added the media types "application/coap-eap" to the "Media T <t>IANA has added the media type "application/coap-eap" to the "Media Ty
ypes" registry. <xref target="coap-eap-media-type"/> defines the format.</t> pes" registry. <xref target="coap-eap-media-type"/> defines the format.</t>
<ul spacing="normal">
<li> <dl spacing="normal" newline="false">
<t>Type name: application</t> <dt>Type name:</dt><dd>application</dd>
</li> <dt>Subtype name:</dt><dd>coap-eap</dd>
<li> <dt>Required parameters:</dt><dd>N/A</dd>
<t>Subtype name: coap-eap</t> <dt>Optional parameters:</dt><dd>N/A</dd>
</li> <dt>Encoding considerations:</dt><dd>binary</dd>
<li> <dt>Security considerations:</dt><dd>See <xref target="security_consid
<t>Required parameters: N/A</t> erations"/> of RFC 9820.</dd>
</li> <dt>Interoperability considerations:</dt><dd>N/A</dd>
<li> <dt>Published specification:</dt><dd>RFC 9820</dd>
<t>Optional parameters: N/A</t> <dt>Applications that use this media type:</dt><dd>To be identified</d
</li> d>
<li> <dt>Fragment identifier considerations:</dt><dd>N/A</dd>
<t>Encoding considerations: binary</t> <dt>Additional information:</dt>
</li> <dd><t><br/></t>
<li> <dl spacing="compact">
<t>Security considerations: See <xref target="security_consideration <dt>Magic number(s):</dt><dd>N/A</dd>
s"/> of [[this document]].</t> <dt>File extension(s):</dt><dd>N/A</dd>
</li> <dt>Macintosh file type code(s):</dt><dd>N/A</dd>
<li> </dl></dd>
<t>Interoperability considerations: N/A</t> <dt>Person and email address to contact for further information:</dt><
</li> dd>ace@ietf.org</dd>
<li> <dt>Intended usage:</dt><dd>COMMON</dd>
<t>Published specification: [[this document]]</t> <dt>Restrictions on usage:</dt><dd>N/A</dd>
</li> <dt>Author:</dt><dd>See the "Authors' Addresses" section of RFC 9820.<
<li> /dd>
<t>Applications that use this media type: To be identified</t> <dt>Change Controller:</dt><dd>IETF</dd>
</li> </dl>
<li>
<t>Fragment identifier considerations: N/A</t>
</li>
<li>
<t>Additional information:
</t>
<ul spacing="normal">
<li>
<t>Magic number(s): N/A</t>
</li>
<li>
<t>File extension(s): N/A</t>
</li>
<li>
<t>Macintosh file type code(s): N/A</t>
</li>
</ul>
</li>
<li>
<t>Person and email address to contact for further information: ace@
ietf.org</t>
</li>
<li>
<t>Intended usage: COMMON</t>
</li>
<li>
<t>Restrictions on usage: N/A</t>
</li>
<li>
<t>Author: See "Authors' Addresses" section of [[this document]].</t
>
</li>
<li>
<t>Change Controller: IETF</t>
</li>
</ul>
</section> </section>
<section anchor="content-format"> <section anchor="content-format">
<name>CoAP Content-Formats Registry</name> <name>CoAP Content-Formats Registry</name>
<t>IANA has added the media types "application/coap-eap" to the "CoAP Co ntent-Formats" registry under the group name "Constrained RESTful Environments ( CoRE) Parameters" following the specification in Section 12.3 of <xref target="R FC7252"/>.</t> <t>IANA has added the media type "application/coap-eap" to the "CoAP Con tent-Formats" registry under the "Constrained RESTful Environments (CoRE) Parame ters" registry group, following the specification in <xref target="RFC7252" sect ionFormat="of" section="12.3"/>.</t>
<table anchor="content-format_registry"> <table anchor="content-format_registry">
<name>CoAP Content-Formats Registry</name> <name>CoAP Content-Formats Registry</name>
<thead> <thead>
<tr> <tr>
<th align="center">Media Type</th> <th>Media Type</th>
<th align="center">Content Encoding</th> <th>Content Encoding</th>
<th align="center">ID</th> <th>ID</th>
<th align="center">Reference</th> <th>Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="center">application/coap-eap</td> <td>application/coap-eap</td>
<td align="center">-</td> <td>-</td>
<td align="center">TBD</td> <td>269</td>
<td align="center">[[this document]]</td> <td>RFC 9820</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="resource-type"> <section anchor="resource-type">
<name>Resource Type (rt=) Link Target Attribute Values Registry</name> <name>Resource Type (rt=) Link Target Attribute Values Registry</name>
<t>IANA has added the resource type "core.coap-eap" to the "Resource Typ <t>IANA has added the resource type "core.coap-eap" to the "Resource Typ
e (rt=) Link Target Attribute Values" registry under the group name "Constrained e (rt=) Link Target Attribute Values" registry under the "Constrained RESTful En
RESTful Environments (CoRE) Parameters".</t> vironments (CoRE) Parameters" registry group.</t>
<ul spacing="normal">
<li> <table anchor="resource-type-reg">
<t>Value: "core.coap-eap" <name>Resource Type (rt=) Link Target Attribute Values Registry</name>
</t> <thead>
<ul spacing="normal"> <tr>
<li> <th>Value</th>
<t>Description: CoAP-EAP resource.</t> <th>Description</th>
</li> <th>Reference</th>
<li> </tr>
<t>Reference: [[this document]]</t> </thead>
</li> <tbody>
</ul> <tr>
</li> <td>core.coap-eap</td>
</ul> <td>CoAP-EAP resource</td>
<td>RFC 9820</td>
</tr>
</tbody>
</table>
</section> </section>
<section anchor="expert-review-instructions"> <section anchor="expert-review-instructions">
<name>Expert Review Instructions</name> <name>Expert Review Instructions</name>
<t>The IANA registries established in this document are defined as <t>The IANA registries established in this document apply the
"Specification Required", "Private Use", "Standards Action with Expert Review "Specification Required", "Private Use", "Standards Action with Expert Review
", "Experimental Use" and "Specification Required". ",
and "Experimental Use" policies. (See also <xref target="RFC8126"/>.)
This section provides general guidelines for what experts should focus on, bu t as they are designated experts for a reason, they should be granted flexibilit y.</t> This section provides general guidelines for what experts should focus on, bu t as they are designated experts for a reason, they should be granted flexibilit y.</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>When defining the use of CoAP-EAP Information Elements: Experts a re expected to evaluate how the values are defined, their scope, and whether the y align with CoAP-EAP's functionality and constraints. They are expected to asse ss if the values are clear, well-structured, and follow CoAP and CoAP-EAP conven tions, such as concise encoding for constrained environments. They should ensure these IEs can seamlessly integrate with existing CoAP implementations and exten sions. It is also expected that they verify if IE values are protected from unau thorized modification or misuse during transmission.</t> <t>When defining the use of CoAP-EAP Information Elements (IEs), exp erts are expected to evaluate how the values are defined, their scope, and wheth er they align with CoAP-EAP's functionality and constraints. They are expected t o assess whether the values are clear, well structured, and follow CoAP and CoAP -EAP conventions, such as concise encoding for constrained environments. They sh ould ensure that these IEs can seamlessly integrate with existing CoAP implement ations and extensions. Experts are also expected to verify that IE values are pr otected from unauthorized modification or misuse during transmission.</t>
</li> </li>
<li> <li>
<t>When adding new cipher suites: Experts must ensure that algorith m values are sourced from the appropriate registry when required. They should al so consider seeking input from relevant IETF working groups regarding the accura cy of registered parameters.</t> <t>When adding new cipher suites, experts must ensure that algorithm values are sourced from the appropriate registry when required. They should als o consider seeking input from relevant IETF working groups regarding the accurac y of registered parameters.</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-emu-eap-edhoc" to="EAP-EDHOC"/>
<references anchor="sec-combined-references"> <references anchor="sec-combined-references">
<name>References</name> <name>References</name>
<references anchor="sec-normative-references"> <references anchor="sec-normative-references">
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> 119.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<title>Key words for use in RFCs to Indicate Requirement Levels</tit 247.xml"/>
le> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<author fullname="S. Bradner" initials="S." surname="Bradner"/> 748.xml"/>
<date month="March" year="1997"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<abstract> 252.xml"/>
<t>In many standards track documents several words are used to sig <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
nify the requirements in the specification. These words are often capitalized. T 613.xml"/>
his document defines these words as they should be interpreted in IETF documents <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
. This document specifies an Internet Best Current Practices for the Internet Co 174.xml"/>
mmunity, and requests discussion and suggestions for improvements.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
</abstract> 677.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="BCP" value="14"/> 323.xml"/>
<seriesInfo name="RFC" value="2119"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<seriesInfo name="DOI" value="10.17487/RFC2119"/> 949.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<reference anchor="RFC5247" target="https://www.rfc-editor.org/info/rfc5 959.xml"/>
247" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5247.xml">
<front>
<title>Extensible Authentication Protocol (EAP) Key Management Frame
work</title>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="D. Simon" initials="D." surname="Simon"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<date month="August" year="2008"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP), defined in RFC 37
48, enables extensible network access authentication. This document specifies th
e EAP key hierarchy and provides a framework for the transport and usage of keyi
ng material and parameters generated by EAP authentication algorithms, known as
"methods". It also provides a detailed system-level security analysis, describin
g the conditions under which the key management guidelines described in RFC 4962
can be satisfied. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5247"/>
<seriesInfo name="DOI" value="10.17487/RFC5247"/>
</reference>
<reference anchor="RFC3748" target="https://www.rfc-editor.org/info/rfc3
748" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml">
<front>
<title>Extensible Authentication Protocol (EAP)</title>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<author fullname="L. Blunk" initials="L." surname="Blunk"/>
<author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht"/
>
<author fullname="J. Carlson" initials="J." surname="Carlson"/>
<author fullname="H. Levkowetz" initials="H." role="editor" surname=
"Levkowetz"/>
<date month="June" year="2004"/>
<abstract>
<t>This document defines the Extensible Authentication Protocol (E
AP), an authentication framework which supports multiple authentication methods.
EAP typically runs directly over data link layers such as Point-to-Point Protoc
ol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for dup
licate elimination and retransmission, but is reliant on lower layer ordering gu
arantees. Fragmentation is not supported within EAP itself; however, individual
EAP methods may support this. This document obsoletes RFC 2284. A summary of the
changes between this document and RFC 2284 is available in Appendix A. [STANDAR
DS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3748"/>
<seriesInfo name="DOI" value="10.17487/RFC3748"/>
</reference>
<reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7
252" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml">
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
<author fullname="K. Hartke" initials="K." surname="Hartke"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<date month="June" year="2014"/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a specialized we
b transfer protocol for use with constrained nodes and constrained (e.g., low-po
wer, lossy) networks. The nodes often have 8-bit microcontrollers with small amo
unts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wire
less Personal Area Networks (6LoWPANs) often have high packet error rates and a
typical throughput of 10s of kbit/s. The protocol is designed for machine- to-ma
chine (M2M) applications such as smart energy and building automation.</t>
<t>CoAP provides a request/response interaction model between appl
ication endpoints, supports built-in discovery of services and resources, and in
cludes key concepts of the Web such as URIs and Internet media types. CoAP is de
signed to easily interface with HTTP for integration with the Web while meeting
specialized requirements such as multicast support, very low overhead, and simpl
icity for constrained environments.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7252"/>
<seriesInfo name="DOI" value="10.17487/RFC7252"/>
</reference>
<reference anchor="RFC8613" target="https://www.rfc-editor.org/info/rfc8
613" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml">
<front>
<title>Object Security for Constrained RESTful Environments (OSCORE)
</title>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="J. Mattsson" initials="J." surname="Mattsson"/>
<author fullname="F. Palombini" initials="F." surname="Palombini"/>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<date month="July" year="2019"/>
<abstract>
<t>This document defines Object Security for Constrained RESTful E
nvironments (OSCORE), a method for application-layer protection of the Constrain
ed Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE).
OSCORE provides end-to-end protection between endpoints communicating using CoA
P or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks s
upporting a range of proxy operations, including translation between different t
ransport protocols.</t>
<t>Although an optional functionality of CoAP, OSCORE alters CoAP
options processing and IANA registration. Therefore, this document updates RFC 7
252.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8613"/>
<seriesInfo name="DOI" value="10.17487/RFC8613"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC6677" target="https://www.rfc-editor.org/info/rfc6
677" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6677.xml">
<front>
<title>Channel-Binding Support for Extensible Authentication Protoco
l (EAP) Methods</title>
<author fullname="S. Hartman" initials="S." role="editor" surname="H
artman"/>
<author fullname="T. Clancy" initials="T." surname="Clancy"/>
<author fullname="K. Hoeper" initials="K." surname="Hoeper"/>
<date month="July" year="2012"/>
<abstract>
<t>This document defines how to implement channel bindings for Ext
ensible Authentication Protocol (EAP) methods to address the "lying Network Acce
ss Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TR
ACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6677"/>
<seriesInfo name="DOI" value="10.17487/RFC6677"/>
</reference>
<reference anchor="RFC8323" target="https://www.rfc-editor.org/info/rfc8
323" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml">
<front>
<title>CoAP (Constrained Application Protocol) over TCP, TLS, and We
bSockets</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="S. Lemay" initials="S." surname="Lemay"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="K. Hartke" initials="K." surname="Hartke"/>
<author fullname="B. Silverajan" initials="B." surname="Silverajan"/
>
<author fullname="B. Raymor" initials="B." role="editor" surname="Ra
ymor"/>
<date month="February" year="2018"/>
<abstract>
<t>The Constrained Application Protocol (CoAP), although inspired
by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over
UDP includes support for reliable delivery, simple congestion control, and flow
control.</t>
<t>Some environments benefit from the availability of CoAP carried
over reliable transports such as TCP or Transport Layer Security (TLS). This do
cument outlines the changes required to use CoAP over TCP, TLS, and WebSockets t
ransports. It also formally updates RFC 7641 for use with these transports and R
FC 7959 to enable the use of larger messages over a reliable transport.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8323"/>
<seriesInfo name="DOI" value="10.17487/RFC8323"/>
</reference>
<reference anchor="RFC8949" target="https://www.rfc-editor.org/info/rfc8
949" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml">
<front>
<title>Concise Binary Object Representation (CBOR)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="P. Hoffman" initials="P." surname="Hoffman"/>
<date month="December" year="2020"/>
<abstract>
<t>The Concise Binary Object Representation (CBOR) is a data forma
t whose design goals include the possibility of extremely small code size, fairl
y small message size, and extensibility without the need for version negotiation
. These design goals make it different from earlier binary serializations such a
s ASN.1 and MessagePack.</t>
<t>This document obsoletes RFC 7049, providing editorial improveme
nts, new details, and errata fixes while keeping full compatibility with the int
erchange format of RFC 7049. It does not create a new version of the format.</t>
</abstract>
</front>
<seriesInfo name="STD" value="94"/>
<seriesInfo name="RFC" value="8949"/>
<seriesInfo name="DOI" value="10.17487/RFC8949"/>
</reference>
<reference anchor="RFC7959" target="https://www.rfc-editor.org/info/rfc7
959" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml">
<front>
<title>Block-Wise Transfers in the Constrained Application Protocol
(CoAP)</title>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="Z. Shelby" initials="Z." role="editor" surname="Sh
elby"/>
<date month="August" year="2016"/>
<abstract>
<t>The Constrained Application Protocol (CoAP) is a RESTful transf
er protocol for constrained nodes and networks. Basic CoAP messages work well fo
r small payloads from sensors and actuators; however, applications will need to
transfer larger payloads occasionally -- for instance, for firmware updates. In
contrast to HTTP, where TCP does the grunt work of segmenting and resequencing,
CoAP is based on datagram transports such as UDP or Datagram Transport Layer Sec
urity (DTLS). These transports only offer fragmentation, which is even more prob
lematic in constrained nodes and networks, limiting the maximum size of resource
representations that can practically be transferred.</t>
<t>Instead of relying on IP fragmentation, this specification exte
nds basic CoAP with a pair of "Block" options for transferring multiple blocks o
f information from a resource representation in multiple request-response pairs.
In many important cases, the Block options enable a server to be truly stateles
s: the server can handle each block transfer separately, with no need for a conn
ection setup or other server-side memory of previous block transfers. Essentiall
y, the Block options provide a minimal way to transfer larger representations in
a block-wise fashion.</t>
<t>A CoAP implementation that does not support these options gener
ally is limited in the size of the representations that can be exchanged, so the
re is an expectation that the Block options will be widely used in CoAP implemen
tations. Therefore, this specification updates RFC 7252.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7959"/>
<seriesInfo name="DOI" value="10.17487/RFC7959"/>
</reference>
</references> </references>
<references anchor="sec-informative-references"> <references anchor="sec-informative-references">
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.ietf-emu-eap-edhoc" target="https://datatracker.i
etf.org/doc/html/draft-ietf-emu-eap-edhoc-02" xml:base="https://bib.ietf.org/pub <!-- draft-ietf-emu-eap-edhoc (I-D Exists) -->
lic/rfc/bibxml3/reference.I-D.ietf-emu-eap-edhoc.xml"> <reference anchor="I-D.ietf-emu-eap-edhoc">
<front> <front>
<title>Using the Extensible Authentication Protocol (EAP) with Ephem <title>Using the Extensible Authentication Protocol (EAP) with Ephemeral D
eral Diffie-Hellman over COSE (EDHOC)</title> iffie-Hellman over COSE (EDHOC)</title>
<author fullname="Dan Garcia-Carrillo" initials="D." surname="Garcia <author initials="D." surname="Garcia-Carrillo" fullname="Dan Garcia-Carri
-Carrillo"> llo">
<organization>University of Oviedo</organization> <organization>University of Oviedo</organization>
</author> </author>
<author fullname="Rafael Marin-Lopez" initials="R." surname="Marin-L <author initials="R." surname="Marin-Lopez" fullname="Rafael Marin-Lopez">
opez"> <organization>University of Murcia</organization>
<organization>University of Murcia</organization> </author>
</author> <author initials="G." surname="Selander" fullname="Göran Selander">
<author fullname="Göran Selander" initials="G." surname="Selander"> <organization>Ericsson</organization>
<organization>Ericsson</organization> </author>
</author> <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattss
<author fullname="John Preuß Mattsson" initials="J. P." surname="Mat on">
tsson"> <organization>Ericsson</organization>
<organization>Ericsson</organization> </author>
</author> <author initials="F." surname="Lopez-Gomez" fullname="Francisco Lopez-Gome
<date day="21" month="October" year="2024"/> z">
<abstract> <organization>University of Murcia</organization>
<t>The Extensible Authentication Protocol (EAP), defined in RFC 37 </author>
48, provides a standard mechanism for support of multiple authentication methods <date month="June" day="4" year="2025" />
. This document specifies the EAP authentication method EAP- EDHOC, based on Eph </front>
emeral Diffie-Hellman Over COSE (EDHOC). EDHOC provides a lightweight authentica <seriesInfo name="Internet-Draft" value="draft-ietf-emu-eap-edhoc-04"/>
ted Diffie-Hellman key exchange with ephemeral keys, using COSE to provide secur </reference>
ity services efficiently encoded in CBOR. This document also provides guidance o
n authentication and authorization for EAP-EDHOC.</t> <xi:include
</abstract> href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<seriesInfo name="Internet-Draft" value="draft-ietf-emu-eap-edhoc-02"/ 967.xml"/>
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
</reference> 869.xml"/>
<reference anchor="RFC7967" target="https://www.rfc-editor.org/info/rfc7 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
967" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7967.xml"> 764.xml"/>
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<title>Constrained Application Protocol (CoAP) Option for No Server 191.xml"/>
Response</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<author fullname="A. Bhattacharyya" initials="A." surname="Bhattacha 433.xml"/>
ryya"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
<author fullname="S. Bandyopadhyay" initials="S." surname="Bandyopad 448.xml"/>
hyay"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
<author fullname="A. Pal" initials="A." surname="Pal"/> 696.xml"/>
<author fullname="T. Bose" initials="T." surname="Bose"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
<date month="August" year="2016"/> 833.xml"/>
<abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<t>There can be machine-to-machine (M2M) scenarios where server re 824.xml"/>
sponses to client requests are redundant. This kind of open-loop exchange (with <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
no response path from the server to the client) may be desired to minimize resou 147.xml"/>
rce consumption in constrained systems while updating many resources simultaneou <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
sly or performing high-frequency updates. CoAP already provides Non-confirmable 137.xml"/>
(NON) messages that are not acknowledged by the recipient. However, the request/ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
response semantics still require the server to respond with a status code indica 140.xml"/>
ting "the result of the attempt to understand and satisfy the request", per RFC <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
7252.</t> 176.xml"/>
<t>This specification introduces a CoAP option called 'No-Response <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
'. Using this option, the client can explicitly express to the server its disint 615.xml"/>
erest in all responses against the particular request. This option also provides <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
granular control to enable expression of disinterest to a particular response c 200.xml"/>
lass or a combination of response classes. The server MAY decide to suppress the <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
response by not transmitting it back to the client according to the value of th 190.xml"/>
e No-Response option in the request. This option may be effective for both unica <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
st and multicast requests. This document also discusses a few examples of applic 031.xml"/>
ations that benefit from this option.</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</abstract> 017.xml"/>
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
<seriesInfo name="RFC" value="7967"/> 053.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC7967"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
</reference> 186.xml"/>
<reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
869" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"> 446.xml"/>
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)< <reference anchor="EAP-Framework-IoT" target="https://ieeexplore.ieee.or
/title> g/document/9579387">
<author fullname="H. Krawczyk" initials="H." surname="Krawczyk"/>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<date month="May" year="2010"/>
<abstract>
<t>This document specifies a simple Hashed Message Authentication
Code (HMAC)-based key derivation function (HKDF), which can be used as a buildin
g block in various protocols and applications. The key derivation function (KDF)
is intended to support a wide range of applications and requirements, and is co
nservative in its use of cryptographic hash functions. This document is not an I
nternet Standards Track specification; it is published for informational purpose
s.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5869"/>
<seriesInfo name="DOI" value="10.17487/RFC5869"/>
</reference>
<reference anchor="RFC4764" target="https://www.rfc-editor.org/info/rfc4
764" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4764.xml">
<front>
<title>The EAP-PSK Protocol: A Pre-Shared Key Extensible Authenticat
ion Protocol (EAP) Method</title>
<author fullname="F. Bersani" initials="F." surname="Bersani"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<date month="January" year="2007"/>
<abstract>
<t>This document specifies EAP-PSK, an Extensible Authentication P
rotocol (EAP) method for mutual authentication and session key derivation using
a Pre-Shared Key (PSK). EAP-PSK provides a protected communication channel when
mutual authentication is successful for both parties to communicate over. This d
ocument describes the use of this channel only for protected exchange of result
indications, but future EAP-PSK extensions may use the channel for other purpose
s. EAP-PSK is designed for authentication over insecure networks such as IEEE 80
2.11. This memo defines an Experimental Protocol for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4764"/>
<seriesInfo name="DOI" value="10.17487/RFC4764"/>
</reference>
<reference anchor="RFC5191" target="https://www.rfc-editor.org/info/rfc5
191" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5191.xml">
<front>
<title>Protocol for Carrying Authentication for Network Access (PANA
)</title>
<author fullname="D. Forsberg" initials="D." surname="Forsberg"/>
<author fullname="Y. Ohba" initials="Y." role="editor" surname="Ohba
"/>
<author fullname="B. Patil" initials="B." surname="Patil"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="A. Yegin" initials="A." surname="Yegin"/>
<date month="May" year="2008"/>
<abstract>
<t>This document defines the Protocol for Carrying Authentication
for Network Access (PANA), a network-layer transport for Extensible Authenticati
on Protocol (EAP) to enable network access authentication between clients and ac
cess networks. In EAP terms, PANA is a UDP-based EAP lower layer that runs betwe
en the EAP peer and the EAP authenticator. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5191"/>
<seriesInfo name="DOI" value="10.17487/RFC5191"/>
</reference>
<reference anchor="RFC5433" target="https://www.rfc-editor.org/info/rfc5
433" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5433.xml">
<front>
<title>Extensible Authentication Protocol - Generalized Pre-Shared K
ey (EAP-GPSK) Method</title>
<author fullname="T. Clancy" initials="T." surname="Clancy"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<date month="February" year="2009"/>
<abstract>
<t>This memo defines an Extensible Authentication Protocol (EAP) m
ethod called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightwe
ight shared-key authentication protocol supporting mutual authentication and key
derivation. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5433"/>
<seriesInfo name="DOI" value="10.17487/RFC5433"/>
</reference>
<reference anchor="RFC5448" target="https://www.rfc-editor.org/info/rfc5
448" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5448.xml">
<front>
<title>Improved Extensible Authentication Protocol Method for 3rd Ge
neration Authentication and Key Agreement (EAP-AKA')</title>
<author fullname="J. Arkko" initials="J." surname="Arkko"/>
<author fullname="V. Lehtovirta" initials="V." surname="Lehtovirta"/
>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<date month="May" year="2009"/>
<abstract>
<t>This specification defines a new EAP method, EAP-AKA', which is
a small revision of the EAP-AKA (Extensible Authentication Protocol Method for
3rd Generation Authentication and Key Agreement) method. The change is a new key
derivation function that binds the keys derived within the method to the name o
f the access network. The new key derivation mechanism has been defined in the 3
rd Generation Partnership Project (3GPP). This specification allows its use in E
AP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of
SHA-1.</t>
<t>This specification also updates RFC 4187, EAP-AKA, to prevent b
idding down attacks from EAP-AKA'. This memo provides information for the Intern
et community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5448"/>
<seriesInfo name="DOI" value="10.17487/RFC5448"/>
</reference>
<reference anchor="RFC6696" target="https://www.rfc-editor.org/info/rfc6
696" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6696.xml">
<front>
<title>EAP Extensions for the EAP Re-authentication Protocol (ERP)</
title>
<author fullname="Z. Cao" initials="Z." surname="Cao"/>
<author fullname="B. He" initials="B." surname="He"/>
<author fullname="Y. Shi" initials="Y." surname="Shi"/>
<author fullname="Q. Wu" initials="Q." role="editor" surname="Wu"/>
<author fullname="G. Zorn" initials="G." role="editor" surname="Zorn
"/>
<date month="July" year="2012"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP) is a generic frame
work supporting multiple types of authentication methods. In systems where EAP i
s used for authentication, it is desirable to avoid repeating the entire EAP exc
hange with another authenticator. This document specifies extensions to EAP and
the EAP keying hierarchy to support an EAP method-independent protocol for effic
ient re- authentication between the peer and an EAP re-authentication server thr
ough any authenticator. The re-authentication server may be in the home network
or in the local network to which the peer is connecting. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6696"/>
<seriesInfo name="DOI" value="10.17487/RFC6696"/>
</reference>
<reference anchor="RFC7833" target="https://www.rfc-editor.org/info/rfc7
833" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7833.xml">
<front>
<title>A RADIUS Attribute, Binding, Profiles, Name Identifier Format
, and Confirmation Methods for the Security Assertion Markup Language (SAML)</ti
tle>
<author fullname="J. Howlett" initials="J." surname="Howlett"/>
<author fullname="S. Hartman" initials="S." surname="Hartman"/>
<author fullname="A. Perez-Mendez" initials="A." role="editor" surna
me="Perez-Mendez"/>
<date month="May" year="2016"/>
<abstract>
<t>This document describes the use of the Security Assertion Marku
p Language (SAML) with RADIUS in the context of the Application Bridging for Fed
erated Access Beyond web (ABFAB) architecture. It defines two RADIUS attributes,
a SAML binding, a SAML name identifier format, two SAML profiles, and two SAML
confirmation methods. The RADIUS attributes permit encapsulation of SAML Asserti
ons and protocol messages within RADIUS, allowing SAML entities to communicate u
sing the binding. The two profiles describe the application of this binding for
ABFAB authentication and assertion Query/Request, enabling a Relying Party to re
quest authentication of, or assertions for, users or machines (clients). These c
lients may be named using a Network Access Identifier (NAI) name identifier form
at. Finally, the subject confirmation methods allow requests and queries to be i
ssued for a previously authenticated user or machine without needing to explicit
ly identify them as the subject. The use of the artifacts defined in this docume
nt is not exclusive to ABFAB. They can be applied in any Authentication, Authori
zation, and Accounting (AAA) scenario, such as network access control.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7833"/>
<seriesInfo name="DOI" value="10.17487/RFC7833"/>
</reference>
<reference anchor="RFC8824" target="https://www.rfc-editor.org/info/rfc8
824" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8824.xml">
<front>
<title>Static Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)</title>
<author fullname="A. Minaburo" initials="A." surname="Minaburo"/>
<author fullname="L. Toutain" initials="L." surname="Toutain"/>
<author fullname="R. Andreasen" initials="R." surname="Andreasen"/>
<date month="June" year="2021"/>
<abstract>
<t>This document defines how to compress Constrained Application P
rotocol (CoAP) headers using the Static Context Header Compression and fragmenta
tion (SCHC) framework. SCHC defines a header compression mechanism adapted for C
onstrained Devices. SCHC uses a static description of the header to reduce the h
eader's redundancy and size. While RFC 8724 describes the SCHC compression and f
ragmentation framework, and its application for IPv6/UDP headers, this document
applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UD
P, since CoAP uses a flexible header with a variable number of options, themselv
es of variable length. The CoAP message format is asymmetric: the request messag
es have a header format different from the format in the response messages. This
specification gives guidance on applying SCHC to flexible headers and how to le
verage the asymmetry for more efficient compression Rules.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8824"/>
<seriesInfo name="DOI" value="10.17487/RFC8824"/>
</reference>
<reference anchor="RFC9147" target="https://www.rfc-editor.org/info/rfc9
147" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml">
<front>
<title>The Datagram Transport Layer Security (DTLS) Protocol Version
1.3</title>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<author fullname="N. Modadugu" initials="N." surname="Modadugu"/>
<date month="April" year="2022"/>
<abstract>
<t>This document specifies version 1.3 of the Datagram Transport L
ayer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to com
municate over the Internet in a way that is designed to prevent eavesdropping, t
ampering, and message forgery.</t>
<t>The DTLS 1.3 protocol is based on the Transport Layer Security
(TLS) 1.3 protocol and provides equivalent security guarantees with the exceptio
n of order protection / non-replayability. Datagram semantics of the underlying
transport are preserved by the DTLS protocol.</t>
<t>This document obsoletes RFC 6347.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9147"/>
<seriesInfo name="DOI" value="10.17487/RFC9147"/>
</reference>
<reference anchor="RFC4137" target="https://www.rfc-editor.org/info/rfc4
137" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4137.xml">
<front>
<title>State Machines for Extensible Authentication Protocol (EAP) P
eer and Authenticator</title>
<author fullname="J. Vollbrecht" initials="J." surname="Vollbrecht"/
>
<author fullname="P. Eronen" initials="P." surname="Eronen"/>
<author fullname="N. Petroni" initials="N." surname="Petroni"/>
<author fullname="Y. Ohba" initials="Y." surname="Ohba"/>
<date month="August" year="2005"/>
<abstract>
<t>This document describes a set of state machines for Extensible
Authentication Protocol (EAP) peer, EAP stand-alone authenticator (non-pass-thro
ugh), EAP backend authenticator (for use on Authentication, Authorization, and A
ccounting (AAA) servers), and EAP full authenticator (for both local and pass-th
rough). This set of state machines shows how EAP can be implemented to support d
eployment in either a peer/authenticator or peer/authenticator/AAA Server enviro
nment. The peer and stand-alone authenticator machines are illustrative of how t
he EAP protocol defined in RFC 3748 may be implemented. The backend and full/pas
s-through authenticators illustrate how EAP/AAA protocol support defined in RFC
3579 may be implemented. Where there are differences, RFC 3748 and RFC 3579 are
authoritative.</t>
<t>The state machines are based on the EAP "Switch" model. This mo
del includes events and actions for the interaction between the EAP Switch and E
AP methods. A brief description of the EAP "Switch" model is given in the Introd
uction section.</t>
<t>The state machine and associated model are informative only. Im
plementations may achieve the same results using different methods. This memo pr
ovides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4137"/>
<seriesInfo name="DOI" value="10.17487/RFC4137"/>
</reference>
<reference anchor="RFC9140" target="https://www.rfc-editor.org/info/rfc9
140" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9140.xml">
<front>
<title>Nimble Out-of-Band Authentication for EAP (EAP-NOOB)</title>
<author fullname="T. Aura" initials="T." surname="Aura"/>
<author fullname="M. Sethi" initials="M." surname="Sethi"/>
<author fullname="A. Peltonen" initials="A." surname="Peltonen"/>
<date month="December" year="2021"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP) provides support f
or multiple authentication methods. This document defines the EAP-NOOB authentic
ation method for nimble out-of-band (OOB) authentication and key derivation. The
EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT)
devices that have no preconfigured authentication credentials. The method makes
use of a user-assisted, one-directional, out-of-band (OOB) message between the p
eer device and authentication server to authenticate the in-band key exchange. T
he device must have a nonnetwork input or output interface, such as a display, m
icrophone, speaker, or blinking light, that can send or receive dynamically gene
rated messages of tens of bytes in length.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9140"/>
<seriesInfo name="DOI" value="10.17487/RFC9140"/>
</reference>
<reference anchor="RFC9176" target="https://www.rfc-editor.org/info/rfc9
176" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9176.xml">
<front>
<title>Constrained RESTful Environments (CoRE) Resource Directory</t
itle>
<author fullname="C. Amsüss" initials="C." role="editor" surname="Am
süss"/>
<author fullname="Z. Shelby" initials="Z." surname="Shelby"/>
<author fullname="M. Koster" initials="M." surname="Koster"/>
<author fullname="C. Bormann" initials="C." surname="Bormann"/>
<author fullname="P. van der Stok" initials="P." surname="van der St
ok"/>
<date month="April" year="2022"/>
<abstract>
<t>In many Internet of Things (IoT) applications, direct discovery
of resources is not practical due to sleeping nodes or networks where multicast
traffic is inefficient. These problems can be solved by employing an entity cal
led a Resource Directory (RD), which contains information about resources held o
n other servers, allowing lookups to be performed for those resources. The input
to an RD is composed of links, and the output is composed of links constructed
from the information stored in the RD. This document specifies the web interface
s that an RD supports for web servers to discover the RD and to register, mainta
in, look up, and remove information on resources. Furthermore, new target attrib
utes useful in conjunction with an RD are defined.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9176"/>
<seriesInfo name="DOI" value="10.17487/RFC9176"/>
</reference>
<reference anchor="RFC8615" target="https://www.rfc-editor.org/info/rfc8
615" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml">
<front>
<title>Well-Known Uniform Resource Identifiers (URIs)</title>
<author fullname="M. Nottingham" initials="M." surname="Nottingham"/
>
<date month="May" year="2019"/>
<abstract>
<t>This memo defines a path prefix for "well-known locations", "/.
well-known/", in selected Uniform Resource Identifier (URI) schemes.</t>
<t>In doing so, it obsoletes RFC 5785 and updates the URI schemes
defined in RFC 7230 to reserve that space. It also updates RFC 7595 to track URI
schemes that support well-known URIs in their registry.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8615"/>
<seriesInfo name="DOI" value="10.17487/RFC8615"/>
</reference>
<reference anchor="RFC9200" target="https://www.rfc-editor.org/info/rfc9
200" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9200.xml">
<front>
<title>Authentication and Authorization for Constrained Environments
Using the OAuth 2.0 Framework (ACE-OAuth)</title>
<author fullname="L. Seitz" initials="L." surname="Seitz"/>
<author fullname="G. Selander" initials="G." surname="Selander"/>
<author fullname="E. Wahlstroem" initials="E." surname="Wahlstroem"/
>
<author fullname="S. Erdtman" initials="S." surname="Erdtman"/>
<author fullname="H. Tschofenig" initials="H." surname="Tschofenig"/
>
<date month="August" year="2022"/>
<abstract>
<t>This specification defines a framework for authentication and a
uthorization in Internet of Things (IoT) environments called ACE-OAuth. The fram
ework is based on a set of building blocks including OAuth 2.0 and the Constrain
ed Application Protocol (CoAP), thus transforming a well-known and widely used a
uthorization solution into a form suitable for IoT devices. Existing specificati
ons are used where possible, but extensions are added and profiles are defined t
o better serve the IoT use cases.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9200"/>
<seriesInfo name="DOI" value="10.17487/RFC9200"/>
</reference>
<reference anchor="RFC9190" target="https://www.rfc-editor.org/info/rfc9
190" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9190.xml">
<front>
<title>EAP-TLS 1.3: Using the Extensible Authentication Protocol wit
h TLS 1.3</title>
<author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Ma
ttsson"/>
<author fullname="M. Sethi" initials="M." surname="Sethi"/>
<date month="February" year="2022"/>
<abstract>
<t>The Extensible Authentication Protocol (EAP), defined in RFC 37
48, provides a standard mechanism for support of multiple authentication methods
. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwa
rds compatible with existing implementations of EAP-TLS. TLS 1.3 provides signif
icantly improved security and privacy, and reduced latency when compared to earl
ier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves securit
y and privacy by always providing forward secrecy, never disclosing the peer ide
ntity, and by mandating use of revocation checking when compared to EAP-TLS with
earlier versions of TLS. This document also provides guidance on authentication
, authorization, and resumption for EAP-TLS in general (regardless of the underl
ying TLS version used). This document updates RFC 5216.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9190"/>
<seriesInfo name="DOI" value="10.17487/RFC9190"/>
</reference>
<reference anchor="RFC9031" target="https://www.rfc-editor.org/info/rfc9
031" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9031.xml">
<front>
<title>Constrained Join Protocol (CoJP) for 6TiSCH</title>
<author fullname="M. Vučinić" initials="M." role="editor" surname="V
učinić"/>
<author fullname="J. Simon" initials="J." surname="Simon"/>
<author fullname="K. Pister" initials="K." surname="Pister"/>
<author fullname="M. Richardson" initials="M." surname="Richardson"/
>
<date month="May" year="2021"/>
<abstract>
<t>This document describes the minimal framework required for a ne
w device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slott
ed Channel Hopping mode of IEEE 802.15.4) network. The framework requires that t
he pledge and the JRC (Join Registrar/Coordinator, a central entity), share a sy
mmetric key. How this key is provisioned is out of scope of this document. Throu
gh a single CoAP (Constrained Application Protocol) request-response exchange se
cured by OSCORE (Object Security for Constrained RESTful Environments), the pled
ge requests admission into the network, and the JRC configures it with link-laye
r keying material and other parameters. The JRC may at any time update the param
eters through another request-response exchange secured by OSCORE. This specific
ation defines the Constrained Join Protocol and its CBOR (Concise Binary Object
Representation) data structures, and it describes how to configure the rest of t
he 6TiSCH communication stack for this join process to occur in a secure manner.
Additional security mechanisms may be added on top of this minimal framework.</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="9031"/>
<seriesInfo name="DOI" value="10.17487/RFC9031"/>
</reference>
<reference anchor="RFC4017" target="https://www.rfc-editor.org/info/rfc4
017" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4017.xml">
<front>
<title>Extensible Authentication Protocol (EAP) Method Requirements
for Wireless LANs</title>
<author fullname="D. Stanley" initials="D." surname="Stanley"/>
<author fullname="J. Walker" initials="J." surname="Walker"/>
<author fullname="B. Aboba" initials="B." surname="Aboba"/>
<date month="March" year="2005"/>
<abstract>
<t>The IEEE 802.11i MAC Security Enhancements Amendment makes use
of IEEE 802.1X, which in turn relies on the Extensible Authentication Protocol (
EAP). This document defines requirements for EAP methods used in IEEE 802.11 wir
eless LAN deployments. The material in this document has been approved by IEEE 8
02.11 and is being presented as an IETF RFC for informational purposes. This mem
o provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4017"/>
<seriesInfo name="DOI" value="10.17487/RFC4017"/>
</reference>
<reference anchor="RFC9053" target="https://www.rfc-editor.org/info/rfc9
053" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9053.xml">
<front>
<title>CBOR Object Signing and Encryption (COSE): Initial Algorithms
</title>
<author fullname="J. Schaad" initials="J." surname="Schaad"/>
<date month="August" year="2022"/>
<abstract>
<t>Concise Binary Object Representation (CBOR) is a data format de
signed for small code size and small message size. There is a need to be able to
define basic security services for this data format. This document defines a se
t of algorithms that can be used with the CBOR Object Signing and Encryption (CO
SE) protocol (RFC 9052).</t>
<t>This document, along with RFC 9052, obsoletes RFC 8152.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="9053"/>
<seriesInfo name="DOI" value="10.17487/RFC9053"/>
</reference>
<reference anchor="RFC4186" target="https://www.rfc-editor.org/info/rfc4
186" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4186.xml">
<front>
<title>Extensible Authentication Protocol Method for Global System f
or Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)</title>
<author fullname="H. Haverinen" initials="H." role="editor" surname=
"Haverinen"/>
<author fullname="J. Salowey" initials="J." role="editor" surname="S
alowey"/>
<date month="January" year="2006"/>
<abstract>
<t>This document specifies an Extensible Authentication Protocol (
EAP) mechanism for authentication and session key distribution using the Global
System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is
a second generation mobile network standard. The EAP-SIM mechanism specifies enh
ancements to GSM authentication and key agreement whereby multiple authenticatio
n triplets can be combined to create authentication responses and session keys o
f greater strength than the individual GSM triplets. The mechanism also includes
network authentication, user anonymity support, result indications, and a fast
re-authentication procedure. This memo provides information for the Internet com
munity.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4186"/>
<seriesInfo name="DOI" value="10.17487/RFC4186"/>
</reference>
<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
446" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
<date month="August" year="2018"/>
<abstract>
<t>This document specifies version 1.3 of the Transport Layer Secu
rity (TLS) protocol. TLS allows client/server applications to communicate over t
he Internet in a way that is designed to prevent eavesdropping, tampering, and m
essage forgery.</t>
<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
77, 5246, and 6961. This document also specifies new requirements for TLS 1.2 im
plementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
</reference>
<reference anchor="EAP-framework-IoT" target="https://ieeexplore.ieee.or
g/document/9579387">
<front> <front>
<title>Secure Network Access Authentication for IoT Devices: EAP Fra mework vs. Individual Protocols</title> <title>Secure Network Access Authentication for IoT Devices: EAP Fra mework vs. Individual Protocols</title>
<author initials="M." surname="Sethi" fullname="Ericsson"> <author initials="M." surname="Sethi" fullname="Mohit Sethi">
<organization/>
</author>
<author initials="T." surname="Aura" fullname="Tuomas Aura">
<organization/> <organization/>
</author> </author>
<date year="2021"/> <date year="2021"/>
</front> </front>
<seriesInfo name="DOI" value="10.1109/MCOMSTD.201.2000088"/>
<refcontent>IEEE Communications Standards Magazine, vol. 5, no. 3, pp.
34-39</refcontent>
</reference> </reference>
<reference anchor="lo-coap-eap" target="https://www.mdpi.com/1424-8220/1
7/11/2646"> <reference anchor="LO-CoAP-EAP" target="https://www.mdpi.com/1424-8220/1
7/11/2646">
<front> <front>
<title>A CoAP-Based Network Access Authentication Service for Low-Po wer Wide Area Networks: LO-CoAP-EAP</title> <title>A CoAP-Based Network Access Authentication Service for Low-Po wer Wide Area Networks: LO-CoAP-EAP</title>
<author initials="D." surname="Garcia-Carrillo" fullname="Dan Garcia -Carrillo"> <author initials="D." surname="Garcia-Carrillo" fullname="Dan Garcia -Carrillo">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Marin-Lopez" fullname="Rafael Marin-L opez"> <author initials="R." surname="Marin-Lopez" fullname="Rafael Marin-L opez">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Kandasamy" fullname="Arunprabhu Kanda samy"> <author initials="A." surname="Kandasamy" fullname="Arunprabhu Kanda samy">
<organization/> <organization/>
</author> </author>
<author initials="A." surname="Pelov" fullname="Alexander Pelov"> <author initials="A." surname="Pelov" fullname="Alexander Pelov">
<organization/> <organization/>
</author> </author>
<date year="2017"/> <date year="2017"/>
</front> </front>
<seriesInfo name="DOI" value="10.3390/s17112646"/>
<refcontent>Sensors, vol. 17, no. 11</refcontent>
</reference> </reference>
<reference anchor="coap-eap" target="https://www.mdpi.com/1424-8220/16/3
/358"> <reference anchor="CoAP-EAP" target="https://www.mdpi.com/1424-8220/16/3
/358">
<front> <front>
<title>Lightweight CoAP-Based Bootstrapping Service for the Internet of Things</title> <title>Lightweight CoAP-Based Bootstrapping Service for the Internet of Things</title>
<author initials="D." surname="Garcia-Carrillo" fullname="Dan Garcia -Carrillo"> <author initials="D." surname="Garcia-Carrillo" fullname="Dan Garcia -Carrillo">
<organization/> <organization/>
</author> </author>
<author initials="R." surname="Marin-Lopez" fullname="Rafael Marin-L opez"> <author initials="R." surname="Marin-Lopez" fullname="Rafael Marin-L opez">
<organization/> <organization/>
</author> </author>
<date year="2016"/> <date year="2016"/>
</front> </front>
<seriesInfo name="DOI" value="10.3390/s16030358"/>
<refcontent>Sensors, vol. 16, no. 3</refcontent>
</reference> </reference>
<reference anchor="TS133.501" target=""> <reference anchor="TS133.501" target="">
<front> <front>
<title>5G; Security architecture and procedures for 5G System - TS 1 <title>5G; Security architecture and procedures for 5G System</title
33 501 V15.2.0 (2018-10)</title> >
<author initials="" surname="ETSI" fullname="ETSI"> <author>
<organization/> <organization>ETSI</organization>
</author> </author>
<date year="2018"/> <date year="2018"/>
</front> </front>
<seriesInfo name="ETSI TS" value="133 501"/>
<refcontent>V15.2.0</refcontent>
</reference> </reference>
<!-- [rfced] [TS133.501]: We found a more recent version of this
specification. Because it appears that EAP will continue to be
mentioned in subsequent versions of this paper, may we update this
listing as follows?
Original:
[TS133.501]
ETSI, "5G; Security architecture and procedures for 5G
System - TS 133 501 V15.2.0 (2018-10)", 2018.
Suggested:
[TS133.501]
ETSI, "5G; Security architecture and procedures for 5G
System - TS 133 501 V18.9.0", April 2025,
https://www.etsi.org/deliver/etsi_ts/133500_133599/
133501/18.09.00_60/ts_133501v180900p.pdf -->
<reference anchor="ZigbeeIP" target=""> <reference anchor="ZigbeeIP" target="">
<front> <front>
<title>ZigBee IP Specification (Zigbee Document 095023r34)</title> <title>Zigbee IP Specification (Zigbee Document 095023r34)</title>
<author initials="" surname="Zigbee Alliance" fullname="Zigbee Allia <author>
nce"> <organization>Zigbee Alliance</organization>
<organization/>
</author> </author>
<date year="2014"/> <date year="2014"/>
</front> </front>
</reference> </reference>
<reference anchor="ieee802159" target="">
<!-- [rfced] [ZigbeeIP]: We could not find this document number.
We also found that <https://www.zigbee.org/> steers to
<https://csa-iot.org/>. When we searched <https://csa-iot.org/> for
the number 095023r34, the result was "Nothing found, please try
adjusting your search."
Should a different paper be listed here and cited in Appendices B and
C.5.1?
Original:
[ZigbeeIP] Zigbee Alliance, "ZigBee IP Specification (Zigbee Document
095023r34)", 2014. -->
<reference anchor="IEEE802159" target="">
<front> <front>
<title>IEEE Standard for Transport of Key Management Protocol (KMP) Datagrams</title> <title>IEEE Standard for Transport of Key Management Protocol (KMP) Datagrams</title>
<author initials="" surname="IEEE" fullname="IEEE"> <author>
<organization/> <organization>IEEE</organization>
</author> </author>
<date year="2021"/> <date month="January" year="2022"/>
</front> </front>
<seriesInfo name="IEEE Std" value="802.15.9-2021"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9690134"/>
</reference> </reference>
<reference anchor="THREAD" target=""> <reference anchor="THREAD" target="">
<front> <front>
<title>Thread specification 1.3</title> <title>Thread Specification 1.3</title>
<author initials="" surname="Thread Group" fullname="Thread Group"> <author>
<organization/> <organization>Thread Group</organization>
</author> </author>
<date year="2023"/> <date year="2023"/>
</front> </front>
</reference> </reference>
<!-- [rfced] We found a newer version (1.4.0) of the Thread
specification. As the citation in Appendix B is general in nature,
may we update this listing as suggested below?
Original:
[THREAD] Thread Group, "Thread specification 1.3", 2023.
Suggested:
[THREAD] Kumar, S. and E. Dijk, "Thread 1.4 Features White Paper",
September 2024, <https://www.threadgroup.org/Portals/0/
Documents/
Thread_1.4_Features_White_Paper_September_2024.pdf>. -->
</references> </references>
</references> </references>
<?line 789?>
<section anchor="flow-of-operation-dtls"> <section anchor="flow-of-operation-dtls">
<name>Flow of operation (DTLS establishment)</name> <name>Flow of Operation (DTLS Establishment)</name>
<t>CoAP-EAP makes it possible to derive a PSK from the MSK to allow (D)TLS <t>CoAP-EAP makes it possible to derive a Pre-Shared Key (PSK) from the MS
PSK-based authentication between the EAP peer and the EAP authenticator instead K to allow (D)TLS PSK-based authentication between the EAP peer and the EAP auth
of using OSCORE. In the case of using (D)TLS to establish a security associatio enticator instead of using OSCORE. In the case of using (D)TLS to establish a se
n, there is a limitation on the use of intermediaries between the EAP peer and t curity association, there is a limitation on the use of intermediaries between t
he EAP authenticator, as (D)TLS breaks the end-to-end communications when using he EAP peer and the EAP authenticator, as (D)TLS breaks the end-to-end communica
intermediaries such as proxies.</t> tions when using intermediaries such as proxies.</t>
<t><xref target="fig-dtls"/> shows the last steps of the flow of operation
for CoAP-EAP when (D)TLS is used to protect the communication between the EAP p
eer and the EAP authenticator using the keying material exported by the EAP auth
entication. The general flow is essentially the same as in the case of OSCORE, e
xcept that DTLS negotiation is established in Step 7. Once DTLS negotiation has
finished successfully, the EAP peer is granted access to the domain. Step 7 <bcp
14>MUST</bcp14> be interpreted by the EAP peer as an alternate success indicatio
n, which will end up with the MSK and the DTLS_PSK derivation for the (D)TLS aut
hentication based on the PSK.</t>
<figure anchor="fig-dtls"> <figure anchor="fig-dtls">
<name>CoAP-EAP flow of operation with DTLS</name> <name>CoAP-EAP Flow of Operation with DTLS</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="272" width="504" viewBox="0 0 504 272" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/ svg" version="1.1" height="272" width="504" viewBox="0 0 504 272" class="diagram " text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap=" round">
<path d="M 88,80 L 88,208" fill="none" stroke="black"/> <path d="M 88,80 L 88,208" fill="none" stroke="black"/>
<path d="M 424,80 L 424,208" fill="none" stroke="black"/> <path d="M 424,80 L 424,208" fill="none" stroke="black"/>
<path d="M 16,48 L 112,48" fill="none" stroke="black"/> <path d="M 16,48 L 112,48" fill="none" stroke="black"/>
<path d="M 336,48 L 432,48" fill="none" stroke="black"/> <path d="M 336,48 L 432,48" fill="none" stroke="black"/>
<path d="M 96,112 L 416,112" fill="none" stroke="black"/> <path d="M 96,112 L 416,112" fill="none" stroke="black"/>
<path d="M 96,160 L 416,160" fill="none" stroke="black"/> <path d="M 96,160 L 416,160" fill="none" stroke="black"/>
<path d="M 96,190 L 208,190" fill="none" stroke="black"/> <path d="M 96,190 L 208,190" fill="none" stroke="black"/>
<path d="M 96,194 L 208,194" fill="none" stroke="black"/> <path d="M 96,194 L 208,194" fill="none" stroke="black"/>
skipping to change at line 1734 skipping to change at line 2061
<text x="172" y="148">(D)TLS</text> <text x="172" y="148">(D)TLS</text>
<text x="216" y="148">1.3</text> <text x="216" y="148">1.3</text>
<text x="260" y="148">Client</text> <text x="260" y="148">Client</text>
<text x="312" y="148">Hello</text> <text x="312" y="148">Hello</text>
<text x="448" y="148">|</text> <text x="448" y="148">|</text>
<text x="32" y="164">MSK</text> <text x="32" y="164">MSK</text>
<text x="68" y="164">7)</text> <text x="68" y="164">7)</text>
<text x="32" y="180">|</text> <text x="32" y="180">|</text>
<text x="468" y="180">DTLS_PSK</text> <text x="468" y="180">DTLS_PSK</text>
<text x="228" y="196">DTLS</text> <text x="228" y="196">DTLS</text>
<text x="284" y="196">hanshake</text> <text x="284" y="196">handshake</text>
<text x="36" y="212">DTLS_PSK</text> <text x="36" y="212">DTLS_PSK</text>
<text x="208" y="228">Protected</text> <text x="208" y="228">Protected</text>
<text x="268" y="228">with</text> <text x="268" y="228">with</text>
<text x="316" y="228">(D)TLS</text> <text x="316" y="228">(D)TLS</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
EAP peer EAP authenticator EAP peer EAP authenticator
------------- ------------- ------------- -------------
... ...
| 2.01 Created Location-Path [/a/eap/(n)] | | 2.01 Created Location-Path [/a/eap/(n)] |
| Payload (EAP-X Resp) | | Payload (EAP-X Resp) |
6) |---------------------------------------->| 6) |---------------------------------------->|
| | MSK | | MSK
| (D)TLS 1.3 Client Hello | | | (D)TLS 1.3 Client Hello | |
MSK 7) |<----------------------------------------| V MSK 7) |<----------------------------------------| V
| | | DTLS_PSK | | | DTLS_PSK
V |===============DTLS hanshake=============| V |===============DTLS handshake============|
DTLS_PSK | | DTLS_PSK | |
<-(Protected with (D)TLS)-> <-(Protected with (D)TLS)->
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t><xref target="fig-dtls"/> shows the last steps of the operation for CoA
P-EAP when (D)TLS is used to protect the communication between the EAP peer and <!-- [rfced] Figure 9:
the EAP authenticator using the keying material exported by the EAP authenticati
on. The general flow is essentially the same as in the case of OSCORE, except th a) Please note that we changed "hanshake" to "handshake". However,
at DTLS negotiation is established in Step 7). Once DTLS negotiation has finishe in the HTML and PDF output files, the space after the "e" in
d successfully, the EAP peer is granted access to the domain. Step 7 <bcp14>MUST "hanshake" was removed in the process. We cannot determine where in
</bcp14> be interpreted by the EAP peer as an alternate success indication, whic the SVG a coordinate should be modified to correct the spacing.
h will end up with the MSK and the DTLS_PSK derivation for the (D)TLS authentica Please correct the SVG in the edited copy of the XML.
tion based on PSK.</t>
<t>According to <xref target="RFC8446"/> the provision of the PSK out-of-b b) We see "down" arrows between MSK and DTLS_PSK in the ASCII art
and also requires the provision of the KDF hash algorithm and the PSK identity. for this figure, but they do not appear in the SVG. If you would
To simplify the design in CoAP-EAP, the KDF hash algorithm can be included in th like to add the arrows in the SVG, please correct the SVG in the
e list of cipher suites exchanged in Step 1 and Step 2 if DTLS wants to be used edited copy of the XML.
instead of OSCORE. For the same reason, the PSK identity is derived from (RID-C)
(RID-I) as defined in <xref target="dtls-psk"/>.</t> c) We see "(Protected with (D)TLS)" in the ASCII art but
<t>Analogous to how the cipher suite is negotiated for OSCORE <xref target "Protected with (D)TLS" in the SVG. If you prefer the parentheses,
="crypto-negotiation"/>, the EAP authenticator sends a list, in decreasing order please correct the SVG in the edited copy of the XML. If you prefer
of preference, with the identifiers of the hash algorithms supported (Step 1). that the parentheses be removed, let us know, and we will update the
In the response, the EAP peer sends the choice.</t> ASCII art accordingly. -->
<t>This list is included in the payload after the EAP message with a CBOR
array that contains the cipher suites. This CBOR array is enclosed as one of the <t>According to <xref target="RFC8446"/>, the provision of the PSK out of
elements of the CBOR Object used for transporting information in CoAP-EAP (See band also requires the provision of the KDF hash algorithm and the PSK identity.
<xref target="cbor-coap-eap"/>). An example of how the fields are arranged in To simplify the design in CoAP-EAP, the KDF hash algorithm can be included in t
the CoAP payload can be seen in <xref target="figure5"/>.</t> he list of cipher suites exchanged in Steps 1 and 2 if DTLS wants to be used ins
<t>In case there is no CBOR array stating the cipher suites, the default c tead of OSCORE. For the same reason, the PSK identity is derived from (RID-C) (R
ipher suites are applied. If the EAP authenticator sends a restricted list of ci ID-I) as defined in <xref target="dtls-psk"/>.
pher suites that is willing to accept, it <bcp14>MUST</bcp14> include the defaul
t value 0 since it is mandatory to implement. The EAP peer will have at least th <!-- [rfced] Appendix A:
at option available.</t>
<t>For DTLS, the negotiated cipher suite is used to determine the hash fun a) As it appears that "Steps 1 and 2" here refer to Steps 1 and 2 in
ction to be used to derive the "DTLS PSK" from the MSK:</t> Figure 8 (as opposed to Steps 1 and 2 in Figure 3), may we add a
<t>The hash algorithms considered are the following:</t> citation for Figure 8 for ease of the reader?
If the suggested text is not correct, please also clarify "if DTLS
wants to be used".
Original:
To simplify the design in CoAP-EAP, the KDF hash algorithm
can be included in the list of cipher suites exchanged in Step 1 and
Step 2 if DTLS wants to be used instead of OSCORE.
Suggested:
To simplify the design in CoAP-EAP, the KDF hash algorithm
can be included in the list of cipher suites exchanged in Steps 1 and
2 (Figure 8) if one wants to use DTLS instead of OSCORE.
b) Should "(RID-C) (RID-I)" be "RID-C || RID-I" per Appendix A.1?
Original:
For the same
reason, the PSK identity is derived from (RID-C) (RID-I) as defined
in Appendix A.1. -->
</t>
<t>Analogous to how the cipher suite is negotiated for OSCORE (<xref targe
t="crypto-negotiation"/>), the EAP authenticator sends a list, in decreasing ord
er of preference, with the identifiers of the hash algorithms supported (Step 1)
. In the response, the EAP peer sends its choice.</t>
<t>This list is included in the payload after the EAP message with a CBOR
array that contains the cipher suites. This CBOR array is enclosed as one of the
elements of the CBOR Object used for transporting information in CoAP-EAP (see
<xref target="cbor-coap-eap"/>). An example of how the fields are arranged in
the CoAP payload can be seen in <xref target="figure7"/>.</t>
<t>If there is no CBOR array specifying the cipher suites, the default cip
her suites are applied. If the EAP authenticator sends a restricted list of ciph
er suites that can be accepted, it <bcp14>MUST</bcp14> include the default value
0, since it is mandatory to implement. The EAP peer will have at least that opt
ion available.</t>
<t>For DTLS, the negotiated cipher suite is used to determine the hash fun
ction to be used to derive the "DTLS PSK" from the MSK. The following hash algor
ithms are considered:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>5) TLS_SHA256</t> <t>5) TLS_SHA256</t>
</li> </li>
<li> <li>
<t>6) TLS_SHA384</t> <t>6) TLS_SHA384</t>
</li> </li>
<li> <li>
<t>7) TLS_SHA512</t> <t>7) TLS_SHA512</t>
</li> </li>
</ul> </ul>
<t>The inclusion of these values, apart from indicating the hash algorithm
, indicates if the EAP authenticator intends to establish an OSCORE security ass <!-- [rfced] Appendix A: Should "considered" be "supported" in this
ociation or a DTLS security association after the authentication is completed. I sentence, along the lines of "The other supported and negotiated
f both options appear in the cipher suite negotiation, the OSCORE security assoc cipher suites are the following" as seen in Section 6.1?
iation will be preferred over DTLS.</t>
Original:
The hash algorithms considered are the following:
* 5) TLS_SHA256
* 6) TLS_SHA384
* 7) TLS_SHA512
Possibly:
The following hash algorithms are supported:
* 5) TLS_SHA256
* 6) TLS_SHA384
* 7) TLS_SHA512 -->
<t>The inclusion of these values, apart from indicating the hash algorithm
, indicates that the EAP authenticator intends to establish an OSCORE security a
ssociation or a DTLS security association after the authentication is completed.
If both options appear in the cipher suite negotiation, the OSCORE security ass
ociation will be preferred over DTLS.</t>
<section anchor="dtls-psk"> <section anchor="dtls-psk">
<name>Deriving DTLS PSK and identity</name> <name>Deriving DTLS PSK and Identity</name>
<t>To enable DTLS after an EAP authentication, the Identity and the PSK <t>To enable DTLS after an EAP authentication, Identity and the PSK for
for DTLS is defined. The Identity in this case is generated by concatenating the DTLS are defined. Identity in this case is generated by concatenating the exchan
exchanged Sender ID and the Recipient ID.</t> ged Sender ID and the Recipient ID.</t>
<artwork><![CDATA[ <artwork><![CDATA[
CoAP-EAP PSK Identity = RID-C || RID-I CoAP-EAP PSK Identity = RID-C || RID-I
]]></artwork> ]]></artwork>
<t>It is also possible to derive a pre-shared key for DTLS <xref target= "RFC9147"/>, referred to here as "DTLS PSK", from the MSK between both the EAP p eer and EAP authenticator if required. The length of the DTLS PSK will depend on the cipher suite. To have keying material with sufficient length, a key of 32 b ytes is derived that can be later truncated if needed:</t> <t>It is also possible to derive a PSK for DTLS <xref target="RFC9147"/> , referred to here as "DTLS PSK", from the MSK between both the EAP peer and EAP authenticator if required. The length of the DTLS PSK will depend on the cipher suite. To have keying material with sufficient length, a key of 32 bytes is der ived that can be truncated later if needed:</t>
<artwork><![CDATA[ <artwork><![CDATA[
DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length). DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length)
]]></artwork> ]]></artwork>
<!-- [rfced] Appendix A.1: Because the other equations in this
document don't end in periods, we removed the period from the end of
this equation. Please let us know any concerns.
Original:
DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length).
Currently:
DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length) -->
<t>where:</t> <t>where:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>MSK is exported by the EAP method.</t> <t>The MSK is exported by the EAP method.</t>
</li> </li>
<li> <li>
<t>"CoAP-EAP DTLS PSK" is the ASCII code representation of the non-N ULL terminated string (excluding the double quotes around it).</t> <t>"CoAP-EAP DTLS PSK" is the ASCII code representation of the non-N ULL-terminated string (excluding the double quotes around it).</t>
</li> </li>
<li> <li>
<t>length is the size of the output key material.</t> <t>length is the size of the output key material.</t>
</li> </li>
</ul> </ul>
</section> </section>
</section> </section>
<section anchor="using-coap-eap-for-distributing-key-material-for-iot-networ ks"> <section anchor="using-coap-eap-for-distributing-key-material-for-iot-networ ks">
<name>Using CoAP-EAP for distributing key material for IoT networks</name> <name>Using CoAP-EAP for Distributing Key Material for IoT Networks</name>
<t>Similarly, to the example of <xref target="dtls-psk"/>, where a shared <t>Similarly to the example in <xref target="dtls-psk"/>, where a shared k
key PSK for DTLS is derived, it is possible to provide key material to different ey PSK for DTLS is derived, it is possible to provide key material to different
link-layers after the CoAP-EAP authentication is complete.</t> link layers after the CoAP-EAP authentication is complete.
<t>One example is that CoAP-EAP could be used to derive the required PSK r
equired to run the 6TiSCH Constrained Join Protocol (CoJP) <xref target="RFC9031 <!-- [rfced] Appendix B: Because "PSK" stands for "Pre-Shared Key",
"/>.</t> should "a shared key PSK" be "a PSK"?
<t>Another example is when a shared Network Key is required by the devices
that join a network. An example of this Network Key can be found in ZigBee IP < Original:
xref target="ZigbeeIP"/> or THREAD protocol <xref target="THREAD"/>. After CoAP- Similarly, to the example of Appendix A.1, where a shared key PSK for
EAP execution, a security association based on OSCORE protects any exchange betw DTLS is derived, it is possible to provide key material to different
een the EAP peer and the EAP authenticator. This security association can be use link-layers after the CoAP-EAP authentication is complete. -->
d for distributing the Network Key securely and other required parameters. How t
he Network Key is distributed after a successful CoAP-EAP authentication is out </t>
of the scope of this document.</t> <t>For example, CoAP-EAP could be used to derive the PSK required to run t
<t>How a particular link-layer technology uses the MSK to derive further k he Constrained Join Protocol (CoJP) for IPv6 over the TSCH mode of IEEE 802.15.4
ey material for protecting the link-layer or use the OSCORE protection to distri e (6TiSCH) <xref target="RFC9031"/>. ("TSCH" stands for "Time-Slotted Channel Ho
bute key material is out of the scope of this document.</t> pping".)</t>
<t>Another example would be when a shared Network Key is required by the d
evices that join a network. An example of this Network Key can be found in Zigbe
e IP <xref target="ZigbeeIP"/> or the THREAD protocol <xref target="THREAD"/>. A
fter CoAP-EAP execution, a security association based on OSCORE protects any exc
hange between the EAP peer and the EAP authenticator. This security association
can be used for distributing the Network Key securely and other required paramet
ers. How the Network Key is distributed after a successful CoAP-EAP authenticati
on is outside the scope of this document.</t>
<t>How a particular link-layer technology uses the MSK to derive further k
ey material for protecting the link layer or uses OSCORE protection to distribut
e key material is outside the scope of this document.
<!-- [rfced] Appendix B: This sentence was difficult to follow.
We updated it as noted below. If this is incorrect, please clarify
the text.
Original:
How a particular link-layer technology uses the MSK to derive further
key material for protecting the link-layer or use the OSCORE
protection to distribute key material is out of the scope of this
document.
Currently (changed "uses the MSK ... or use the OSCORE protection" to
"uses the MSK ... or uses OSCORE protection"):
How a particular link-layer technology uses the MSK to derive further
key material for protecting the link layer or uses OSCORE protection
to distribute key material is outside the scope of this document. -->
</t>
</section> </section>
<section anchor="examples-of-use-case-scenario"> <section anchor="examples-of-use-case-scenario">
<name>Examples of Use Case Scenario</name> <name>Example Use Case Scenarios</name>
<t>In IoT, for an EAP peer to act as a trustworthy entity within a securit <t>In IoT networks, for an EAP peer to act as a trustworthy entity within
y domain, certain key material needs to be shared between the EAP peer and the E a security domain, certain key material needs to be shared between the EAP peer
AP authenticator.</t> and the EAP authenticator.</t>
<t>Next, examples of different use case scenarios will be elaborated on, a <t>Next, examples of different use case scenarios will be elaborated on as
bout the usage of CoAP-EAP.</t> related to the usage of CoAP-EAP.</t>
<t>Generally, four entities are involved:</t> <t>Generally, four entities are involved:</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t>2 EAP peers (A and B), which are EAP peers. They are the EAP peers. <t>Two EAP peers (A and B).
</t>
<!-- [rfced] Appendix C: "EAP peers (A and B), which are EAP peers.
They are the EAP peers." appeared to be some unintentionally repeated
text. We removed the extra text as noted below. If some additional
information for this bullet item was intended (for example, as was
done for the "EAP authenticator (C)" and "AAA server (AAA)" bullet
items), please provide the information.
Original:
* 2 EAP peers (A and B), which are EAP peers. They are the EAP
peers.
Currently:
* Two EAP peers (A and B). -->
</t>
</li> </li>
<li> <li>
<t>1 EAP authenticator (C). The EAP authenticator manages a domain whe re EAP peers can be deployed. In IoT, it can be considered a more powerful machi ne than the EAP peers.</t> <t>One EAP authenticator (C). The EAP authenticator manages a domain w here EAP peers can be deployed. In IoT networks, it can be considered a more pow erful machine than the EAP peers.</t>
</li> </li>
<li> <li>
<t>1 AAA server (AAA) - Optional. The AAA is an Authentication, Author <t>One AAA server. Optional. The AAA server is not constrained. Here,
ization, and Accounting Server, which is not constrained. Here, the EAP authenti the EAP authenticator is operating in pass-through mode.
cator acts as an EAP authenticator in pass-through mode.</t>
<!-- [rfced] Appendix C: "the EAP authenticator acts as an EAP
authenticator" read oddly and was difficult to follow. We updated
this sentence as noted below. If this update is incorrect, please
clarify the text.
Original:
Here, the EAP authenticator acts as an EAP authenticator in pass-
through mode.
Currently:
Here, the EAP authenticator is operating in pass-
through mode. -->
</t>
</li> </li>
</ul> </ul>
<t>Generally, any EAP peer wanting to join the domain managed by the EAP a <t>Generally, any EAP peer wanting to join the domain managed by the EAP a
uthenticator <bcp14>MUST</bcp14> perform a CoAP-EAP authentication with the EAP uthenticator <bcp14>MUST</bcp14> perform a CoAP-EAP authentication with the EAP
authenticator (C). This authentication <bcp14>MAY</bcp14> involve an external AA authenticator (C). This authentication <bcp14>MAY</bcp14> involve an external AA
A server. This means that A and B, once deployed, will run CoAP-EAP once, as a A server. This means that the EAP peers (A and B), once deployed, will run CoAP
bootstrapping phase, to establish a security association with C. Moreover, any o -EAP once, as a bootstrapping phase, to establish a security association with C.
ther entity, which wants to join and establish communications with EAP peers und Moreover, any other entity that wants to join and establish communications with
er C's domain must also do the same.</t> EAP peers under
<t>By using EAP, the flexibility of having different types of credentials C's domain must also do the same.</t>
can be achieved. For instance, if a device that is not battery-dependent and not <t>By using EAP, the flexibility of having different types of credentials
very constrained is available, a heavier authentication method could be used. W can be achieved. For instance, if a device that is not battery dependent and not
ith varied EAP peers and networks, more lightweight authentication methods might very constrained is available, a heavier authentication method could be used. W
need to be used (e.g., EAP-NOOB<xref target="RFC9140"/>, EAP-AKA'<xref target=" ith varied EAP peers and networks, authentication methods that are more lightwei
RFC5448"/>, EAP-PSK<xref target="RFC4764"/>, EAP-EDHOC<xref target="I-D.ietf-emu ght (e.g., EAP-NOOB <xref target="RFC9140"/>, EAP-AKA' <xref target="RFC5448"/>,
-eap-edhoc"/>, etc.) being able to adapt to different types of devices according EAP-PSK <xref target="RFC4764"/>, EAP-EDHOC <xref target="I-D.ietf-emu-eap-edho
to organization policies or devices capabilities.</t> c"/>, etc.) and
are able to adapt to different types of devices according to organization polici
es or device capabilities might need to be used.
<!-- [rfced] Appendix C: This sentence did not parse. We updated it
as noted below. If this is incorrect, please clarify "... methods
might need to be used (...) being able to ...".
Original:
With varied EAP peers and
networks, more lightweight authentication methods might need to be
used (e.g., EAP-NOOB[RFC9140], EAP-AKA'[RFC5448], EAP-PSK[RFC4764],
EAP-EDHOC[I-D.ietf-emu-eap-edhoc], etc.) being able to adapt to
different types of devices according to organization policies or
devices capabilities.
Currently:
With varied EAP peers and
networks, authentication methods that are more lightweight (e.g.,
EAP-NOOB [RFC9140], EAP-AKA' [RFC5448], EAP-PSK [RFC4764], EAP-EDHOC
[EAP-EDHOC], etc.) and are able to adapt to different types of
devices according to organization policies or device capabilities
might need to be used. -->
</t>
<section anchor="example-1-coap-eap-in-ace"> <section anchor="example-1-coap-eap-in-ace">
<name>Example 1: CoAP-EAP in ACE</name> <name>Example 1: CoAP-EAP Using ACE</name>
<t>In ACE, the process of client registration and provisioning of creden <t>When using ACE, the process of client registration and provisioning o
tials to the client is not specified. The process of Client registration and pro f credentials to the client is not specified. The process of client registration
visioning can be achieved using CoAP-EAP. Once the process of authentication wit and provisioning can be achieved using CoAP-EAP. Once the process of authentica
h EAP is completed, the fresh key material is shared between the EAP peer and th tion with EAP is completed, the fresh key material is shared between the EAP pee
e EAP authenticator. In this instance, the EAP authenticator and the Authorizati r and the EAP authenticator. With ACE, the EAP authenticator and the Authorizati
on Server (AS) of ACE can be co-located.</t> on Server (AS) can be co-located.</t>
<t>Next, a general way to exemplify how Client registration can be perfo <t>Next, a general way to exemplify how client registration can be perfo
rmed using CoAP-EAP is presented, to allow two EAP peers (A and B) to communicat rmed using CoAP-EAP is presented, to allow two EAP peers (A and B) to communicat
e and interact after a successful client registration.</t> e and interact after a successful client registration.</t>
<t>EAP peer A wants to communicate with EAP peer B (e.g., to activate a <t>EAP peer A wants to communicate with EAP peer B (e.g., to activate a
light switch). The overall process is divided into three phases. Let's start w light switch). The overall process is divided into three phases.</t>
ith EAP peer A. In the first phase, EAP peer A does not yet belong to EAP authen
ticator C's domain. Then, it communicates with C and authenticates with CoAP-EA <ul spacing="normal">
P, which, optionally, communicates with the AAA server to complete the authentic <li><t>In the first phase, EAP peer A does not yet belong to EAP authenticator C
ation process. If the authentication is successful, a fresh MSK is shared betwee 's domain. Then, it communicates with C and authenticates with CoAP-EAP, which,
n C and EAP peer A. This key material allows EAP peer A to establish a security optionally, communicates with the AAA server to complete the authentication pro
association with the C. Some authorization information may also be provided in t cess. If the authentication is successful, a fresh MSK is shared between C and E
his step. In case EAP is used in standalone mode, the AS itself having informati AP peer A. This key material allows EAP peer A to establish a security associati
on about the devices can be the entity providing said authorization information. on with C. Some authorization information may also be provided in this step. If
</t> EAP is used in standalone mode, the AS itself, having information about the devi
<t>If authentication and authorization are correct, EAP peer A has been ces, can be the entity providing said authorization information.</t>
enrolled in the EAP authenticator C's domain for some time. In particular, <xref <t>If authentication and authorization are correct, EAP peer A is enroll
target="RFC5247"/> recommends 8 hours, though the entity providing the authoriz ed in EAP authenticator C's domain for some period of time. In particular, <xref
ation information can establish this lifetime. In the same manner, B needs to p target="RFC5247"/> recommends 8 hours, though the entity providing the authoriz
erform the same process with CoAP-EAP to be part of EAP authenticator C's domain ation information can establish this lifetime. In the same manner, B needs to p
.</t> erform the same process with CoAP-EAP to be part of EAP authenticator C's domain
<t>In the second phase, when EAP peer A wants to talk to EAP peer B, it .</t></li>
contacts EAP authenticator C for authorization to access EAP peer B and obtain a <li><t>In the second phase, when EAP peer A wants to talk to EAP peer B,
ll the required information to do that securely (e.g., keys, tokens, authorizati it contacts EAP authenticator C for authorization to access EAP peer B and obta
on information, etc.). This phase does NOT require the usage of CoAP-EAP. The in all the required information to do that securely (e.g., keys, tokens, authori
details of this phase are out of the scope of this document, and the ACE framewo zation information, etc.). This phase does NOT require the usage of CoAP-EAP.
rk is used for this purpose <xref target="RFC9200"/>.</t> The details of this phase are outside the scope of this document; the ACE framew
<t>In the third phase, EAP peer A can access EAP peer B with the credent ork is used for this purpose. See <xref target="RFC9200"/>.</t></li>
ials and information obtained from EAP authenticator C in the second phase. This <li><t>In the third phase, EAP peer A can access EAP peer B with the cre
access can be repeated without contacting the EAP authenticator, while the cred dentials and information obtained from EAP authenticator C during the second pha
entials given to A are still valid. The details of this phase are out of the sc se. This access can be repeated without contacting the EAP authenticator, while
ope of this document.</t> the credentials given to A are still valid. The details of this phase are outsi
<t>It is worth noting that the first phase with CoAP-EAP is required to de the scope of this document.
join the EAP authenticator C's domain. Once it is performed successfully, the c
ommunications are local to the EAP authenticator C's domain and there is no need <!-- [rfced] Appendix C.1: Does "while" in this sentence mean "at
to perform a new EAP authentication as long as the key material is still valid. the same time as" or "as long as" (per the "as long as the key
When the keys are about to expire, the EAP peer can engage in a re-authenticati material is still valid" phrase in the "It is worth noting that the
on as explained in <xref target="re-authentication"/>, to renew the key material first phase ..." paragraph)?
.</t>
Original:
This access can be repeated without contacting the EAP
authenticator, while the credentials given to A are still valid. -->
</t></li>
</ul>
<t>It is worth noting that the first phase with CoAP-EAP is required to
join
EAP authenticator C's domain. Once it is performed successfully, the communicat
ions are local to EAP authenticator C's domain and there is no need to perform a
new EAP authentication as long as the key material is still valid. When the key
s are about to expire, the EAP peer can engage in a re-authentication to renew t
he key material,
as explained in <xref target="re-authentication"/>.
<!-- [rfced] Appendix C.1: We had trouble following the meaning of
"the first phase with CoAP-EAP". If the suggested text is not
correct, please provide clarifying text.
Original:
It is worth noting that the first phase with CoAP-EAP is required to
join the EAP authenticator C's domain.
Suggested:
It is worth noting that to join EAP authenticator C's domain, the
first phase (authentication via CoAP-EAP) is required. -->
</t>
</section> </section>
<section anchor="example-2-multi-domain-with-aaa-infrastructures"> <section anchor="example-2-multi-domain-with-aaa-infrastructures">
<name>Example 2: Multi-domain with AAA infrastructures</name> <name>Example 2: Multiple Domains with AAA Infrastructures</name>
<t>A device (A) of the domain acme.org, which uses a specific kind of cr <t>A device (A) of the domain acme.org uses a specific kind of credentia
edential (e.g., AKA) and intends to join the um.es domain. This user does not be l (e.g., AKA) and intends to join the um.es domain. This user does not belong to
long to this domain, for which first it performs a client registration using CoA this domain, for which it first performs a client registration using CoAP-EAP.
P-EAP. For this, it interacts with the EAP authenticator's domain, which in turn To do this, it interacts with the EAP authenticator's domain, which in turn comm
communicates with an AAA infrastructure (acting as AAA client). Through the loc unicates with a AAA infrastructure (acting as a AAA client). Through the local A
al AAA server communicate with the home AAA server to complete the authenticatio AA server communicate with the home AAA server to complete the authentication an
n and integrate the device as a trustworthy entity into the domain of EAP authen d integrate the device as a trustworthy entity into EAP authenticator C's domain
ticator C. In this scenario, the AS under the role of the EAP authenticator rece . In this scenario, the AS, in the role of the EAP authenticator, receives the k
ives the key material from the AAA infrastructure</t> ey material from the AAA infrastructure.
<!-- [rfced] Appendix C.2:
a) Should "AKA" be "AKA'", as used elsewhere in this document?
Original:
A device (A) of the domain acme.org, which uses a specific kind of
credential (e.g., AKA) and intends to join the um.es domain.
b) This sentence does not parse. It appears that some words are
missing. Please clarify "Through the local AAA server communicate
with the home AAA server ...".
Original:
Through the local AAA server
communicate with the home AAA server to complete the authentication
and integrate the device as a trustworthy entity into the domain of
EAP authenticator C. -->
</t>
</section> </section>
<section anchor="example-3-single-domain-with-aaa-infrastructure"> <section anchor="example-3-single-domain-with-aaa-infrastructure">
<name>Example 3: Single domain with AAA infrastructure</name> <name>Example 3: Single Domain with a AAA Infrastructure</name>
<t>As a University Campus, with several Faculty buildings and each one h <t>In this scenario, a university campus has several faculty buildings,
as its criteria or policies in place to manage EAP peers under an AS. All buildi where each building has its criteria or policies in place to manage EAP peers un
ngs belong to the same domain (e.g., um.es). All these buildings are managed wit der an AS. All buildings belong to the same domain (e.g., um.es). All these buil
h AAA infrastructure. A new device (A) with credentials from the domain (e.g., u dings are managed with a AAA infrastructure. A new device (A) with credentials f
m.es) will be able to perform the device registration with an EAP authenticator rom the domain (e.g., um.es) will be able to perform the device registration wit
(C) of any building if they are managed by the same general domain.</t> h an EAP authenticator (C) of any building if they are managed by the same gener
al domain.</t>
</section> </section>
<section anchor="example-4-single-domain-without-aaa-infrastructure"> <section anchor="example-4-single-domain-without-aaa-infrastructure">
<name>Example 4: Single domain without AAA infrastructure</name> <name>Example 4: Single Domain Without a AAA Infrastructure</name>
<t>In another case, without a AAA infrastructure, with an EAP authentica <t>In another case, without a AAA infrastructure, with an EAP authentica
tor that has co-located the EAP server, and using EAP standalone mode, all the d tor that has co-located the EAP server, and using EAP standalone mode, all the d
evices can be managed within the same domain locally. Client registration of an evices can be managed within the same domain locally. Client registration of an
EAP peer (A) with Controller (C) can also be performed in the same manner.</t> EAP peer (A) with a Controller (C) can also be performed in the same manner.</t>
</section> </section>
<section anchor="other-use-cases"> <section anchor="other-use-cases">
<name>Other use cases</name> <name>Other Use Cases</name>
<section anchor="coap-eap-network-access-control"> <section anchor="coap-eap-network-access-control">
<name>CoAP-EAP for network access authentication</name> <name>CoAP-EAP for Network Access Authentication</name>
<t>One of the first steps for an EAP peer is to perform the authentica <t>One of the first steps for an EAP peer is to perform the authentica
tion to gain access to the network. To do so, the device first must be authentic tion to gain access to the network. To do so, the device must first be authentic
ated and granted authorization to gain access to the network. Additionally, secu ated and granted authorization to gain access to the network. Additionally, secu
rity parameters such as credentials can be derived from the authentication proce rity parameters such as credentials can be derived from the authentication proce
ss, allowing the trustworthy operation of the EAP peer in a particular network b ss, allowing the trustworthy operation of the EAP peer in a particular network b
y joining the security domain. By using EAP, this can be achieved with flexibili y joining the security domain. By using EAP, this can be achieved with flexibili
ty and scalability, because of the different EAP methods available and the abili ty and scalability, because of the different EAP methods available and the abili
ty to rely on AAA infrastructures if needed to support multi-domain scenarios, w ty to rely on AAA infrastructures if needed to support multi-domain scenarios, w
hich is a key feature when the EAP peers deployed under the same security domain hich is a key feature when the EAP peers deployed under the same security domain
belong, for example, to different organizations.</t> belong, for example, to different organizations.</t>
<t>In the process of joining a network, there are two cases: 1) the no <t>The following two cases apply to the process of joining a network:
de does not have an IPv6 address; 2) the node does have an IPv6 address (e.g., l 1)&nbsp;the node has an IPv6 address (e.g., link-local IPv6 or IPv6 global addre
ink-local IPv6 or IPv6 global address).</t> ss) and 2)&nbsp;the node does not have an IPv6 address.</t>
<t>In networks where the device is placed, and no IP support is availa <t>In networks where the device is in place but no IP support is avail
ble until the EAP peer is authenticated, specific support for this EAP lower lay able until the EAP peer is authenticated, specific support for this EAP lower la
er has to be defined to allow CoAP-EAP messages to be exchanged between the EAP yer has to be defined to allow CoAP-EAP messages to be exchanged between the EAP
peer and the EAP authenticator. For example, in IEEE 802.15.4 networks, a new KM peer and the EAP authenticator. For example, in IEEE 802.15.4 networks, a new K
P ID can be defined to add such support in the case of IEEE 802.15.9 <xref targe ey Management
t="ieee802159"/>. Where can be assumed that the device has at least a link-layer Protocol (KMP) ID can be defined to add such support in the case of IEEE 802.15.
IPv6 address.</t> 9 <xref target="IEEE802159"/>, where it can be assumed that the device has at le
<t>When the EAP peer intends to be admitted into the network, it would ast a link-layer IPv6 address.
search for an entity that offers the CoAP-EAP service, be it the EAP authentica
tor directly, or through the intermediary (i.e., proxy). See <xref target="disco <!-- [rfced] Appendix C.5.1: We corrected the incomplete
very-section"/>.</t> "Where can ..." sentence as follows. If this change is not correct,
<t>CoAP-EAP will run between the EAP peer and the EAP authenticator or please provide clarifying text.
through an intermediary entity such as a proxy, as happens in a mesh network, w
here the EAP authenticator could be placed to 1 or more hops from the EAP peer. Original (the previous sentence is included for context):
In the case a proxy participates in CoAP-EAP, it will be because it is already a For
trustworthy entity within the domain, which communicates through a secure chann example, in IEEE 802.15.4 networks, a new KMP ID can be defined to
el with the EAP authenticator, as illustrated by <xref target="fig-network-proxy add such support in the case of IEEE 802.15.9 [ieee802159]. Where
"/>.</t> can be assumed that the device has at least a link-layer IPv6
<t>Thus, the EAP peer follows the same process described in <xref targ address.
et="coap-eap-network-access-control"/> to perform the authentication. As mention
ed, either with a direct link to the EAP authenticator, or through an intermedia Currently (now one sentence that includes the expansion for "KMP"):
ry entity (proxy) that is already part of the network (already shares key materi For
al and communicates through a secure channel with the authenticator) and can aid example, in IEEE 802.15.4 networks, a new Key Management Protocol
in running CoAP-EAP.</t> (KMP) ID can be defined to add such support in the case of IEEE
<t>When CoAP-EAP is completed, and the OSCORE security association is 802.15.9 [IEEE802159], where it can be assumed that the device has at
established with the EAP authenticator, the EAP peer receives the local configur least a link-layer IPv6 address. -->
ation parameters for the network (e.g. a network key) and can configure a global
IPv6 address. Moreover, there is no need of a CoAP proxy after a successful aut </t>
hentication.</t> <t>When the EAP peer intends to be admitted into the network, it would
<t>For removal, if the EAP authenticator decides to remove a particula search for an entity that offers the CoAP-EAP service, be it directly via the E
r EAP peer from the network or the peer itself intends to leave, either EAP peer AP authenticator or through an intermediary (i.e., proxy). See <xref target="dis
or EAP authenticator can directly send a DELETE command to explicitly express t covery-section"/>.</t>
hat the network access state is removed, and the device will no longer belong to <t>CoAP-EAP will run between the EAP peer and the EAP authenticator or
the network. Thus, any state related to the EAP peer is removed in the EAP auth through an intermediary entity such as a proxy, as happens in a mesh network, w
enticator. Forced removal can be done by sending new specific key material to th here the EAP authenticator could be placed one or more hops away from the EAP pe
e devices that still belong to the network, excluding the removed device, follow er. In the case that a proxy participates in CoAP-EAP, it will be because it is
ing a similar model as 6TiSCH Join Protocol <xref target="RFC9031"/> or Zigbee I already a trustworthy entity within the domain and communicates through a secure
P<xref target="ZigbeeIP"/>. The specifics on how this process is to be done, is channel with the EAP authenticator, as illustrated by <xref target="fig-network
out of the scope of this document.</t> -proxy"/>.
<!-- [rfced] Appendix C.5.1: Per the phrase "entity (proxy) that is
already part of the network (already shares key material and
communicates through a secure channel with the authenticator)" in the
next paragraph of this section and per Figure 10, we updated this
sentence accordingly. If this is incorrect, please clarify what
communicates through a secure channel.
Original:
In the case a proxy participates in CoAP-
EAP, it will be because it is already a trustworthy entity within the
domain, which communicates through a secure channel with the EAP
authenticator, as illustrated by Figure 10.
Currently:
In the case that a proxy participates in
CoAP-EAP, it will be because it is already a trustworthy entity
within the domain and communicates through a secure channel with the
EAP authenticator, as illustrated by Figure 10. -->
</t>
<t>If the EAP peer cannot connect to the EAP authenticator directly, t
he
EAP peer can follow the same process as that described in
<xref target="proxy"/> to perform the authentication (i.e., can connect via
an intermediary entity (proxy) that is already part of the network (already shar
es
key material and communicates through a secure channel with the authenticator) a
nd
can aid in running CoAP-EAP).
<!-- [rfced] Appendix C.5.1: This paragraph had several issues:
This section (Appendix C.5.1) cited itself, and in the second
sentence, "As mentioned, either ..." was unclear. Also, the
second sentence was incomplete. Please review all of our updates
carefully, and let us know if anything is incorrect.
(Side note: We cited Section 3.6 here because although Section 3.1
mentions both direct links and linking via a proxy, it doesn't
provide any descriptive text.)
Original:
Thus, the EAP peer follows the same process described in
Appendix C.5.1 to perform the authentication. As mentioned, either
with a direct link to the EAP authenticator, or through an
intermediary entity (proxy) that is already part of the network
(already shares key material and communicates through a secure
channel with the authenticator) and can aid in running CoAP-EAP.
Currently (the direct connection is mentioned in the previous
paragraph, so we did not mention it again here):
If the EAP peer cannot connect to the EAP authenticator directly,
the EAP peer can follow the same process as that described in
Section 3.6 to perform the authentication (i.e., can connect via
an intermediary entity (proxy) that is already part of the network
(already shares key material and communicates through a secure
channel with the authenticator) and can aid in running CoAP-EAP). -->
</t>
<t>When CoAP-EAP is completed and the OSCORE security association is e
stablished with the EAP authenticator, the EAP peer receives the local configura
tion parameters for the network (e.g., a network key) and can configure a global
IPv6 address. Moreover, there is no need for a CoAP proxy after a successful au
thentication.</t>
<t>For removal, if the EAP authenticator decides to remove a particula
r EAP peer from the network or the peer itself intends to leave, either the EAP
peer or the EAP authenticator can directly send a DELETE command to explicitly e
xpress that the network access state is removed, and the device will no longer b
elong to the network. Thus, any state related to the EAP peer is removed in the
EAP authenticator. Forced removal can be done by sending new specific key materi
al to the devices that still belong to the network, excluding the removed device
, following a model similar to CoJP for 6TiSCH <xref target="RFC9031"/> or Zigbe
e IP <xref target="ZigbeeIP"/>. The specifics on how this process is to be done
are outside the scope of this document.</t>
<figure anchor="fig-network-proxy"> <figure anchor="fig-network-proxy">
<name>CoAP-EAP through CoAP proxy</name> <name>CoAP-EAP Through CoAP Proxy</name>
<artset> <artset>
<artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="144" width="568" viewBox="0 0 568 144" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round"> <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2 000/svg" version="1.1" height="144" width="568" viewBox="0 0 568 144" class="dia gram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linec ap="round">
<path d="M 8,32 L 8,80" fill="none" stroke="black"/> <path d="M 8,32 L 8,80" fill="none" stroke="black"/>
<path d="M 72,32 L 72,80" fill="none" stroke="black"/> <path d="M 72,32 L 72,80" fill="none" stroke="black"/>
<path d="M 144,32 L 144,80" fill="none" stroke="black"/> <path d="M 144,32 L 144,80" fill="none" stroke="black"/>
<path d="M 216,32 L 216,80" fill="none" stroke="black"/> <path d="M 216,32 L 216,80" fill="none" stroke="black"/>
<path d="M 440,32 L 440,80" fill="none" stroke="black"/> <path d="M 440,32 L 440,80" fill="none" stroke="black"/>
<path d="M 560,32 L 560,80" fill="none" stroke="black"/> <path d="M 560,32 L 560,80" fill="none" stroke="black"/>
<path d="M 8,32 L 72,32" fill="none" stroke="black"/> <path d="M 8,32 L 72,32" fill="none" stroke="black"/>
<path d="M 144,32 L 216,32" fill="none" stroke="black"/> <path d="M 144,32 L 216,32" fill="none" stroke="black"/>
skipping to change at line 1893 skipping to change at line 2509
<polygon class="arrowhead" points="440,64 428,58.4 428,69.6" f ill="black" transform="rotate(0,432,64)"/> <polygon class="arrowhead" points="440,64 428,58.4 428,69.6" f ill="black" transform="rotate(0,432,64)"/>
<polygon class="arrowhead" points="232,112 220,106.4 220,117.6 " fill="black" transform="rotate(180,224,112)"/> <polygon class="arrowhead" points="232,112 220,106.4 220,117.6 " fill="black" transform="rotate(180,224,112)"/>
<polygon class="arrowhead" points="232,64 220,58.4 220,69.6" f ill="black" transform="rotate(180,224,64)"/> <polygon class="arrowhead" points="232,64 220,58.4 220,69.6" f ill="black" transform="rotate(180,224,64)"/>
<polygon class="arrowhead" points="144,64 132,58.4 132,69.6" f ill="black" transform="rotate(0,136,64)"/> <polygon class="arrowhead" points="144,64 132,58.4 132,69.6" f ill="black" transform="rotate(0,136,64)"/>
<polygon class="arrowhead" points="88,64 76,58.4 76,69.6" fill ="black" transform="rotate(180,80,64)"/> <polygon class="arrowhead" points="88,64 76,58.4 76,69.6" fill ="black" transform="rotate(180,80,64)"/>
<g class="text"> <g class="text">
<text x="32" y="52">EAP</text> <text x="32" y="52">EAP</text>
<text x="180" y="52">CoAP</text> <text x="180" y="52">CoAP</text>
<text x="480" y="52">EAP</text> <text x="480" y="52">EAP</text>
<text x="36" y="68">peer</text> <text x="36" y="68">peer</text>
<text x="184" y="68">Proxy</text> <text x="184" y="68">proxy</text>
<text x="504" y="68">authenticator</text> <text x="504" y="68">authenticator</text>
<text x="108" y="84">CoAP</text> <text x="108" y="84">CoAP</text>
<text x="324" y="84">CoAP</text> <text x="324" y="84">CoAP</text>
<text x="328" y="100">OSCORE/DTLS</text> <text x="328" y="100">OSCORE/DTLS</text>
<text x="284" y="116">Security</text> <text x="284" y="116">security</text>
<text x="368" y="116">Association</text> <text x="368" y="116">association</text>
</g> </g>
</svg> </svg>
</artwork> </artwork>
<artwork type="ascii-art" align="center"><![CDATA[ <artwork type="ascii-art" align="center"><![CDATA[
+-------+ +--------+ +--------------+ +-------+ +--------+ +--------------+
| EAP | | CoAP | | EAP | | EAP | | CoAP | | EAP |
| peer |<------>| Proxy |<------------------------->| authenticator| | peer |<------>| proxy |<------------------------->| authenticator|
+-------+ CoAP +--------+ CoAP +--------------+ +-------+ CoAP +--------+ CoAP +--------------+
OSCORE/DTLS OSCORE/DTLS
<--(Security Association)--> <--(security association)-->
]]></artwork> ]]></artwork>
</artset> </artset>
</figure> </figure>
<t>Given that EAP is also used for network access authentication, this
service can be adapted to other technologies. For instance, to provide network <!-- [rfced] Figure 10: We see "(security association)" in the ASCII
access control to very constrained technologies (e.g., LoRa network). Authors in art but "security association" in the SVG. If you prefer the
<xref target="lo-coap-eap"/> provide a study of a minimal version of CoAP-EAP f parentheses, please correct the SVG in the edited copy of the XML.
or LPWAN networks with interesting results. In this specific case, the compressi If you prefer that the parentheses be removed, let us know, and we
on by SCHC for CoAP <xref target="RFC8824"/> can be leveraged.</t> will update the ASCII art accordingly. -->
<t>Given that EAP is also used for network access authentication, this
service can be adapted to other technologies -- for instance, to provide networ
k access control to very constrained technologies (e.g., Long Range (LoRa) netwo
rks). The authors of <xref target="LO-CoAP-EAP"/> provide a study of a minimal v
ersion of CoAP-EAP for LPWANs, with interesting results. In this specific case,
compression as provided by Static Context Header Compression (SCHC) for CoAP <xr
ef target="RFC8824"/> can be leveraged.</t>
</section> </section>
<section anchor="coap-eap-for-service-authentication"> <section anchor="coap-eap-for-service-authentication">
<name>CoAP-EAP for service authentication</name> <name>CoAP-EAP for Service Authentication</name>
<t>It is not uncommon that the infrastructure where the device is depl oyed and the services of the EAP peer are managed by different organizations. Th erefore, in addition to the authentication for network access control, the possi bility of a secondary authentication to access different services has to be cons idered. This process of authentication, for example, will provide the necessary key material to establish a secure channel and interact with the entity in charg e of granting access to different services.</t> <t>It is not uncommon that the infrastructure where the device is depl oyed and the services of the EAP peer are managed by different organizations. Th erefore, in addition to the authentication for network access control, the possi bility of a secondary authentication to access different services has to be cons idered. This process of authentication, for example, will provide the necessary key material to establish a secure channel and interact with the entity in charg e of granting access to different services.</t>
<t>In 5G, for example, consider primary and secondary authentication u sing EAP <xref target="TS133.501"/>.</t> <t>In 5G, for example, consider primary and secondary authentication u sing EAP <xref target="TS133.501"/>.</t>
</section> </section>
</section> </section>
</section> </section>
<section numbered="false" anchor="acknowledgments"> <section numbered="false" anchor="acknowledgments">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t>We would like to thank the reviewers of this work: Paul Wouters, Heikki <t>We would like to thank the reviewers of this work: <contact
Vatiainen, Josh Howlett, Deb Cooley, Eliot Lear, Alan DeKok, Carsten Bormann, M fullname="Paul Wouters"/>, <contact fullname="Heikki Vatiainen"/>,
ohit Sethi, Benjamin Kaduk, Christian Amsuss, John Mattsson, Goran Selander, Ale <contact fullname="Josh Howlett"/>, <contact fullname="Deb Cooley"/>,
xandre Petrescu, Pedro Moreno-Sanchez and Eduardo Ingles-Sanchez.</t> <contact fullname="Eliot Lear"/>, <contact fullname="Alan DeKok"/>,
<t>We would also like to thank Gabriel Lopez-Millan for the first review o <contact fullname="Carsten Bormann"/>, <contact fullname="Mohit
f this document, and we would like to thank Ivan Jimenez-Sanchez for the first p Sethi"/>, <contact fullname="Benjamin Kaduk"/>, <contact
roof-of-concept implementation of this idea, Julian Niklas Schimmelpfennig for t fullname="Christian Amsüss"/>, <contact fullname="John Preuß Mattsson"/>,
he implementation of the Erbium-based IoT device implementation, and Daniel Mene <contact fullname="Göran Selander"/>, <contact fullname="Alexandre
ndez Gonzalez for the Python implementation.</t> Petrescu"/>, <contact fullname="Pedro Moreno-Sanchez"/>, and <contact
<t>And thank for their valuable comments to Alexander Pelov and Laurent To fullname="Eduardo Ingles-Sanchez"/>.</t>
utain, especially for the potential optimizations of CoAP-EAP.</t> <t>We would also like to thank <contact fullname="Gabriel
<t>This work was supported in part by Grant PID2020-112675RB-C44 funded by Lopez-Millan"/> for the first review of this document, <contact fullname="
MCIN/AEI/10.13039/5011000011033 (ONOFRE-3-UMU) and in part by the H2020 EU proj Ivan Jimenez-Sanchez"/> for the first
ect IoTCrawler under contract 779852.</t> proof-of-concept implementation of this idea, <contact fullname="Julian
Niklas Schimmelpfennig"/> for the implementation of the Erbium-based IoT
device implementation, and <contact fullname="Daniel Menendez
Gonzalez"/> for the Python implementation.</t>
<t>Thanks also to <contact fullname="Alexander Pelov"/> and <contact
fullname="Laurent Toutain"/> for their valuable comments, especially regarding
the
potential optimizations of CoAP-EAP.</t>
<t>This work was supported in part by Grant PID2020-112675RB-C44 funded
by MCIN/AEI/10.13039/5011000011033 (ONOFRE-3-UMU) and in part by the
H2020 EU project IoTCrawler under contract 779852.</t>
</section> </section>
</back> </back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+196VYbWZrgfz3FHfzDqFKSWb3QndUtg5ymEgwNuLK6q/Pk
CaQAohyKUEeEICnjPvMg86OfpR9lnmS+9S6xyOCqmuk5M5yqNEgRd/nud799
GQ6HvSqp0njPTManw8uojGdmvKxu4qxKplGV5Jk5j4vbZBqbq7ww+/n4tDfL
p1k0h1dmRXRVDZO4uhpG03h4dz2c5tFiGMP/N3d70eVlEd/u0TtDGL3XSxbF
nqmKZVltbWy82djqlcvLeVKWMMvF/QIGPJxcvOtFRRztmfPJfu8uLz5dF/ly
sWfG+xPzE/yZZNfmB/yoB6vbM2U1603zrIyzclnS2HEPPpjBY3tmCet63Vsk
e+aZmUaZWZaxiYoiujfryZWJ0tTcx2XfwLZuovLG3MRF3DOmyqd7+AX8WuZF
VcRXpf37fu7/CU/O4kV1s2e2e70IgJYXe72hSTJ44mxkjqMiyYZH+SL+MzzM
EDuLrqLaF3kBS/2YJbdxUSbVvcmvzPGymCYRfKcg7Pi6hNXFAIX9aL5YlmYW
m0m5SLKomOXm/MWHgXkXTZcpv7SfwzNVXJjzaRJnU9zpFMbbc6MV8TUcxJ55
/hy/y2ew3O2NzY0N+muZVQU8fL6Ikgw+iOdRku4ZOP/oH5fzEYBD9n0wMj9E
OOBwH0CdpGlu934AR9D8rmX7J7dJPMs7t2+/dttP09gcLZPSnBRV8mfzNi6K
fBqlDITJLLlKpkluTvM0uY1SQG23+x+SP+WZt/lxWS2LJCodCLa3NrZXgOCa
djSLsn9cZkl+myAser0sL+Zwe27jPXjSnL3b39rcfKO/727tvNLft1/tvNbf
X23tbunvr19ubtvfN1/t6O8vX76y777e3nLPvNmx4796swu/w3XLrtwy4LvD
4cGILms8X9IljWc3gOw9eenlK/l19/XLN/LrzquXO/rp5ptN/XVne9v+yuun
pb15qYO9tg+8fr2lI7zZ3NEpdja3X7lPN+yvr3QE2P+ufgrEwj7wxv66sa3L
2dnYtINt7G7bKV7bwXZ2XiJAjMH/I6G7KgAlkbwMD/MLgpupouIasemmqhbl
3osXSRzHvy7SvIhH+OsIEPUFUL7lHPDnxZvdV2+2X7/iF5l+rp3H02URmw9x
hQOb8XQal2WdmCIRhSnNQYw0tSSya97pasxtOTKH2Sy5TWZLwN/TIgcik6fl
Gs2kNAZ/l/t2PAL6XN0k9JnetEmRTMuS8NqYWVTBR1sbW5u4+TS3NLp923d3
d6P5bJGMpvn8xebO1s7w9dbWxovNVy82N19svdx5Gex5zNT9LfGN1Tv32chR
fjc8ze+AGv2UANUaA8XXt2FPRydD5RnNfdudt1IaHwrt9MYboUGj/beRUsdp
ywPy8nhkfoyyWVRG8/vaq+NimS2K6PJm2XjEvXwap/lt/cU0/hVeALC4b/X4
Nl/1iAp9y9m9fLH9Ynv3dXByR8n1TXUX43/9M3yb5xXQ1WixQE7rnxkcJqAm
cJAsrpAMX9zAEy2I+X/4gCy8XiK8Ls43t7dHuxubIcDW1gJY7P7wd4ZuL3IY
WNBNUsXTCi8znIZZAC+JZ/BXSXDY/cGc35dVPIdVXpwbGN/A+Ob3m7ujrdGG
WYepXw83N/rtkCF2J9PjD+1zcnF+WNud/cju5zXu51+S68s4PjxduR146G0M
h3UKvCqeIvPjG7jOb5sDoWJm483uxtZ2sb3zlMXKIOM0TSKWI/x1t31rt7CD
W0Bi+hqo0e6blZs4nEwm5rzC+1PMCPAXRZSVCxDJEPt+jO/h6LPoOqadKKE0
6z8en/YBs6roGohqB3q27gsnrG3GfhTS0Iv3Z5PxwcrVX9wASZuZMoD/5mj7
CeuRIVjYDdfV+MquDwTRXm84HILohLd4WvV6cE9BNNQjlxUBLsPli0IKXcpt
r26iCoXlku785NcKpOvkEkSsGkV3QAdK3QfhW84HyEg8B855jyRkH6Rz+CbJ
ULFYLNLmy0h9+mYOLANOE/jfuDTlcnozMEkFIu0VvEmLRUaZEs9Io3v4L+sq
MBK+D/I9yIAzq2uMzEkWI57gDkBQy8x1HqWlAVBUub9vuOL8UpxFlzgCMucZ
MWfallnEcdFnkCRA/bIZjfCnHIaMAGJCNGY5TTInjJyZy3saFgTGHJZV8Eje
rHnRR74NmsssvaeNwvLzOxThC+D9ALZPgN8gusGfIAbAhECEkCbxZhVWJv51
ehNlNCNwzzjOcL9zB5qTyz/hS5a2sQrnDuRscn5xtUzNJLtNijxDDCnN+sn5
/snZpD8wBBNcDUIxLiv8q7whPALQetuPQNoAMk4H669kJNg4T2azFDSzZ8hB
iny2nOKj34Kb65HDof63YurnzyJ5f/lCFB4WcblM0gpBVuULxZtHoi6NhrI7
jNZAQ/0N58BdecPQ4uXc/d0ivO9yPmnAtwWgGpwKoNSyxO8IlWDR9jzww+gv
POvHHOUxiMKOoqWIuFXH+d3kd3otcRQ8ohmMDCgzdSsaGMCtT0O+zQmIPQvY
LYwzAGUMuAceY/3O+wcHl8JSHHrQ3gpdNt9sQh28g0ANCVSlcfcaASmPTdME
N1F7LLy0cgTBJRwBOY6DIW4ixsd8QVAEbIJdVzou3M7pJ9ipGY/HsG3QRAAg
SxY3YE8gui3SuIoZo2HQLL7OKz6QAa5qFpfTIrkEgCaZfShkNB6YRnjJYoEP
cB0kX4h3cjA+zb5LqhuHr8cfzy+AvhB0p8X9osqBoS5ukqkjSzQNKrNwGiwh
AjYEKxnBnYxwPyVCAam6XUVU0KqGP5ye/ygjgVb55cuAPj0/POYPUYvTD8c/
jp/ro7g3/vTi6Bw563/+B32DGqJ+Mzl4f7IPL7TrvfhUXE1R3zLXcRYXUQrw
ze49WCGsk+uMQT05/hhaoBiQDCI+8GM4SrSwxGTSIhll/fj8x35wDQIwM/J0
vgfw1KuD4wNdT1gIvVoW8EFROxniHgR4wkp49i6CWxryDAS8cBMc+QpnDokt
sGD6VBf5HE5vAfARFARSQ0SjnWbApJYyhXzJI2ZCYIWoj8zHUrkM8D381eLY
VZHP6YtwiQOT0/7bllCirSbFqeVcYZ8jQIMroCTD/Gpo9zKcVWkJuFveIAlG
mgX3zy4ebur6QR+xq3Wfy68vuUY/ELK9Xl0u8ThCyXY6xzCa6pZZB/mkDzSB
deWBuUOrpbmLCcVAVpoZoHX3PpklKgsvxqPrEZLceYLnfgmU7y6ZVTdMA1ni
KRk59ZlptIgukzSpkpjMErjoMiYJqZyCbFAkOa4gNgmS7eTqnnVEJ0AJ2uKX
1T1fl7sIzx/gfBkcKctMjsE5EUskKxbAyi4Ji++RNzU8muiCp5GVEITw056F
xcsIA3+pcB3hLOV865jXcrQ5LOAdHnsGSKTPhKsp4qu4KGDlKH9+dTX+I7V5
DoNtDQLSTsd3FSPDVNEQngD8LvA+KwkY0IQh6YjS6xxw/GaOwndSEfdFQuMj
kiIJUxDcDz7GoL+Em3aVuKuNq7JGNjwKhAa+eJNc36RodWCq+vlzwxxHTKv3
7Jk5i/9tmRQxSypHsJklrJ75GYrH8DxseQ0Z1dqA/zUfTuj3s8k/fTw8mxzg
7+fvx0dH9peePHH+/uTj0YH7zb25f3J8PPlwwC/Dpyb4qLd2PP7nNYbg2snp
xeHJh/HRGuOaLwtFzM0By1FrKABcRG3LXsC+3+6f/ud/bO4AFP6b2IiBHPEf
aPSFP+B+ZzxbnqX38icA+L4HhCOOUHAiTwbcVTi1tCQRAQlaRv4MgORv/oiQ
+XnP/P3ldLG581v5ADccfKgwCz4kmDU/abzMQGz5qGUaC83g8xqkw/WO/zn4
W+Huffj3/wBkLjbDzdf/8FvAnjPQj+OCURU4NPM6Po+raA40DSBHlwVxFc5n
XvKdyLNpvKhqQhbxT0/K5zvny6K+JITjCIOkj9GSTyj9zPzAYoYZeyamXu/z
ZzQ5wZtJmi7xslVCrQJLFGvCswamjQxTBNQvvOcHT9OIiAzdwQIMiKksqfuy
s5PumGMPLMkS8tygU94YLBUzmWDGG6VIMG4SGgP3AiJjKcIDEXocroDbD8wY
vgUaMFXZIkpBpClDHiuLRIXAo6ojtEMDiQAyjqoKDwmybobM4KtjEkC8EXkO
OMVDYkNAewB5spy1NVxyK7U2gLlMABCshHAr5X+83jw9iBrD6gbEzGsQmfNZ
rKIgcvwExGg6q0UaTeM6GEQrwNEVMCTwowqSZIxZ1jMEACiYys4ahpEAmEx2
F4o1ICRNP5mkdlE+f6bPAdtX6b11VRsfRXuNr3p7zxMmF7EMRButcHnzCLA9
i506UyyzmvwOTLlVLXE8XOR8IojlckHaDvIWJ0mzrk1CPtNWUXJlw/bew5fd
cjxaSyqTxvC9ebljciBHlbBh3BPe0hmM2Pb+pHsAD8pA+XNSm1HTEorFWjTK
b/ewT5QGknJeWoJW15/ZUW9yxJiPB6eqp2RXCWAKUhCrQax7tJDc5+7Fi/3T
gQGZeYAf/xRfnueA63CHmRJubzEl/Pd//3cTReXtdc+Y74by853aOO0ntc/r
X34Hbz+QO8/QL/yDv/BH9k/3g3/BxXiBv/LbdM/Nw9/zkL99CO+vfi5f4rjn
dKceaisnCLSvHC9iy8of87N+smBy2YcXaCnrwFhOJ+bknbl4f3huDk72PwK/
vOjT+hCuvc975hkyAjZFf79mUcRnOmvAK0iDGEYgi2Xfr03RKV6sfek4m44f
OQGB+Dldy2O5lhbkTxjHM7Kt67r79ugAAKzUqv/i0SOfMSt5cab0/8U57Doi
0yZ9/27fIDqbF/Qr4umjxz7mWwGv6m/ozeWR/8KxP2bWEAYv66/WDfLtY/97
+w/hDlP2OvKc46crsOaZI0Unql4b8/kZqM57NibIKt7wwtt4GmE8jn2NrLh2
vzP4hRRZT+yhO7YeyGEeWekriyeiJlFFsI85cY4SlGggeMD3kiypSDNFDIJH
PEIuFjNzkQMPiBdswytmrAmC8gEDg144qK35/T1sax7Pksgqbdl1wlq+bzXm
67H+fnwxORmf90dmAjcFNc2FmS2tstm0GYBEhu501LtA779DISZfFqhUZqI0
ejZOa9lkcQvUjtskX5beS/j7HGg1KhQiPISjlqAZxqiRD9Aoay3SKLzpM6zJ
kwSCvtGylGF+rXg/ng64yv7h64xO9VcZUGwa05s8Bzwh4SwyKbrbzG1UJDEH
A9VgJYowymmZPadBKNXRwkmbuoluYTFZXcUHaDL2iMCmskNTvmMWnggwQBy0
AEFBhE1ULScKJ7cAbAJFH+Rvq4aUoAO32JzxJMn2gRIGQinFNV/n1hdQG7s0
iI9JhRqP+u3t0IG5oX3CkQERdx7do670WDEXHydg2m2xQEpgFLPEfJlWySJ1
68BT6sFdY/xuMbU4bSPUrdUpiG/cxWk6/JShvvvx7NCsKbFZM+tiZCrFhHt5
bw7HH8YAT7oaL0bu1Rf6Fo2hRldaNQ2IlgD897tqCgPDfvmvu3JNLBUHSTnN
iV59fjbT34clqxhE7a7QeaLXlYiHGmhMFX2CzZAsX8PULI7Z3ahjdoBfTjmw
syFCsk+zY1oxCEYZKyhEwWADgMC/3gv5sFuxaA2wyZeVtd9OgaTzH75GyrqC
k009IiiGcCFpiIas4uBotfNT3K2K5PraWa/MehnHbdZc5AfnSH02+s4lM1TF
CK1wMrnuSqyIJVn0WSEEmhBd4gY96zSSpyt8Wkzqvu6EI5LojXu6jZKU4C2E
2ZJLHjtH7PgsUW4kBh+iZwQhxoN9yKuY/P6o7aDhYpbQxIDx1nVTQ4XD09uX
JprNCjybdqrL6BEcMeMJK0cx+2cGqDVE5uVR/tPp+IPalxkd3xIPNGc5hY8S
YlX3C3YBqrmgfeIbDDQdiI8BYBCzbxsfltHGM9hKlZQcxbF+NnaBAE4fDxZQ
uyJIeeLsGhEjz9oxXe7ouxRts1fOlaHOz9Cz3Ycr3MQttNJcJdcgOm9ahwFO
Jo4jc9UYXKOlh2LODlTrDk9um28F9XZgrIzSNM0sB+Agr8Fl1NmTKr6HGXDi
aMbQAh5aimFBFF4SA0A6KFGC82zvEe8IBsNIE5Inhn9QkkmzAz2FW16G3ICO
AklpFyYkiupleEbWAzR2n+lFvyETEktWgHCBUcBSbLjzRA7oMXyqtD5PFEXs
rXAHgzcrQi8aed4xLHQodINhbPfDRoEKZN5wzUoLAWgAvhmDbe30BJ5uZSpr
asoClhTSsr6QFN3xFKPghLE9/5APVV95bsT8+OYlWhhZ3WbnMmLWbZ4At4oS
4tKId5G1dFm/CeILshNHxsRHjXKQzs/OpPYThIteNg2DKko42aLV7KcTEK1M
smm6nJE8S+yWr+0iuk/zaGZ9Y/IGCe0zZ5CyRHXVWvnkYlkbyaUyHi+HcFsm
8gXfMk7ZUnx5Xxetm+Q6I3Ld+wlNduJnVOKG27LnwKNzvIwnHLd5lezT7MAk
iQo/Z1yV051HbKDNlHabtUVU3bwATHtBQeqgkYlfEJD7N/ztGm0vh22nFBiP
nynBFB8VQHoOkogcBny9zBJAW7r7iedTzUW2TK7IPY6MkaYhTBesIgBLzBQf
XmkBIx7s0FTLc+CNz2AZcZQpKle+1fESOPNNnC5EopzFl8trULWueQGy+edi
IWV7ISAbe5BwQN6RyZbzSzFqxyTdoALkmZxhuPN8wGqhI/pXPrf0T5lOKCng
fjvkVGD9z//+PyI6mc21nqM0m47ShIhbUnxZZIiYeFcgRFQBKSmuTLlUmHv+
QmZ7rgqg3Cr1GlhK41uDefE+6SU9Uq0mhzMWGPq87TPgNguKczk86JY51s8O
D4b7fQIQszTWldAgLpMjoXh7ciYpOaJrARsk8RLOfJGjhAiTkaN/mSASre+f
h6MCp+Ml+M/xKEL1hNwIKwTdIQJFJHzcDafCv8i/MawztTwkeMcLyxFhrZwu
SaYlvGHv6tB7iviSIMBWjdUIS5FbEpy+shgFs+UlyJrhiOB4+nXXR2ghV5dB
EVfLIrNWdMsi5LDLBQ5FC6NAI1SbGjYHmUj1z5q+ppyxho1bz/sDiTLAyKZS
LrWYJlD/Xg8Q912ScXiZXofnW6ONTbPPZonnbuVWdQ4tGByNkDhfyFHOCxye
Il1bh6W8oCQE+fSflkAE+sJRHXWy9gx3WDrz6ptAR0AX4LDvlG3lLV2Yh6iN
z6OrQ1C2xhtH1tOHq2oRhNlws0KKVOWJv/7yRaiEdQF1OjBI6g+UHGs9ardB
lEtS8TDgEDZBjO+Vxf/SbA9ftkRMtEgddfmC9VrVYdlVxi6GIk4j8fLqGyLs
ihQ7CKLdfOuZ3jUL53bqTHMvy9i/pDQBTEnSRuC2bLgjLxr7oIRET1bLSQK8
9+66fFPHg2AihJHzbCL++KJ9jYu5sKUMpAHAs4gcjwwipCc0nP5VLgY0NBoy
buMU7QKGBJ4ai0K59TZuXHy4zbwjCVH16Ze8OkA5QskfOuAL0cMv71eStBox
U0kZFIkUiBNThhgNrP63g4YJ1Ro760vffs5cRpZmgYaXyN+GIqhSRDt0kwZS
aFwRlVYEp+C8poGZJBfYJsgmM48Y1sk2yatZ1SI/R+r/83UAdu6z/O3J020W
5ceRS/ZNcWAYhiIFblpMwAyAB5w9vgYNZU6nqGevZha9EHyqGHm3M9rYMG9h
PyKFMKWS8ZXZEu8lew3PB0RhRk4dQnr6bKif+ez31YixuIN8EddxBIwDnVsN
K5dOiOoknew7dkqFI0z2TM95LgcXxCqS1jlTJPmz2o2d6UnwS03VaXIVo7Oj
7/ukuwgZ4zyvu4tTOEIBu6AF1dndZY53DEXDJEhFEKm0NJv0msg6jfQBb3Ib
s74vk1NggXX8OH6l0kn7cbC40JCgXLArUQWZEy83evqn4uEWACPj9cUtOZou
SKI4S5eK6H9kj/9IjoO0iJISPcqBU0x8As2CbwbKiY01ruJrFl5EQs45tF+Y
9/QS0FqNC8TDD8UCW59dReCSouprejqbcSIrEd9G6ZL01NfmBsgBR5J5EVm1
eAeVHDBeSqLc3YkOHcyDoyA9EvY5U+trw3aA9lQMekUyoe4nHl0upHgA2VfX
r3HVMDLEi4+nb20knjgbvjZRmcxB2CmAGQkvJzYH2jPS2ODm9oUJM0+SS+Od
N/kTkL2zgLbq3tUXzbk/1kPSAVg2rqLHpyP4OC8c+XttlaY2b6MwNKDJLqFg
5eGqFvoqlPsI4WqbAfHrDsPyFOcbA6Kkv2P2mZI8B2njHe8HvVoYOk6i4jSf
z0GVl7VZJSCNfBW8xn/Xsz5wYDIMXXaQBIyku+KEHHENeI6LRQ6/CiMgv1nX
+SFF0FB/L28rXDN8wc5BXW4ZBMrTBDZaHu3XQViGcQBd8dNAAHgziANY8a7/
mMaqPBjTbeMM3n7gVzb68IpnxVy12Ad/FpZk1tdUilzrr37lK/EO9ue3/iyd
P7xJmdo0X9HliYkElOaHB7RKPDyIyUNe2ewH0UMrf7xZfFW3Jon9UWXJn0OI
hSsiPZ6WdMhLOrQhNPzKVv9vCLGtFoiFD7vFDv+AAOzbhW3/zSC23Q0xWkS5
aEUxfWXnWyDW9jOCn6+Ax4Plejbc7IcLfyJEd/9mEAV6+nMLRM3XQCqvvPxr
42BtFoMM+OvvhdDu05NPmU6YQP01/0KKhPDw8BuRzoYqnQF55Pd7KGGbV085
K2P2L/7QkyU+AS7uFZ/Rrn7FblJ+ecQssDhjXn/zrWmAiuIOJBZyZfSaGDoa
8WtN/6zH+FfEtXEaSk1E+vysiIfhZ/Co1Sidc5OkUZR505zNO6ALJqjst9ju
MDGKDEnkcGQ7RZd5tTE9WYCLGN8h+QEnFs+b5r5L6jurrDx6huJiXN40MthQ
cX3BgcdoOyAlBkXbQSNNndfZIQsN2PsSWU1ShCESM69Rc+Zg6zSOPlnfXH0t
KrLR7iih0IbSEDQDAbWONyPz9l4VHAfzWu0IV33HJS6uUowY1gy5qrnikdmP
i0qTIjRyg3JfOad4+OHk5K2GguxsfPmCARqTlvxWhNct1se5YskWwJqhLImq
678tk+knEiBrqOAbq4dNBNKkjzNNg8eqTTCVVWQ92ZUdy+x7WsSo5ztI46ic
wevHWbBKWJ9WlRS6hGpJtnKuJkuDwsZ5S6HFcmQ+oJMOHklhmAGlxrvAmPCu
lc5OTQZLP7Cysaw99uksi5aBrBaE2B1+FSRgwExqP7T28Ob+0a2JcaeUEOvb
lTDrofMt0pU5F3zWYo3qWDhZTvgdVkkprszq2s39oC44YG91dm/wtjpvdH1J
V+gNWzl900+whNdTDJGk24rJhxgOUrEVhK80Gjoy1oeqgqI6m1jd6x1erV4V
j4lp2TVnGAZNxVO8R5ReU6OxzfE8CqO7dBuUXUhMEVERxTAO8LWUiGPOPj+b
yzO/XOZ59QuN8sUl5QcBmU37EsUh88weLluge+7FeswbY4OGWpR4h5AJzNEY
iaxmASDA6JehGXNuapyxf4+c5vB6No19p9Y6rTQvwgW+YOttP7S8kKnhwvdZ
Bz41aw3K5DPnSW1azXUolJHQgK7W1LsVBtzADuFlyVC4nos2dWQEA4oRW0vf
JhUak9aTUTwaaFGC7VdofGqBnmfa0citHgY9T2MXVt1+1OQZ52BnwlhbBEIo
UiPXiknkDmdbZVggMfZN1VaywLCfUD6oYcmlxOILM3O8t110acbON8UhicGS
QMYyqZaS4e7CdjooyJwqkumaifFTuDqHKypmDuA6cHBQVQZyAIV1IMGj16K0
Bg8qzUHDYlYo1WqxFrNaMR9x0lhfI8ZM2QTNxhFY+tQ82FkcY9oVbgpRDyMw
6TRwW23H0cxDFIrkE9GEc97E7HwwOZpcTMjIRAHpGbkV2UNVI4cDi69KTchu
VluDvbjXwEazlngoZIOIGZ6z3efsNCaydGuYbLHH1Th9PRoObX7WTicrWFV5
gqxtQOcykpCu4wL468cFZTgGRuqkDB1QfjybRhz4Ptn2U7Vmx33MzkS75ZY5
YM773LP8kkz1lG2QbdZbQBMbbPwne10lvHbyh/334w8/TH45Onw3uTg8nnSu
m/xsFvlYCAgNjF83LzaNi4E+1/le8JTofI9VXx9WPi9XwFfmHzu+Krj6/CPV
8EeP31i/jyyPef5xird9/tE699c16R3VpGm1SDEIX76iMU9Cb+znZzVXbE8q
f0mChIlBVMw57x3FZYxxtqyZXuWwBnqfOAHeiRa+j5Ig5b6DaAdaoNwhvCNq
TDfAzqwAwrIoyTug22C51UZMAy5fEh5IkMY0ftxg59xOsqsrQcCJ8Rkkem53
HmcUAnlXYPwCyApEWIF82BidEpXRpBZ53XK5mSew+vmOV2U3pay+M0PLrKsv
p06bNfYIff01ruribT3C9XwHrYgfM3VhY+SWuopeizcf2dpAvUfIufhbOm3J
phLCmXiz211k+crSSVZWVPm60+fG9PQ+rryKQV0c3aocK7XLFTK98Bg+IIuy
j1CqyoqDhlr1KtZInpkP7YiPu2mqeblLxrOOfABuPicO4w80aJNUpMSHE9K0
nBQudbHkeKxojnG5NA1ZZBCZw89sVtDsTyBe4StauEHZL3nfKMrALy3FvNT3
0sH2llIZRyRNvw4BB3aOG7YdTwxoclHMaJvHlHgSlfV0VL/0n54SzaKmEJJB
XT3BmnLWFfTWmWLBaYZxS7EGsqfBtGMfdDjhoGVP6oNnNYgNrJXkoTFeRVrL
rqzyRSklVNjg54tGVsrEBA4cp2C9HtNtObSaBo98ma6kFDHfLucyxWb5Qpzz
1ujWXD2lGMhkDf9y0L0gL1ZL2klbKL41s3I0OhGh6yLW0F4+FA3toN4DAAFS
SZLKvnOJrlxrvhnV9P26DFZbVpyQLURW1wQA8gBOJEFtshZLX1NbvTg5kIuQ
HYxaWVSLZPgXrmrQqaLnBYe4VRKq1Sx2Isp2t3q/iAsMhUJaIYbkyKt40u+M
EOqCTRRFF3CmQJYqYfEgUS6ZsMAkNkEGhf5WB7he+Fo4TD150UXsSxC8nzLi
vOmc+MkRYLNZwo4Pe21ZYBio5dSPZpRSNo1cxLZokB4pGo30SsmhtDGdncKG
sD+AXkc4eDOzmRXQDvsHCREJtmdI7ynCDws/E9OvrVHXDhOns9WZV4/fjfDr
QoKm6nuRLXYtHqW7JVZuR/PEjInESh8OkUkinciT9pWMVN3BhizbeZbL5s0Y
mff5XUzaeVILR58lMw4F4wFABmiXV1Qmw9rL+gpFrovcULPnta3h4mZZ1gRE
G8i/g17HDzlq6ACu516qrOQiqMz5hu1rvlr6jUEvj9BK6aeml4JW95vHxbuA
3rVBruMnxbo8NdClrmWu0uvanvd+wgiX9vF9f34Q5kJ69Wb/0Vqy6slPclLT
8yGufPX5xy6nO0LjNyfp7BE68RvVidsxg6geEJAOotgdoLdKqUat+hQz8z0P
duIqXICKTXn7X2qp997DpZQvt3ZVlE7gO2QSllCLatjMFk9qEWqPcF0Q9+fU
91r0m6hbi7yk0nSeaql+Y5LFcUc4b62GNBc1KMqGVB34Ieslv3BSrWsK++fo
5lLbC9Qr/OE8eLZU8EseQg3WT70tg/J+WDTDJWbTzPdMZoV/K6lDsUWrnulI
LiXXr1UYS1A9BwQ7Rze96R0RwijJOmFBcQm8X4Vo7Wmi9uWN5ix6EbpWA7FW
cJs4CKJ/nsZDNLgWZeQqwcgLl/F1kpF0o/qlrkgKmErWYWCJdVgVJhuLLtKN
a5FLK9d8Xalh7OIXWB8TkctWR+XP89RmzpAfBQTYy9gPA3eCS2AD71yR96zm
QXvnEHGVDV2WLob1cxXENngMftIvzQgP3QE+Svm4UtdseXLB+piVG6nDgA9z
N1+4vTrAB15EvZ/sSk68IHGqLQfFaoaK23gzSCbm4hFYATK6TXKeGMbXGrmi
vKKIoyU4Xrg4WVf2NAxMa81S0SQVWz7K5kmBqMRKWw3GnHONpfFiwWRvU97R
wJJBxMLKP+Tkqi3mxCoBtVwcstJ4RdZdcQPJ7P78zJbLots9xC+/9A477vdA
aEotPzywRQT5/vJA4hcyDEOdHSdzpRcQE1qqLHg1lkR2prK3QYRG7Oo+uLLz
lLhkq5gEaXeMomiYStgRk0YUygEIIjvRA9FNSipFLRfb6jMgm9UiSmjhWDQX
n+a4A6mlHGnQjqp7PAPD16sLgEkZ0m+hVg+ylpyBdpHbpMReXpqtb2ufY1II
m6oEKizneIvdlVLI/oRlje+HE/ZWY0ohhbFdGhGdiq0zdBmb1pYidKYqCIRF
/at6TZxI/btB4radR6ZRpz9GzhSr0pw0pMsmOGkiGKpctvaOHTqmWprCNmvb
9J2/XrIS4cwS0yAFwdQt4fpZ2ENnlv9mB+s0z6IKDZ1e7wbnK/amfqLY5Oel
6sXwqs+E5WdCEUcFIg87uxbl4VCvU+Q1xj70yyG8bL43n0V2/gdjNs2e+eN3
KIj8PKDP/s7s85GfU2ozpepTdVDMa3bvbcF72JxooGL33xkKnHdPbLc/ceie
2IEnlujOcU/UQ//g4S+PCRV1saIIttqZ+kV8VonnFzexMxSXtsBBSJs9+O/1
epujAFx75pANUa4YAr5dL4dA5j5NJQc5+eR84pdub6mLAPibUr0fLi4zY7Jr
2TMzEK24kdgko2bxhYEwvLahNL2W0nfxj5nNf46uC7iawyU64v3hAKm3Rnyu
tHd8dlVCfVcGnnT/gVWxyZiEmPOYuujBKFcUbVa6TEP6Yt8vqmQvZctQwYp0
LPfhvg3x2ea97H91L7Vae19bwDfs5avwefSmdkaNa8X7S+YSPCBuNx49mfnp
jljrkS3GsMxfa3qcTXX3zJu0PhL7uVARNqv45GhcjUm46yYGbZ2GFOyXuxsb
mzjLy93d7V0R7Ulqn0khF9CME1vMR7hsZ30PoNa1qtCfn8EHv9AHX0g773wZ
WHSzFkhPo+qLJepSoqq02dMGXiZuUDrCFpQQQtNZnWQ9yMbtU31Ty34br3ru
GCmRRWUnSXQBKbHIo+nN3mrPJlEtQoVZbOO/uYYbkTKNlxs4OufCiFxzGC7H
3SwBwyV0+laRDGN1oqpmyt7qdxgjm2VEpjd5MrX2Ay0i01GNo3ZqtlqP+DH8
4jYgBWa+/EetZpQ2s+KJz/kCic//ndQcZ3XxsDZyoKu7fXWhRlI2Y66p3RI7
TxMrsOPJx1OW13DEWQKwK21EOKWCT7ggTVAzyFaTUMOo/WbQLlVLqnOQ/V2T
qQd130lYUYX4neoCXTsPTctcMdmvm/xd+O93YU3l73oPFPX1cOii3x6O4uwa
oPBgsPmkeXgIsPbhG+ZQ2Qax65SKnLTYLB2SdctxTtrZVWEnvFJcc6aBdysN
kk+LF9N9oHN21OPGeeqs635j3TNG9HuPzV4NHvtG23P4MxqNVj//RNvzN9jm
W+zxAzr8MZ79HzcGm4Otn7/dNv+0rNOH+nIo5zRYz899hc9W/69hm8czeASC
v2xDcP/ir8LpRiGTLPcrlKHzuI3klN2VxYS2o3EFDTGdIcIeS6qKhLi6Sv4t
ajSOiaYJMZRhRPuiIiMu+VCFXwWLYtlvA+tHT2OR4jFUOKKytBhHrcUN2+oU
kVHM9p+gNUj5SetoHokWFMC98Bs4MZGBL8kGb90gedYM62m2z9GIWhykrvRw
JtXGLpnh6/le74/H+0Puhzr5lTriDmHbw8mvC+RMGC524IS6d8uMNf/19z8e
vOu7SRBc5+/Hw63dl1Z1H0/GB+ET4wlovPvHw82Xw5c7w82t17WlIZOMyHLR
DXhpa2dlH5zNs5U0kSvQMSmfY6PfXMnALn9dwNOHJ4FUjOHLH/aP7ffwKVzY
MfxmP91+vQOfbvcxWxT+t7Xx4jRP7ze3N3b9t3a6vv9xgg+0+mRs51YEd8jz
MQnu9cs33OeTxGytV6Qx9H6mAugpiWZS1QR19UvYuboiBr2gbc8DYhMk7VwD
u2LFoitFG9/sata57RruiE2jpUGkQkfAve9sI93MDoE+oAwFSFta3hZv9ZIH
8FVeAKG0eI7SyMGPfF2/AN3+ZY7dLmel7ap2oLmbuIauAjyfn0nJHb7VHjyd
+TKMofQq2UmSKD+iBDPwAD7RJmZz6zAJCK14FF6l4Z0DyZPEqaiaj0TOkpDJ
vjP6tVHtRxQjjjx9rTUKQRy+LiIu61tRM4xZLFmrI8nksSgE2g27pfSTKGXy
zBjLuT73dc3XQ2ck+F8rhkRlf87FJrk92hpt4hseceyT99E58LAyrfjuQMHf
D4NcJafUichd07ozFwU73LUWU+eNugrSokdhvemAF+jp4k0Pyi93MfVwuu/x
xXWqqrN/DgLI2v6J9hvh9R+Pzy8mZ+Z8sn82wU5+KYnj/RUyQ6cgoLVzXeJZ
dw2vEdX+D2qRBXeb39diU949ooL5XKTo82e9Tb+EIV5Ssww2LIY57E8HZCgL
riLdQFdTq0vyGZhK+0i0D3XnSzulIfMtnhrab6VNBX1PHVzRES+enX49MrbF
CwKSj28OZq+ZK00l8X4qrXjMHS8T3ps+LZrFGL1HGquNAGpLK5YYqJZRaXqk
mMk0wWgzLaQXrFEW1axS24DyBqcCfgUn9RDH5/uHhwD/mVeoMThQjLz+8PHo
iBoTJhkxfpQL4Xatg3LvVSib5UuM3/i3Zc7iADuQqr6iDXWp/MqqEMIOGShY
dSi3R1dcJn+26AwYvlhWIffthQQiQuGrUTwruM+DOv14EklAKvtogjA++quT
Az+34C+gCC3Syv+nCv/vUAVEzCfThOHflibQmv46FMFJ5HJlWsQfudAggyv6
UfnXFcXnvJQgWwmb84e0Bp9GknIqUV9Fvq7OFI0Kw7bqPiFMjWpxXVYEdV2a
HFEvI01AjVrkyMFT7iVcLVcs0nWOVk1i/5wznOaX8cwzTYcykyfBGY6X5oVg
vIMX/WRTLb5GJ2wSml4rF+XRkVlla16SfWO50CrvkvXkSoWKDL46N0Fz1B9X
d5s3922eQG+6b3KcdQ321Or537qJTuB9026e+Rzt87Mk6INRZ07sDEO7LVe7
MWjjL0wa3cdFLe1TS+YLSaG249yu1AvtdEVrmuPJjb9N4jtNhfi3ZVKSbQQr
XZTMnykSlnvD2sFsKXBpxINquTQe5hhMcSQiTLwZy0asjlPMnFrGxUk9g4JN
cJ1R8BwIE15vR7sUruvt0rspDYz5c7AE9mby2wNqimEdNdRQT5vl2Rm8t70a
8jG57BXGqBSW9qVa11hNTmUVr60pLLKXI+9kuCCz05ylIpE2qE27H9W59s/2
QUq8iaefAAwDc3wIf8bVdNTnShDkkkRGfe95LLFqxjXlEdcHFSHUh+PAFmWi
b5LskywIRTPbGZc/kjVhX1wKeqDGWzn1u63vXGlg7TTFFupIpG0vZk2h/uJg
0OMkS+bLuTm++Dgy5sjHAI120gJRErcGT1rOvLmxtSF9gnGh12TbL0Z6NaX6
bwZEeYEVJgid+TVtL2xpgriDFJ+p/Zhjp4GRl4K+21yY1Geo7ivVbED15JL1
HRZxrC3AxGddC+BDXoS1J2ynMGLZMdrCwkg0rHHD4KUbXiskJYthZ4p0m7pK
fkXbO8s6sJJdoB8Vhrxpc9ctJ+wFrg/u+EJWNz5LO0Rl3dvVvUQVqyTUgNI8
+pWOnA5xHc+ib0j0Wmfh8+GBI2YMfqzzk7hzQw3vzbos2Foz0zjCtCe2KZpy
EUnyjrYVQXFFFnuvy6QYvzqwNH6eQStUEDEBs4Wd+Ye2c5nm00/Du6QU4gZC
gvSv2n2D2gt2utvjgGhJzeXIdI0oyiiX70rrsvFZjalwj3qYbdsHQI2z8cHh
x3N2frjeMlTWbTbEOwFiT5EAnfRc4swFEcIuitt7Y/x7atpGtwFGOzgcH09Q
QCb+5YYrqY2wiPC1husupp6xIqEeFdqmQQeXTt693kmjD0C5img22wbwfVUJ
2mZ+jABHriNOCdZ7py8PwiRdjLiud3SQIOj2xpwGrmFNB5ZI8u6esgxsDkgO
OhlFZs33Qq45UZ7Uosj1dSB9yGvhFcx1m9SDsZtR4WHaBbVhoE16meQaYxnx
wXHiKNGI2S0WIEKlaJwCHdLulR7jl2J0e2Zt4vNW6nR7l9k+81eUQyk5piAi
JKTXabxR2Mh4baA3xXZ6j6ga9teQwvH7gtBgECy0itJPpRgpNB3HrklXUoLe
D3v5yVZu8qdMSk8USVxXYGJLihT8qMj+qMnOXGptiZH2lBEjN9pLYgQSlqq3
knqNSTvTukBk6yQCRP3hRW9x6QeRz63WRg3h52tr45SLKSV2c5lINiXo0mqT
E/A1wi2EPAKVd3KnZJBCwWxIZVN0M2u1m5gXpqXddeGVZZC211TiRDpfS8WD
UmKlwgHQ+kSAyqcgpfjJsiw8rpF0f+4p/3WJ/Lb0TGHEx3o9R4CIF84X6LJi
T3bWGMA5nKU9nXRrwyij+yq24WF3N3naoEstwe4RJ7oVSakZyVprUJqc8rzq
Iw5XMzCn4w9jcUduviHZg01ZzorltD3ZtGQOeb2GuGcqNteb587f4xZ7owjv
wacDvsB4ub6AAdaTU6o99edJqBsrrI0IOupksAAyvdUqz4NIn+Vpfp3ENQGY
HPFWrTnMLyQ8T7PmpiBOkV6QcLERZuLviOe42biZYCl+awZwOY0zOIBchC7P
EooVQkoy9zD2Yb2HsSuaKlL3pKU2Kn96cXRuNkfbWkz1zcaXL30mSbhrznZM
sFzLbU4YlKcoJNnpLDehArnwPUau5nMJMR1IXVa7nDkWYYtm0UJbawOQ/DXW
67ryp5OD9yf78PHh8GCUxNXVMJ4vKb8H/bJTfIq1GgpBDdxwnloNaneXNTgo
tIeymFdVjBVZzfdUp7Y7d2ogG+ZeUFwISACz4LA6y+zAIKFzHA+e4huLZRl0
s2gUgPCCPvx0tVqZA79yLpmtsjg1l4n0XaVKEFrI9hU2R6WAG+SRriEfgoeq
OpiPvBtOveJD/fys6SpnM4XtN04PlD44fKywLfFiKdhKnJlQi4tFbmziuoLI
h4G5xzBFzkGlgk+uGLPGVANYy+CCArwpvoUYGmlwC2eZa41HUKOrNrcmk/w0
jQovYckGWkh4wNhHB5Bx6thBOhWFfOYV3vrFAhtwkgMahV+Ch2toDMyNaG1g
okPl4U954mokIZvCUKc8YySgaolzxJ9oxlJHLnWDgtVQsobaIkHtv5GIDY0s
Kq6jTJ/VPrha0Qh5a70NKUs7cRbUTGxk55CSisI+sNQicrkiJKMs0vyea0dl
kjicojsHi5oMrCDdnumkG+ms2KHhY81yKXLOgzb4NDvDeIqKdcKliW2Iro+4
YtFM4UTLAiAcJBx5j93gTm3oBVFH9PYMr4UXtKxGJrSE19lZ4PzPx8dHnj7H
KuPrbQye6nE2b4B0Az95oBuumCdGCWex5L6zamQB3V72UxaKTBuPvIhZAOE3
8nTJaGoTZWSs8f7E/PRDyFeFZJzgTRLusLVB3CGa482XiC8dc+DbdcaheKPl
jdxGOUHJsd9JdpsAPSFjDJO8saYfuUzNIrrCfAqch8vo1MQo9d1wojmnJfmt
cAQx/MJNYk+aSuXzw1MjxcqTWwStgIdsbE+M/cECTks9FRqA9HxbVc6Q96uk
9oRmmTn30GGwU006feLsXom3tuI2CgCvkPeqUsQD6/K1JXZtvTlfia6X5GNO
S1X97o0WyuataXy+LbLnsrQsKIg6o6IL9wxLU0gUKxLELgdEor1znSeMYB+V
TciRdqHVCCqpJHfvN2rm/k3avYAdqLbEw73XIxXnYcmtkqhZy1+fEEDml69g
NZ36fBGKDCwiDlmgxrLLet1UM6f8byVMFslxK6goR4TfQHsK6QLPli9vTLJc
ifiKD5AX3LVLqPUfOFVCe0g91g4nk4l5vbE12twdvQGCkcRxDH9u7kpJHLjT
71BQyHB2kaN9lGpLy+ZY5ozi6Gx6iEdnruyAAm0SPjQ2w3IOkkAublxLwMmv
UlKkTT7kBhI0UqOgHy6tsw2D12WOxLlmDKbGe5JVGRls89b5IcUoI7aXaHCw
iWvRAx5vCWfWKHE+S/FtawfdAenu9VqQymZz7FwK+AAEzSav2LoZWMeMCxgy
phA/TbEa9l1MNbE9FdN50TuWyZEY1um0oko3eutEqn4rUrVcg1oxQWvkYkF7
UBfGB34HXq4qIh1KVVZx5n82DvA0lHdasfu8hHWVV/fOl6d+BcFzFcmd9T6w
RblsnPULzgsvpaciAP0QNPl+kOrOUSaevEU+luERDTa2Rl4gkiKRaA1JZqwO
8h1KW89m47cXAQusFGx+s+5PrNfHdBRrWXvG2zLAUthxwqqrmmTXD/Lzvjj6
S3V71mt8JtltnrYUVQ9CBKKM62iDJJ5WyYKKyXGdXH8pWlCsvY7sRj/0lzTK
tjAHuufYG+bQ915cgdL28uk10hor0ptG+Z/YGrjRPNFW5xs02q67xDaXgNgj
nJ2jmw4FEYIwLHxaucIIcBg2+oO5st9Rc0UlX0/nZHJUqTe58rrFAxHM5wFy
uAKDHnkv8ktQpjJLZsrqa4jDZH4WV1ToFjty4CJoUUSdCgr7KdXIW05BqLab
DlTdNrdb4Rpl+G48tW6rxUkkokvgNHfJDC13tqzh08Q4kR7dQKpreaYznVSK
eqpAjVzdGqKOTn8afwCt5wi4HVXVqeyag2NFA/1sOaVTixhBltJj4CuVXzXH
hquwOuSzyZNi3Yo16Lp9v0C6xcip2s1QiTMGdoE4hOOQmQbrepRUv6JRbRZ1
dL0DNS2JqAObeFZBPAG9IK4FQHibf4wEQAwXjQ7JdJlGXvVIWiLWXis1/GHF
eho9LtQeoK5YZ7IIduv3F0i6JKLOtK4bZ7lRZPHXgVr2OSvi9Sgm2krchc5o
KUR21jQS4qdfwigb6964XiazyGtTcohichZXZqxc8gOZ2kvVMWH/68w1i8CC
D38l1AZDovMkcd9j/1Yv6tlwIJJG/YoXuFyONqNgMyxdg1tCmGlPJXUj0nT3
nNqHwYutw61xAU7rEbwGoWPBfkL3huquayMjVdW9rRBdBY1PMqvWzoNkpTMR
8dYGZu2UAutitCfin+dSIg4gN3XK4QRrDFTwHsYnrXHcZceQXpUQVmC0H3Ep
7gaBU4UF19yKh5QzzgHBmFN6RnK9ZKbSf8/8/Z26/bn81Ye9IANzr/Z3+88e
vGeGWFvhJR73cGsX5mvfWz1fFt7b2uGXNiWX1AGzMy2W3yOmtrUt+3sE1Ok9
no4LQZhHrxNzSleDvdFkMMTuDtDbejGAhct5ZkVbi+WIer9nJ93YxiYPzAE1
/1lYO9CZV0WBpEh6R8w10kLchTZIlSuZkvIGMceHI4hLuQwq3kmIavvSvHoB
Hnjk1SGRArYlP8iKHrxtPATbaByy25R/8Jqq7Kctr05qbvsM1rMhs2yCfDfc
fEm/r8iUhG//+MfK9wT8/DMh1KaOo8PgOLU8ynBf7eNsybfbMM7OtoxTy7x8
zDh6ITCWRffVnavZPc6OP87O7opxKKezY5zaxQkw4ytXRhGQGYp2E9k/ODgK
ip4detZdW17u87M0TWbfwkVahvsr8pL/WqzEc10Pk25m8n+Am/i0/enUfeeN
vvdYbrK7wVxhY2PjCVzhoVZZ6IFXxJWE0q5J5VKsBnzjbvh4OVE0X8VVej1G
xFWc5UOEnQuOoss45XoN5oLqO/5XYS+1Hnc+zJgqKH7iRkIg866QZum26NNV
HOdrP6s5UgvLeWj99Nt+uthYUGWPV6kciXZOFTgIHokLNrGeKq9+3IrycZ08
ghITQhApG3t7jy1hOCfpAV0OtlYwLuBxiQ86Zvfkh+Hk23/R5G1Fa7omb/Sk
dgwzKEX4QJkTdurOWmleqbSvzl4nH6JxPYpi1K6dUArirHgrf8IS5j9iCXOq
8Xuml/HzMyyATbXNfaYaUboR7sfVPqcX11zTBdEv18KhQUFzV92xV5+1Nl7Q
9MHLe5vvLjVRhzRpuby6Sn7dM7YLx1BamtNuC+CEcbFnDicX7+CbkMIrfNfL
/p751z/+awj1f/35X3+GV85EpfVLN2KHpRiHq6JqWe6hc2EeZTG2WBKQrrBL
Fw689AQ90A5f7y0p+s0OnTwkmmvWcG3IcO2LLuSe4ViHmif51HWCHp/23anX
Ac62fgY4cYA9c/H2YAR/eVPuuVqi3wBlhJoUQkaaXfoo6NUbboWRq1BcmrW2
GsYOGb0Z1iz0Rj6L8eotfxFA+DWTuaktchVE1j3fJY7bXl5W7jsPH60k4QoW
Agq9GMNXJ9LRvuWrSTbNtaCFZ+HZQ2dLVNzjhF6qXfDEOVVq7swdRmRqPQg8
VDIJUXyEeCLqg/PqTpfqWQtMvd33aOxgJVGvNh3NHeGeYaeNRfwZvPmuiK7J
OOhdh/ZFef6YoNKqMd+Z4+g6mUokKaEivoJfvMMA45ivSZ4FXx1HUyDreXlj
rvAhOl2MRLcPARzgxERewsryqXUKY3lLZALSrP1qWVRcCdMjI9E0/keMBxzl
xbWAnlypSzSGw5U6OT4++UAIxDWhOEAy0+9l02Sp40Nf4z/K5wgKalgFmK5W
wFWnLiRzv04yXSrfPvOO4TtafnBFha0MeWd/8TVtm27ta3zDj4A5m5xfXC3T
IBIGC8mdTfrm1N6zuppU6xXh0vo2t0bbNq+Pm0Ow/OnoSSg8yNrdDX5AmaNT
lGzXj1r0JvmoTaMi/am1grurNDf0lggUfLWg4Z/oL6Hi/H3rCVmEUJ39TNMx
CEDrRfV9H8TR7JO5iIprNDlb7+rvWZTxMEpTOaT0fRtC2WwPupUgehTxqIlL
T13E3wLPAtZZW2gPj8VTTxwftRsc0TMOdTqZKPddDbTjw4yDE9kVjYIJQVL2
WO+mqA02bdQra2MsDkQl1uX761ox4LG67rzasoGwMB2uDfKHp+TiiNMkk2So
O+Q0VOq3KjUZ6wr2h3SUE2fZQWNVT0znQnlP36F+mbZbJj3pyixdU4oNjJjG
v4rnnmQEymuzIT+VCwFcKafvCXhYfQ76wKC0T+lHUjZWCyW7A6K1JQX7YVkt
9yJvsU4+7CwMWXvuio5RqSx6yXo+K/YA3zcWEyFbsUU0vJVM0xi9c6QV2KBY
yfdiWiupp9nMAWKKfesziXvUoEn0UGLqYKwU9KqWYxD7QY68TDkV68pEv/Lh
pJQe6dEcfc+UH8GddCQCFc6trGzWYpjXzikMVjQoNYiOvL0OIuI0veeSFfcI
mMOJDxcXkEhOw6XXDxeDd70yF4WZJyWiigYdeok5DrEw4Ae+RKtkUAxwz1gE
oshp36vrqhR6C2MC4/kyqbrzoki4/7sQQspO0uimENgECZXFsDjxJ65yj8VA
aNAiTgF3UekGaQKjD+kBIqhlzaUYYb5RNKVIFZ47DmXmEemswOzMZTT9RPTO
vEOkwqwO2+Vq/QAzQixZw8PsA0e5ggeH+dXQPjicVSmqFBYR59T7NPGy4LwQ
K3OKBXs8ly9dBELp9YM+zggPSAJRLebkyc0fYOPca4bDwGwx/zBBmr+UyQPv
ddTquw4ijbw0Xkmxarb9enq/L8otkBVdAsX8VErI0WxY5cM4qyUiSao4b6Q2
sRICaVdVawNonlJvuNYL8LElhFv71Lf9YFXaQPx7RCHd9az/s3kIX/Pr6Q7/
QAEfK3oB4s/Lby6r+4RqyIjsba/KOWPq1T735noPdD8Pn6RJ8bZgbZ4nlCQ2
5vd+leSnLBev/y+nsubfy6ffhz9EIkDjKW/gzgffwIJ1gKfXjK79/P1w/dRS
fmI2DLP+8Lctj3+tsjHRq4a576pB/2gi3MOqMsdUSYEpoN9LJsW4o5Kq8Whh
Jzuu3weFL65ggBdBI4zuqcHaTSLo6kh+iu8puE2DWtuKrjW7j8ZWHCQAUSww
RhZynFd145UCC6kqE9sBRkjHC8lQJWyplcyvic1SfkpyABovoOaCsiDbS2wu
gB/ESACBgVWijOgh1WM0L4Xn4fSHS4lyXxRxSwI+NQ7BFlcc+B7rtJ43UOtD
UCQcUmctzqQsTs/H3givSp0mTgkS1HkeMUI0Mp7/WO9IzlbcnZ2XmHzObonb
pExclS+cKV9WyK0vKbmA091J/ijbX8GKogDkG0/M0cXjaFp7g/pecNUYiTBm
gd93LQ+6BpQI7noriPYi3UF3KQ4WpRVxOwoUEQlJ7qLMJmcuOYnIcn/l++8E
0oSxnh4S7KwRmablo7xaWEEhPrz7w0X5iW0ZZgwaQH6dL2kxqmQEhcAwRt4V
ofbcRJ8/tzQ3+dLZfvuv2R8kPKHSq5nd2SGktREIbfav0PhDyht4ZQG5453v
DArwRGIkvReo+PM0zaXTKSY2aOR2GgbC+z2+CHeu/KJFtW5TQfDEOtuHa7UY
MZXvb9ek5P+e0vqYJfVfr7I+UgEkGQMJSGktBx+WWOQykbG7KTYp2CM4YTHG
tQNRZdYCZWePbUf16+bVSG8vQ7/bN8g6zt+PuUD8S/s3F5R/Zf/e3dzSFk6U
ymdJe6kWhoFfy0mZmOBLuLCBLSpTrshuI1t7LVUZ0LdexdCP/iVLEEGo9WtH
E5qpSJQVHleCptQrR1sIu26mDZrbKL64anVeL0wpFkmFRHC9o7Dqux4yl5dX
DvL5meUJlNTATZb5Yd6alOqoN6fChQXNfpQ5XQnOMnMi5sMXwD6tFkciDEkZ
pkJ6hWjlnB1XdeUQdULfvz9a2dAw+LFEERds1/W9BDlosa3O4XqeRajVbgCn
MQQ1A48DY84tSLRGBKVRtZX3dFdxEBoeVJQmJGrI0y2YfhUab2p1ySwyEP7M
4gVKgnkTGUl2IlpVF8mJ65Ebfkrw5/ExDQ53DNNsb0ndFk9I8VvBooOd4t0z
qQR1JanaK+pA18/RbsMrCu3UJA+WUgW6u5OMV+z564WeubpvY5r/3XW+n1qZ
F8tgBAnhVIiKfAKXy0pr29oT1kInUs2lxOxwKe09UBXFExt86VJjxyLj3YIm
cZBWCZK17F0kzV8K1lP53YVd0q3fRc/lpXfSYmrl4BaeCP/3LNNi5W9t2iAu
fdyK/YMT1emBlxfJ+f77IDH/d1jvwkVd7Oe/O+1re5htbkqsKTvemkjVttD7
IPV0MG3GyzlVzNTSO7QRrq+hh9ZsEwfv+8PVq5r+S3L9FuTEw1NYI/x+GceH
pxg7UJiL92fY+MZWh/j8mT+hXnR0Al7rYWBVzCbazZJOVQyLO5eUtGgTlb8p
2at1Pr8RRwPrcTQfJjQCVhXAqfhoimYwB5Ura7yLeK1jx6oxRJ76vwpHMclc
26wEiXXqmwNkwUkjLy/KTz+3NZ7uva43bLUWLNaAhMZFlwNQcHiDcitRXxDR
Z1mmdNsNR33kfnrPgq7SGEi7j3LBudSOIhWCilKRTy7zUqVQTq+4VyqlTVGZ
g3tNn0UGRVehlsE2sMUqguUG+cF87Z6Ifr3eh/jXaqDXjbbjCNayFHuTLYrl
khFdjhxdGa91ABVtvPLTqn5gE1dKfRSXhUvt5TZbnN67R87nLZdFa9bHtPK3
fb+hlpdke6E+P3+zJbGZzbY61fv9rqLTXEWqpErolDHIrMAtxdaekZo5Rg/Y
dZ30dQzOh19g1BlenzlWYif9JspaF+tVuVmH37FgqsZb8ZKphA/ZycY1mTYo
scIeTDRiYU4m3AvO2POKO2OhDM89CQQBVtxlAomm3CahKU5zdaFGcZ/wrJEu
Og0y4hUBthK5d8ZCreHVmSHK+qwt/9JJjVYkb8vZIwjDd7CihmAgpbH/SlbI
1DuRkfjxse208CvBywH3elKkGPDlQL5qV5hzpjpiVlAOyCxAE4wHj3GHiSd8
ZI4Bp/JbjmTXyiqxtCcV+6ga6WzBKjd43aGVcBNUwW8OIdl/XtozoYJWVJos
t0Y9ON63WkHEGiC9iAKyxESkuTkiwpFUaMGAq8GWbXufuENBM7Uf5OpIRARr
6qBKglEF53M/ZOGfAj+wdF9eNSsJ4lGrVQJZ+k0MC0NaGJ6/lHcIJKiR+Qmh
cxtR33AHJK9MICj5jZIXrSMD3tCXWrLDNlwLK/E1CvFhCcFGBUEQ4bhK26uX
O0HFvq8W7JM6j5HIqlQXMBRO7THZooi+KTwoT7bIsZZ5TKW69el6wcVnlkWa
zT1PeQXUGu9PiEHCvwM1kk+lPgy3Tw2zkxDs1o5O1tcQl7TmDr8qmCIxcqpJ
elPsP2aKGn569aJrFZS8gduo0YSLUlmjilyZRo0Ybm78LRzclsx1t6eDmGsr
yKAm17lynfM+7gFrgll+NkzzqbRUYSkhss6qu4jMhSA0i4sCDbBtkJXBhHg3
IMmln0jbJOBoqAJ28mkRBDhWVQkZ92kj1xIJVU25tQWdYDMWqmNHMf1RA9po
3updZdmNQ8civvmmhGenN31JGkLqHHFJYfZgoWDNDewwOhfAX4CeQqQf84yO
4up5KRVAwjnH1htwlRRYP5y5hbdwW6r/PsY6YVRvmkvZ1I7d0XReZMYyi9uu
8AJulOS9a7+w7iZiMgMxBzKLb45T3YTVxXOL/G0GR4GUNYmvLkgWyc0Ra0ft
wuxbs5LCkPh2WGmIuz16gHw0ByZdfWTOsWrp6gJ+xDYvY9e9UI2H6LB2NZkE
/cWb1l6BcXyOlbjj1PLVoGWAFbodFc60g5RoFK7bZBkl9SqH3mBIsw8bNExR
wr3C7ZaobHuAj67RZUZh2UHpjC6M5OL+CFBMPGoUz/BLa9kiuaV5DcRmWZC3
xVZqauxWkan9lBBOfhEN8qNxphTckkOvkNwcy0bBWt46ZUsFUfuMXvfgugiz
1wqkKy+mLb3EKVZ63W2x7TqxwkroetuZRsmlpij+sm0y1kQDgIjPqCx9Wkfm
g0vuSpCmoQXJh2AlgmFUOdOD0EksoobU8lOMgZKdh2AbpPA1pT0zWftwcmE7
kLSrlKZe8adyQ0i5n9VKvMsGRY5nmzfY+8hBAzjmssBURL8WpjsueKKYtRBn
RK8maF3jNU94YQ7m4MqwV99420EmTVRR1YanFCJQgIwcaUAPAkTQwy8UVQuK
4xL29SVeJ9h2Aw58zKGYFWo5lBX4l5/DSP0SzXKPNe5Xu12+SdFXKb/CAE+c
39OJJM04l5qyhFtBWSjtrrXrETXBrEa1PqfAYjxsi/4aYfcmLhSNkzTkQx/w
FF4rT4l3mbkBxfsmRT18gChedk2NbLLWun9Roy1zSw2+AdeLwg3Ul1iT+rf2
zDGWYhuqRQWPr1mJuOz1xqrprY/7rnYeg3IKBBl0D1VwyUIY2QQY8ynhRkAO
XZUIgf7Ut+KhuE8tkizno9ghBd0dGLlwQpUTqARb2QjHYfq4EEZMDMHlQ6XS
/S3ib11veCd0hR0IIrmWKywXz93sYsOBLSyLrEXykk40tUrP63Ll4XjxW14k
GUNcnUPGbb/Ucl0axqdukFE/XrRT4HMIu5NSOo2fIiLbw2/nml5PMDFKWknJ
5cEUeWr9Ss0xpCRZyy0Lyk6HgAyQe3sPa3pep3atHdgNyI2b/ZglVMYfiy7C
AMtSgoXKmBQG8y4CiQcbLi0TqrMu4fxY9g/FQZStsL7eFARTXCfq3VYHRzNc
GnGhLDakNcw6iBjnIyyu7M3go7jIMbIXbZ+Gl6TPr1UU3uAtr4it1a5j6/Ai
0TnvbtOTPmex4G6b2Zqa1Wjhy10yanDX9BK0Wv+4TKUDsa3l6G/l0ou4VE3X
imje8e+0HT9S3zYMwK4q4iybslinpXlbHh+s2AVxRaoVYzVzi+Cl2HkRb6x9
rqlSqEhX0xf8o/SrKMvuiDyk96NWBZ/Lf1o+Y8/ZJWgS+EkkUr3Ict6kIWkL
FzkheKn/ocTPnoU+YO3XIUJPjfh8dhUI5MEhPziUXPsv7FIVGsHknOOJ6y6b
pCH01+bCEqfMrPxAWOvMvCBJucwHPuLyhGRkvQwGRO8BnKENrq1L7KtmcknF
KMdYTda5/1zWUtMU26gW2FUGNvJTUX0y7iKw60UrSOLw3H96dnDfVpRtpP4R
gbE5aRiOGdd8EzS1RQB8laTwgS1iqJJFUK5VjbSuWKfqBZpUTvIOFW5uk15c
BAiVl5WS3HNf8PEaylgvDAecXIF8jiz67qZm7nPNGTyeRpekXtmSqThLJuLD
G4R2Xd9yWzrVxbNb6hFYB7wm4JBr7S7nK7hnNrmBdYYxIlZS4pjAjHtMSkb5
35mt+qNtjym5Z78tiSDaqZL+vU7zy8imqfd57Wp/Fw+dd6VQpEdGKGl8IHgf
ntoT8b0BtXqlesmDSzhwMqbfAY1QsF4xgwpn5nyHOG7ZmjFdypZXhPjSDw97
qrX3nX/QtQLsO553Qoq3H59i5Jm94m55sxkTAwugMLtgVV13Uj7QDCRXkdop
uOxCPQ9KgtZg0cj3zvtIAKf6Ux39fZkdJ5jNk6pyNtTY4Sn2cCPPTRlHBYrl
TLtFoOQIVbwILOrZ05AqwgOKku8qwur60NDBO2nZr9ivDQK4N8BI6llgNx+0
Bd8PJfmXjAZebX5xEz4x18RbR9DGoLAitNL3iBdEnscbDNvkgmoR4uGNA5+7
Q83JrEeMLxX1gKS0T3R73eQLT3rTpYeZf7IGofvJgqNc/fSFxDXnViKtRYqL
OJrdr4yRcGKja/XqaUQWUGKesgXgu1UtghasZ0myjdaVwfQjFSFoQ9JFbVnW
NGwOKC6bZsGuKmEdgsmX1eIGsHn0RVMeMjVUS0hUkoB+Rlpuf9Flqxg8ApHW
pdmFOl/1RNSc6d1C0DDlS7LH1w3uQS7low4mWCwr8SQ9chUqbUfghZcQAfEt
Q567TW/TqnjkWpbUKgwJTjzQI5mBTbHb9PVS6yo6yUuzkCzQqN2GZbkINLdV
HQUvkXDBgGZ6oQANQxPK416/kjavWA2hOGS/iOf5LfZE6wxEnwFDnDELo4fj
UKhzF0Hpgu5Nts6knb0ZHoWnpr8Wj+0oeUsXDAKO0mVKlsAw98nR5GJCSEaH
TQYwaradYljegmvcKHOqqQ1S4ryUHXkII1yMCBTAFsWsuKhpzU7GJ3KA+iUP
6FWXrosZMtGKzllwGkhw5UD8fhxIkbTWP7J3ZwerxZz6Oh7b6CsmtC2rH5gw
fFcXyO8PvNozEWakYTAtaZPUtkOCR8OAUS9SFI+RQzIBg/3oTHbL6waoVhDn
8CSl7z4VuYp6kTw2OM9Pv/5O8nS/0+hr/cB90vLzXZjk+10PM2zxpLxM2wcO
alide4vf8Xv8Jw3EyeCaY/zbB+pLBjd1RdYxPBQgyUO4NV5I69b4q5Vbe8QP
U88XGAW9+gXYwrot9jV2NLYPe/hq3nDAZhsJxMo4HG1blTf8AzstEPeFKZD1
wTp3VpoPRNfUZhMq6EozTQyHIVrltyetRzB5AeG1qYTP4xONoCV/RNvHIT+z
bALNcVw3i2WJNPfS4uyEcE+r5Yw7s3BDByxTzH1Eg9IuCAhqE+GpVcj8SCKI
udoI/AvarNea2RIdtmaJu4TILEVJ3xugCPs2C1uyaF9v7cAKNY2C7J7XFFnS
tOwo2Ot93g5tcM8SO4nM88yR9ZrRu005tCq1a+RYMIWsmytqJsEuXRopWBHD
ilkT0+ZGSl5r9pMWpBNMkCCoWksdcfChTNa0N8kAbmV2L04ZdfGo4uLoDFWq
mQ8aXbGzGN/DldT5TCNywolzQWiOFalcNhU8V7BXl2xdxF+sWau5Mdb+d3+o
rdVWdFkUgOWFmH+6IOcso58/X5xvbm+Pdjc4nQFDusdTLBCaxjOq4VciWeIi
fPHs+7UsR7LyUyz6Zpp8ktYUEUraxDaxUJRN+WWX5qc9cxqBxPUTMK4YQxbe
x8mnT4n5PawHbzyA/ndYtO89zltVWNn4Ei5Dnsagu03SBHD9iCoVjVO4OQfx
jzmw6/2oKEF6Mm/RaZzBEMf5DehN5zHMOjBv4+xPEVx682M0W+LTNwXWDUIf
wLxcogHvd/lNZo6jqiopQfuHHOAPb8MMs5imAuhmIGia07iCWz1dDuC3WZGT
1Jnlw3OgcDfxnznaZraMilkOxOE6jUv9auRBSprk+OD6IbosEkCRI+Dgfx4e
A7pFLk2fLaMMzQ63/V37KRzewjC/wwpdMKouMhwWsBor61wNqbHMoqqVUbLz
AUpFAKgltsc1H5JPKdyq8+lNMp/H6eIqBg3k2o7cNgQQk+IyWc6lzg5mJCkh
Cp7m/RwAUQFwHMPC4Qj+DCeS/TlKvcWf3gPNz2rvjgxm4cxk8/JoUlASKpm5
pDchXSg5VLgopyAD3tK0R9GSrtgFICep0V6DIZ15kVfiV8WoL202Xdbi+y8U
3c1d5Oe2JxzPg0T0B7zk5vTwYGtja2O4ubn18tXu2dvh/s4OJvvOmNIe7x9+
eDGeHL7Y3Bhtbm9sv3kB93NzA37gv9vbZv3kw8m7s8lwe/jx+KO6d+0UuN73
OLyZfMSTpnxzAP1+Ed2hG4JNqUR0kSa9evXm9e7WiOs0XaXLq6ve/wI0RsX0
YR4BAA==
<!-- [rfced] Please review the "Inclusive Language" portion of
the online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed. Updates of this nature
typically result in more precise language, which is helpful for
readers.
For example, please consider whether the following should be updated:
Master Session Key, Master Secret, Master Salt, Master Key -->
<!-- [rfced] Please let us know if any changes are needed for the
following:
a) The following terms were used inconsistently in this document.
We chose to use the latter forms. Please let us know any objections.
AAA Server / AAA server (per post-6000 published RFCs)
Client registration (in running text) /
client registration (per RFC 9200)
b) The following terms appear to be used inconsistently in this
document. Please let us know which form is preferred.
"a/eap/1" (the URI for the first resource would be "a/eap/1") /
'/a/eap/1'
CBOR Object / CBOR object
DTLS PSK / DTLS_PSK
EAP Failure / EAP failure
(will send an EAP Failure, sends an EAP failure)
EAP-Request/Identity / EAP Req/Id / EAP-Req/Id
EAP response / EAP Response (used generally in text, e.g.,
"an EAP response", "an EAP Response")
(We also see "EAP Response header" in Section 7.1.)
EAP-Response/Identity / EAP Resp/Id / EAP Response/Id
EAP-X-Req (text) / EAP-X Req (Figure 3)
EAP-X-Resp (text) / EAP-X Resp (Figures 3 and 9)
Network Key / network key
Option(s) / option(s) (e.g., "Location-Path Option",
"Location-Path and/or Location-Query Options",
"Location-Path or Location-Query options",
"Location-Path (and/or Location-Query) Options",
"Location-Path (and/or Location-Query) options")
OSCORE Security Context / OSCORE security context
Session-Lifetime / Session-lifetime / Session Lifetime /
session lifetime (in running text)
(Figure 3 and Table 4 use "Session-Lifetime".)
c) Should quoting and spacing be made consistent? For example:
Quoting: '2.01 Created' / "2.01 Created"
Spacing: Payload(EAP-X Resp) / Payload (EAP-X Resp)
d) Should spacing after step numbers in figures be made
consistent? For example:
...
0)| No-Response |
... (Figure 3)
...
0) | No-Response |
... (Figure 5) -->
</rfc> </rfc>
 End of changes. 172 change blocks. 
2324 lines changed or deleted 2176 lines changed or added

This html diff was produced by rfcdiff 1.48.