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

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.23 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ace-wg-coap-eap-15" number="9820" updates="" obsoletes="" category="std" consensus="true" submissionType="IETF" tocDepth="3" tocInclude="true" sortRefs="true" symRefs="true" version="3"> version="3" xml:lang="en">

<!-- [rfced] *AD, text was added to the Acknowledgements section after the
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
-->

<!-- xml2rfc v2v3 conversion 3.27.0 [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) for Use with the Constrained
  Application Protocol (CoAP)
-->

  <front>
    <title abbrev="CoAP-EAP">EAP-based Authentication abbrev="CoAP-EAP">Authentication Service Based on the Extensible Authentication Protocol (EAP) for CoAP</title> Use with the Constrained Application Protocol (CoAP)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ace-wg-coap-eap-15"/> name="RFC" value="9820"/>
    <author initials="R." surname="Marin-Lopez" fullname="Rafa Marin-Lopez">
      <organization abbrev="University of Murcia">University of Murcia</organization>
      <address>
        <postal>
          <street>Campus de Espinardo S/N, Faculty of Computer Science</street>
          <city>Murcia</city>
          <region/>
          <code>30100</code>
          <country>Spain</country>
        </postal>
        <email>rafa@um.es</email>
      </address>
    </author>
    <author initials="D." surname="Garcia-Carrillo" fullname="Dan Garcia-Carrillo">
      <organization abbrev="University of Oviedo">University of Oviedo</organization>
      <address>
        <postal>
          <street>Calle Luis Ortiz Berrocal S/N, Edificio Polivalente</street>
          <city>Gijon</city>
          <region>Asturias</region>
          <code>33203</code>
          <country>Spain</country>
        </postal>
        <email>garciadan@uniovi.es</email>
      </address>
    </author>
    <date year="2025" month="February" day="19"/> month="July"/>
    <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>
      <?line 154?>
<t>This document specifies an authentication service that uses the Extensible Authentication Protocol (EAP) transported employing Constrained Application Protocol (CoAP) messages. As such, it defines an EAP lower layer based on CoAP called CoAP-EAP. "CoAP-EAP". One of the main goals is to authenticate a CoAP-enabled IoT 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 Constrained RESTful Environments (OSCORE), enabling the establishment of a security association between them.</t> them.

<!-- [rfced] Abstract:  We had trouble following the meaning of
"transported" in this sentence.  If the suggested text is not
correct, please provide clarifying text.

Original:
 This document specifies an authentication service that uses the
 Extensible Authentication Protocol (EAP) transported employing
 Constrained Application Protocol (CoAP) messages.

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>
  </front>
  <middle>
    <?line 159?>

<section anchor="introduction">
      <name>Introduction</name>

<!-- [rfced] We found quite a few undefined abbreviations in this
document.  For ease of the reader, we expanded as many of them as we
could find.  Most were straightforward (e.g., SAML per RFC 7833,
PANA per RFC 5191), but please confirm that our expansions for MIC
(currently "Message Integrity Check") and LoRa (currently "Long
Range") are correct.

Original:
 EAP relies on lower layer error
 detection (e.g., CRC, checksum, MIC, etc.).
...
 Given that EAP is also used for network access authentication, this
 service can be adapted to other technologies.  For instance, to
 provide network access control to very constrained technologies
 (e.g., LoRa network).

Currently (fixed the incomplete sentence in the "LoRa" text):
 EAP relies on lower-layer error
 detection (e.g., CRC, checksum, Message Integrity Check (MIC),
 etc.).
...
 Given that EAP is also used for network access authentication, this
 service can be adapted to other technologies - for instance, to
 provide network access control to very constrained technologies
 (e.g., Long Range (LoRa) networks). -->

      <t>This document specifies an authentication service (application) that uses the Extensible Authentication Protocol (EAP) <xref target="RFC3748"/> and is built on top of the Constrained Application Protocol (CoAP)<xref target="RFC7252"/> (CoAP) <xref target="RFC7252"/>; it is called CoAP-EAP. "CoAP-EAP". CoAP-EAP is an application that allows authenticating two CoAP endpoints by using EAP and establishing an Object Security for Constrained RESTful Environments (OSCORE) security association between them.
More specifically, this document specifies how CoAP can be used as a constrained, link-layer independent, link-layer-independent, reliable EAP lower layer <xref target="RFC3748"/> to transport EAP messages between a CoAP server (acting as an EAP peer) and a CoAP client (acting as an EAP authenticator) using CoAP messages. The CoAP client has the option of contacting a backend AAA Authentication, Authorization, and Accounting (AAA) infrastructure to complete the EAP negotiation, as described in the EAP specification <xref target="RFC3748"/>.</t>
      <t>The
      <t>In the case of this specification, the EAP methods that can be transported with CoAP-EAP <bcp14>MUST</bcp14> export cryptographic material <xref target="RFC5247"/> for this specification. target="RFC5247"/>. Examples of such methods are EAP-GPSK the EAP Generalized Pre-Shared Key (EAP-GPSK) <xref target="RFC5433"/>, EAP-SIM the EAP Method for Global System for Mobile Communications (GSM)
Subscriber Identity Modules (EAP-SIM) <xref target="RFC4186"/>, EAP-AKA' the EAP Method for 3rd Generation Authentication and Key Agreement (EAP-AKA') <xref target="RFC5448"/>,
EAP-TLS 1.3 <xref 1.3 <xref target="RFC9190"/>, EAP-EDHOC EAP with Ephemeral Diffie-Hellman over
CBOR Object Signing and Encryption (EAP-EDHOC) <xref target="I-D.ietf-emu-eap-edhoc"/>, etc. ("CBOR" stands for "Concise Binary Object Representation".) In general, any EAP method
designed in EMU the EAP Method Update (EMU) Working Group that exports the Master Session Key (MSK) can be used with CoAP-EAP. The Master Session Key (MSK) MSK is used as the basis for further cryptographic derivations. This way, CoAP messages are protected after authentication. After CoAP-EAP's the CoAP-EAP operation, an OSCORE security association is established between the endpoints of the service. Using the keying material from the authentication, other security associations could be generated. <xref target="flow-of-operation-dtls"/> shows how to establish a (D)TLS security association using the keying material from the EAP authentication.</t>
      <t>One of the main applications of CoAP-EAP is involves Internet of Things (IoT) 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 domain that is managed by a Controller. The In these cases, the IoT device is in these cases the EAP peer and the Controller, Controller is the entity steering the authentication, authentication (i.e., the EAP authenticator. From authenticator); from now on, the IoT device is will be referred to as the EAP peer and the Controller will be referred to as the EAP authenticator. In these cases, EAP methods with fewer exchanges, shorter messages, and cryptographic algorithms suitable for constrained devices are preferable. The benefits of the EAP framework in IoT networks are highlighted in <xref target="EAP-framework-IoT"/>.</t> target="EAP-Framework-IoT"/>.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
       <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
       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="RFC5247"/> target="RFC5247"/>, and OSCORE <xref target="RFC8613"/>.</t>
      </section>
    </section>
    <section anchor="general-architecture">
      <name>General Architecture</name>
      <t><xref target="arch"/> illustrates the architecture defined in this document.  In this architecture, the Extensible Authentication Protocol (EAP) EAP peer will act as a CoAP server for this service,
service and the domain EAP authenticator will act as a CoAP client. 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.

<!-- [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.</t> 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> interact with a backend AAA infrastructure when EAP pass-through mode is used, which will place the EAP server in the AAA server that contains the information required to authenticate the EAP peer.</t>
      <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 state machine that can run any EAP method. For In the case of this specification, the EAP method <bcp14>MUST</bcp14> support key derivation and export, export as specified in <xref target="RFC5247"/>, a Master Session Key (MSK) target="RFC5247"/>: an MSK of at least 64 octets, octets and an Extended Master Session Key (EMSK) of at least 64 octets. CoAP-EAP also relies on CoAP reliability mechanisms in CoAP to transport EAP: CoAP over UDP with Confirmable messages (<xref target="RFC7252"/>) <xref target="RFC7252"/> or CoAP over TCP, TLS, or WebSockets <xref target="RFC8323"/>.</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">
        <name>CoAP-EAP Architecture</name>
        <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">
              <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 152,32 L 152,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 472,32 L 472,80" fill="none" stroke="black"/>
              <path d="M 8,32 L 80,32" fill="none" stroke="black"/>
              <path d="M 152,32 L 272,32" fill="none" stroke="black"/>
              <path d="M 384,32 L 472,32" fill="none" stroke="black"/>
              <path d="M 88,64 L 144,64" fill="none" stroke="black"/>
              <path d="M 280,64 L 376,64" fill="none" stroke="black"/>
              <path d="M 8,80 L 80,80" fill="none" stroke="black"/>
              <path d="M 152,80 L 272,80" fill="none" stroke="black"/>
              <path d="M 384,80 L 472,80" fill="none" stroke="black"/>
              <path d="M 8,112 L 48,112" fill="none" stroke="black"/>
              <path d="M 232,112 L 272,112" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="384,64 372,58.4 372,69.6" fill="black" transform="rotate(0,376,64)"/>
              <polygon class="arrowhead" points="288,64 276,58.4 276,69.6" fill="black" transform="rotate(180,280,64)"/>
              <polygon class="arrowhead" points="280,112 268,106.4 268,117.6" fill="black" transform="rotate(0,272,112)"/>
              <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="black" transform="rotate(180,88,64)"/>
              <polygon class="arrowhead" points="16,112 4,106.4 4,117.6" fill="black" transform="rotate(180,8,112)"/>
              <g class="text">
                <text x="40" y="52">EAP</text>
                <text x="192" y="52">EAP</text>
                <text x="428" y="52">AAA/</text>
                <text x="44" y="68">peer</text>
                <text x="216" y="68">authenticator</text>
                <text x="400" y="68">EAP</text>
                <text x="444" y="68">Server</text> y="68">server</text>
                <text x="116" y="84">CoAP</text>
                <text x="328" y="84">AAA</text>
                <text x="332" y="100">(Optional)</text> y="100">(optional)</text>
                <text x="72" y="116">SCOPE</text>
                <text x="108" y="116">OF</text>
                <text x="140" y="116">THIS</text>
                <text x="196" y="116">DOCUMENT</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center"><![CDATA[
  +--------+        +--------------+             +----------+
  |  EAP   |        |   EAP        |             |   AAA/   |
  |  peer  |<------>| authenticator|<----------->|EAP Server| server|
  +--------+  CoAP  +--------------+     AAA     +----------+
                                      (Optional)
                                      (optional)
  <----(SCOPE OF THIS DOCUMENT)---->
]]></artwork>
        </artset>
      </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">
        <name>CoAP-EAP Stack</name>
        <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">
              <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 8,32 L 264,32" 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 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,160 L 264,160" 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)"/>
              <g class="text">
                <text x="64" y="52">EAP</text>
                <text x="104" y="52">State</text>
                <text x="160" y="52">Machine</text>
                <text x="120" y="84">Application(CoAP-EAP)</text> y="84">Application (CoAP-EAP)</text>
                <text x="324" y="84">This</text>
                <text x="380" y="84">Document</text>
                <text x="128" y="116">Request/Responses/Signaling</text> y="116">Request / Responses / Signaling</text>
                <text x="288" y="116">RFC</text>
                <text x="324" y="116">7252</text>
                <text x="352" y="116">/</text>
                <text x="376" y="116">RFC</text>
                <text x="412" y="116">8323</text>
                <text x="48" y="148">Message</text>
                <text x="88" y="148">/</text>
                <text x="128" y="148">Message</text>
                <text x="192" y="148">Framing</text>
                <text x="288" y="148">RFC</text>
                <text x="324" y="148">7252</text>
                <text x="352" y="148">/</text>
                <text x="376" y="148">RFC</text>
                <text x="412" y="148">8323</text>
                <text x="52" y="180">Unreliable</text>
                <text x="104" y="180">/</text>
                <text x="148" y="180">Reliable</text>
                <text x="224" y="180">Transport</text>
                <text x="288" y="180">RFC</text>
                <text x="324" y="180">7252</text>
                <text x="352" y="180">/</text>
                <text x="376" y="180">RFC</text>
                <text x="412" y="180">8323</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center"><![CDATA[
  +-------------------------------+
  +---------------------------------+
  |       EAP State Machine         |
  +-------------------------------+
  +---------------------------------+
  |   Application(CoAP-EAP)     Application (CoAP-EAP)      | <-- This Document
  +-------------------------------+
  +---------------------------------+
  | Request/Responses/Signaling Request / Responses / Signaling | RFC 7252 / RFC 8323
  +-------------------------------+
  +---------------------------------+
  |   Message / Message Framing     | RFC 7252 / RFC 8323
  +-------------------------------+
  |Unreliable
  +---------------------------------+
  | Unreliable / Reliable Transport| Transport | RFC 7252 / RFC 8323
  +-------------------------------+
  +---------------------------------+
]]></artwork>
        </artset>
      </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 anchor="sec_coap-eap-operation">
      <name>CoAP-EAP Operation</name>
      <t>Because CoAP-EAP uses reliable delivery as defined in CoAP (<xref target="RFC7252"/>, <xref target="RFC8323"/>), target="RFC7252"/> <xref target="RFC8323"/>, EAP retransmission time is set to an infinite value, as mentioned in <xref target="RFC3748"/>. To keep the maintain ordering guarantee, guarantees, CoAP-EAP uses Hypermedia as the Engine of Application State (HATEOAS). Each 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 authentication.</t>
      <t>One of the benefits of using EAP is that we can choose from a large variety of authentication methods.</t>
      <t>In CoAP-EAP, the EAP peer will only have one authentication session with a specific EAP authenticator, and it will not process any other EAP authentication in parallel (with the same EAP authenticator). That is, a single ongoing EAP authentication is permitted for the same EAP peer and the same EAP authenticator. It may be worth noting that the EAP authenticator may have parallel EAP sessions with multiple EAP peers.</t>

      <t>To access the authentication service, this document defines the well-known URI "coap-eap" (to be assigned by IANA). (see <xref target="wellknown"/>).  The /.well-known/coap-eap URI is used with "coap", "coap+tcp" "coap+tcp", or "coap+ws".</t>
      <section anchor="discovery-section">
        <name>Discovery</name>
        <t>Before the CoAP-EAP exchange takes place, the EAP peer needs to discover the EAP authenticator or the entity that will enable the CoAP-EAP exchange (e.g., an intermediary proxy). The discovery process is out of 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" for the trigger message (see <xref target="flow-of-operation"/>, Step 0). The CoAP-EAP service can be discovered by asking directly about the services offered. This information can also be available in the resource directory <xref target="RFC9176"/>.</t>
        <t>Implementation Notes: notes: There are different methods to discover for discovering the IPv6 address of the EAP authenticator or intermediary entity. 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.

<!-- [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.</t> 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 anchor="flow-of-operation">
        <name>Flow of operation Operation (OSCORE establishment)</name> Establishment)</name>
        <t><xref target="figure1"/> target="figure3"/> shows the general flow of operation for CoAP-EAP to authenticate using EAP and establish an OSCORE security context. The flow does not show a specific EAP method. Instead, the chosen EAP method is represented 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 media type application/coap-eap, "application/coap-eap". See <xref target="mediatypes"/>.</t>
        <t>The steps for this flow of the operation are as follows:</t>

        <ul spacing="normal">
          <li>
            <t>Step
          <li><t>Step 0. The EAP peer <bcp14>MUST</bcp14> start the CoAP-EAP
          process by sending a "POST /.well-known/coap-eap" request (trigger
          message). This message carries the 'No-Response'  <xref target="RFC7967"/> CoAP option <xref
          target="RFC7967"/> to avoid waiting 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 acts as a CoAP client. The message
          also includes a URI in the payload of the message to indicate the
          resource where the EAP authenticator <bcp14>MUST</bcp14> send the
          next message. The name of the resource is selected by the CoAP server.</t>
          </li>
          server.</t></li>
	</ul>
          <t>Implementation notes: When generating the URI for a resource of during a
          step of the authentication, the resource could have the following
          format as an example "path/eap/counter", where:</t>
          <ul spacing="normal">
          <li>
            <t>"path"
            <li>"path" is some local path on the device to make the path unique.  This could be omitted if desired.</t>
          </li>
          <li>
            <t>"eap" desired.</li>
            <li>"eap" is the name that indicates that the URI is for the EAP peer.
            This has no meaning for the protocol but helps with debugging.</t>
          </li>
          <li>
            <t>"counter' which
            debugging.</li>
            <li>"counter" is an incrementing unique number for every new EAP request.</t>
          </li> request.</li>
          </ul>
        <t>So,

<!-- [rfced] Section 3.2:  Please confirm that the "Implementation
notes" paragraph and bullet list should remain independent of Step 0
(i.e., should not be indented so that it is part of Step 0).  We see
"resource of a step of the authentication" in <xref target="figure1"/> the text, which seems
to indicate that this information applies to all steps and not just
Step 0, but we would still like you to confirm that the current
indentation levels are correct.

Original:
 *  Step 0.  The EAP peer MUST start the CoAP-EAP process by sending a
    "POST /.well-known/coap-eap" request (trigger message).  This
    message carries the 'No-Response' [RFC7967] CoAP option to avoid
    waiting 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 message also includes a URI in the
    payload of the message to indicate the resource where the EAP
    authenticator MUST send the next message.  The name of the
    resource is selected by the CoAP server.

 Implementation notes: When generating the URI for a resource of a
 step of the authentication, the resource could have the following
 format as an example "path/eap/counter", where:

 *  "path" is some local path on the device to make the path unique.
    This could be omitted if desired.

 *  "eap" is the name that indicates the URI is for the EAP peer.
    This has no meaning for the protocol but helps with debugging.

 *  "counter' which is an incrementing unique number for every new EAP
    request.

 So, in Figure 3 for example, the URI for the first resource would be “a/eap/1"</t>
 “a/eap/1"

 *  Step 1. ... -->

          <t>So, per <xref target="figure3"/>, the URI for the first resource would be "a/eap/1".</t>
<ul spacing="normal">
          <li>
            <t>Step
          <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), 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"/>.</t>
          </li>
          <li>
            <t>Step
          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'), '/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) (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 Master Session Key (MSK) 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 step 7.</t>
          </li>
          <li>
            <t>Steps 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="figure1"/>
          target="figure3"/> using the nomenclature (EAP-X-Req "EAP-X-Req" and EAP-X-Resp, respectively). "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 guarantee is 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. In case there is If an
          error occurs while processing a legitimate message, the server will return a (4.00
          "4.00 Bad Request). There is a discussion about error Request". Error handling is discussed in
          <xref target="error-handling"/>.</t>
          </li>
          <li>
            <t>Step 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 Master Session Key (MSK) 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 confirmation, including the EAP
          Success. The EAP authenticator <bcp14>MAY</bcp14> also send a
          Session Lifetime, in seconds, which is represented with 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"/>). <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.</t>
          </li>
          <li>
            <t>Step
          authenticator.</li>
          <li>Step 8. If the EAP authentication and the verification of the
          OSCORE-protected POST in Step 7 is (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.</t>
          </li> endpoints.</li>
        </ul>
        <figure anchor="figure1"> anchor="figure3">
          <name>CoAP-EAP flow Flow of operation Operation with OSCORE</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="592" width="464" viewBox="0 0 464 592" class="diagram" 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 64,56 L 64,304" 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,336 L 400,560" 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 344,48 L 432,48" fill="none" stroke="black"/>
                <path d="M 72,112 L 392,112" fill="none" stroke="black"/>
                <path d="M 72,160 L 392,160" fill="none" stroke="black"/>
                <path d="M 72,208 L 392,208" fill="none" stroke="black"/>
                <path d="M 72,256 L 392,256" fill="none" stroke="black"/>
                <path d="M 72,304 L 392,304" fill="none" stroke="black"/>
                <path d="M 72,368 L 392,368" fill="none" stroke="black"/>
                <path d="M 72,416 L 392,416" fill="none" stroke="black"/>
                <path d="M 72,496 L 392,496" fill="none" stroke="black"/>
                <path d="M 72,560 L 392,560" fill="none" stroke="black"/>
                <polygon class="arrowhead" points="400,560 388,554.4 388,565.6" fill="black" transform="rotate(0,392,560)"/>
                <polygon class="arrowhead" points="400,416 388,410.4 388,421.6" fill="black" transform="rotate(0,392,416)"/>
                <polygon class="arrowhead" points="400,304 388,298.4 388,309.6" fill="black" transform="rotate(0,392,304)"/>
                <polygon class="arrowhead" points="400,208 388,202.4 388,213.6" fill="black" transform="rotate(0,392,208)"/>
                <polygon class="arrowhead" points="400,112 388,106.4 388,117.6" fill="black" transform="rotate(0,392,112)"/>
                <polygon class="arrowhead" points="80,496 68,490.4 68,501.6" fill="black" transform="rotate(180,72,496)"/>
                <polygon class="arrowhead" points="80,368 68,362.4 68,373.6" fill="black" transform="rotate(180,72,368)"/>
                <polygon class="arrowhead" points="80,256 68,250.4 68,261.6" fill="black" transform="rotate(180,72,256)"/>
                <polygon class="arrowhead" points="80,160 68,154.4 68,165.6" fill="black" transform="rotate(180,72,160)"/>
                <g class="text">
                  <text x="48" y="36">EAP</text>
                  <text x="84" y="36">peer</text>
                  <text x="336" y="36">EAP</text>
                  <text x="408" y="36">authenticator</text>
                  <text x="100" y="68">POST</text>
                  <text x="208" y="68">/.well-known/coap-eap</text>
                  <text x="52" y="84">0)</text>
                  <text x="128" y="84">No-Response</text>
                  <text x="160" y="100">Payload("/a/eap/1")</text>
                  <text x="300" y="132">POST</text>
                  <text x="356" y="132">/a/eap/1</text>
                  <text x="176" y="148">Payload(EAP</text>
                  <text x="308" y="148">Req/Id||CS-C||RID-C)</text>
                  <text x="52" y="164">1)</text>
                  <text x="92" y="180">2.01</text>
                  <text x="144" y="180">Created</text>
                  <text x="232" y="180">Location-Path</text>
                  <text x="332" y="180">[/a/eap/2]</text>
                  <text x="120" y="196">Payload(EAP</text>
                  <text x="256" y="196">Resp/Id||CS-I||RID-I)</text>
                  <text x="52" y="212">2)</text>
                  <text x="300" y="228">POST</text>
                  <text x="356" y="228">/a/eap/2</text>
                  <text x="288" y="244">Payload(EAP-X</text>
                  <text x="364" y="244">Req)</text>
                  <text x="52" y="260">3)</text>
                  <text x="92" y="276">2.01</text>
                  <text x="144" y="276">Created</text>
                  <text x="232" y="276">Location-Path</text>
                  <text x="332" y="276">[/a/eap/3]</text>
                  <text x="128" y="292">Payload(EAP-X</text>
                  <text x="208" y="292">Resp)</text>
                  <text x="52" y="308">4)</text>
                  <text x="236" y="324">....</text>
                  <text x="252" y="340">POST</text>
                  <text x="324" y="340">/a/eap/(n-1)</text>
                  <text x="288" y="356">Payload(EAP-X</text>
                  <text x="364" y="356">Req)</text>
                  <text x="52" y="372">5)</text>
                  <text x="92" y="388">2.01</text>
                  <text x="144" y="388">Created</text>
                  <text x="232" y="388">Location-Path</text>
                  <text x="340" y="388">[/a/eap/(n)]</text>
                  <text x="104" y="404">Payload</text>
                  <text x="164" y="404">(EAP-X</text>
                  <text x="216" y="404">Resp)</text>
                  <text x="52" y="420">6)</text>
                  <text x="432" y="436">MSK</text>
                  <text x="284" y="452">POST</text>
                  <text x="348" y="452">/a/eap/(n)</text>
                  <text x="364" y="468">OSCORE</text>
                  <text x="128" y="484">Payload(EAP</text>
                  <text x="288" y="484">Success||*Session-Lifetime)</text>
                  <text x="436" y="484">OSCORE</text>
                  <text x="16" y="500">MSK</text>
                  <text x="52" y="500">7)</text>
                  <text x="432" y="500">CTX</text>
                  <text x="92" y="532">2.04</text>
                  <text x="144" y="532">Changed</text>
                  <text x="28" y="548">OSCORE</text>
                  <text x="100" y="548">OSCORE</text>
                  <text x="16" y="564">CTX</text>
                  <text x="52" y="564">8)</text>
                  <text x="168" y="580">*Session-Lifetime</text>
                  <text x="252" y="580">is</text>
                  <text x="300" y="580">optional</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
    EAP peer                            EAP authenticator
  -------------                           ------------
       |  POST /.well-known/coap-eap             |
     0)|  No-Response                            |
       |  Payload("/a/eap/1")                    |
       |---------------------------------------->|
       |                           POST /a/eap/1 |
       |        Payload(EAP Req/Id||CS-C||RID-C) |
     1)|<----------------------------------------|
       | 2.01 Created Location-Path [/a/eap/2]   |
       | Payload(EAP Resp/Id||CS-I||RID-I)       |
     2)|---------------------------------------->|
       |                           POST /a/eap/2 |
       |                     Payload(EAP-X Req)  |
     3)|<----------------------------------------|
       | 2.01 Created Location-Path [/a/eap/3]   |
       | Payload(EAP-X Resp)                     |
     4)|---------------------------------------->|
                           ....
       |                     POST /a/eap/(n-1)   |
       |                     Payload(EAP-X Req)  |
     5)|<----------------------------------------|
       | 2.01 Created Location-Path [/a/eap/(n)] |
       | Payload (EAP-X Resp)                    |
     6)|---------------------------------------->|
       |                                         |  MSK
       |                         POST /a/eap/(n) |   |
       |                                  OSCORE |   |
       |  Payload(EAP Success||*Session-Lifetime)| OSCORE
MSK  7)|<----------------------------------------|  CTX
 |     |                                         |
 |     | 2.04 Changed                            |
OSCORE | OSCORE                                  |
CTX  8)|---------------------------------------->|
            *Session-Lifetime is optional
]]></artwork>
          </artset>
        </figure>
      </section>
      <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 to 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, allows deriving a new OSCORE security context, increasing the protection against key leakage. The keying material <bcp14>MUST</bcp14> be renewed before the expiration of the Session-Lifetime. By default, the EAP Key Management Framework key management framework <xref target="RFC5247"/> establishes a default value of 8 hours to refresh the keying material. Certain EAP methods such as EAP-NOOB
Nimble Out-of-Band Authentication for EAP (EAP-NOOB) <xref target="RFC9140"/> or EAP-AKA' <xref target="RFC5448"/> provide fast reconnect for quicker re-authentication. The EAP re-authentication protocol Re-authentication Protocol (ERP) <xref target="RFC6696"/> <bcp14>MAY</bcp14> also be used to avoid the repetition of the entire EAP exchange.</t>
        <t>The re-authentication message flow will be the same as the one that shown in <xref target="figure1"/>. target="figure3"/>. Nevertheless, two different CoAP-EAP states will be active during the re-authentication: the current CoAP-EAP state and the new CoAP-EAP state, which will be created once the re-authentication has finished successfully. Once the re-authentication is completed successfully, the current CoAP-EAP state is deleted and replaced by the new CoAP-EAP state. If, If for any reason, reason the re-authentication fails, the current CoAP-EAP state will be available until it expires, or it is will be renewed in another try of re-authentication.</t> during a subsequent re-authentication attempt.</t>
        <t>If the re-authentication fails, it is up to the EAP peer to decide when to start a new re-authentication before the current EAP state expires.</t>
      </section>
      <section anchor="managing_boot_state">
        <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>
        <ul spacing="normal">
          <li>
            <t>A reference to an instance of the EAP (peer or authenticator/server) state machine.</t>
          </li>
          <li>
            <t>The resource for the next message in the negotiation (e.g., '/a/eap/2')</t> '/a/eap/2').</t>
          </li>
          <li>
            <t>The MSK MSK, which is exported when the EAP authentication is successful. CoAP-EAP can access the different variables by via the EAP state machine (i.e., (see <xref target="RFC4137"/>).</t>
          </li>
          <li>
            <t>A reference to the OSCORE context.</t>
          </li>
        </ul>
        <t>Once created, the EAP authenticator <bcp14>MAY</bcp14> choose to delete 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 expiring, as mentioned in <xref target="re-authentication"/>.</t>
        <t>There are situations where the current CoAP-EAP state might need to be removed. For instance, due to its expiration or forced removal, the EAP peer has to be expelled from the security domain. This Such an exchange is illustrated in <xref target="figure4"/>.</t>
        <t>If the EAP authenticator deems it necessary to remove the CoAP-EAP state from the EAP peer before it expires, it can send a DELETE command in a request to the EAP peer, referencing the last CoAP-EAP state resource given by the CoAP server, whose identifier will be the last one received (e.g., '/a/eap/(n)' in <xref target="figure1"/>). target="figure3"/>). This message is protected by the OSCORE security association to prevent forgery. Upon reception of this message, the CoAP server sends a response to the EAP authenticator with the Code code '2.02 Deleted', which is also protected by the OSCORE security association. If a response from the EAP peer does not arrive after EXCHANGE_LIFETIME EXCHANGE_LIFETIME, the EAP authenticator will remove the state.</t>
        <figure anchor="figure4">
          <name>Deleting state</name> State</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="192" width="432" viewBox="0 0 432 192" class="diagram" 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 376,56 L 376,176" 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 64,112 L 368,112" 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="72,112 60,106.4 60,117.6" fill="black" transform="rotate(180,64,112)"/>
                <g class="text">
                  <text x="32" y="36">EAP</text>
                  <text x="68" y="36">peer</text>
                  <text x="304" y="36">EAP</text>
                  <text x="376" y="36">authenticator</text>
                  <text x="252" y="84">DELETE</text>
                  <text x="324" y="84">/a/eap/(n)</text>
                  <text x="340" y="100">OSCORE</text>
                  <text x="84" y="148">2.02</text>
                  <text x="136" y="148">Deleted</text>
                  <text x="92" y="164">OSCORE</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
  EAP peer                          EAP authenticator
-------------                         -------------
      |                                       |
      |                     DELETE /a/eap/(n) |
      |                                OSCORE |
      |<--------------------------------------|
      |                                       |
      | 2.02 Deleted                          |
      | OSCORE                                |
      |-------------------------------------->|
]]></artwork>
          </artset>
        </figure>
      </section>
      <section anchor="error-handling">
        <name>Error handling</name> Handling</name>
        <t>This section elaborates on how different errors are handled: EAP authentication failure (<xref target="eap-authentication-failure"/>), a non-responsive 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.</t> 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">
          <name>EAP authentication failure</name> Authentication Failure</name>
          <t>The EAP authentication may fail in different situations (e.g., wrong credentials). The result is that the EAP authenticator will send an EAP Failure message because of the a failed EAP authentication (Step 7 in <xref target="figure1"/>). target="figure3"/>). In this case, the EAP peer <bcp14>MUST</bcp14> send a response '4.01 Unauthorized' in Step 8. Therefore, Step Steps 7 and Step 8 are not protected in this case because no Master Session Key (MSK) MSK is exported and the OSCORE security context is not yet generated.</t>
          <t>If the EAP authentication fails during the re-authentication and the EAP authenticator sends an EAP failure, the current CoAP-EAP state will be still be usable until it expires.</t>
        </section>
        <section anchor="non-responsive-endpoint">
          <name>Non-responsive endpoint</name>
          <t>If,
          <name>Non-Responsive Endpoint</name>
          <t>If for any reason, reason one of the entities becomes non-responsive, the CoAP-EAP state <bcp14>SHOULD</bcp14> be removed after a stipulated amount of time. The amount of time can be adjusted according to the policies established by the application or use case where CoAP-EAP is used. As a default value, the CoAP EXCHANGE_LIFETIME parameter, as defined in CoAP<xref target="RFC7252"/> CoAP <xref target="RFC7252"/>, will be 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>According to CoAP, EXCHANGE_LIFETIME considers the time it takes until a client stops expecting a response to a request. A timer is reset every time a message is sent.
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.

<!-- [rfced] Section 3.5.2:  We could not follow the meaning of this
run-on sentence.  If the suggested text is not correct, please
provide clarifying text.

Original:
 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.</t> 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 either if either the EXCHANGE_LIFETIME is triggered, triggered or the EAP peer state machine returns an eapFail.</t>
          <t>The EAP authenticator will remove the CoAP-EAP state either if either the EXCHANGE_LIFETIME is triggered, triggered or, when the EAP authenticator is acting operating in pass-through mode (i.e., the EAP authentication is performed against a AAA server), the EAP authenticator state machine returns an aaaTimemout.</t> "aaaTimeout" <xref target="RFC4137"/>.</t>
        </section>
        <section anchor="duplicated-message-with-well-knowncoap-eap">
          <name>Duplicated message Message with /.well-known/coap-eap</name>
          <t>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> 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 during an ongoing authentication with the same EAP peer, the EAP authenticator <bcp14>MUST</bcp14> silently discard this trigger message.</t>
          <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 understand that a new authentication process is requested. 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' Found' in the response (<xref target="figure9"/>).</t> target="figure5"/>).

<!-- [rfced] Section 3.5.3:  The "However, if ..." sentence is
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="figure9"> anchor="figure5">
            <name>/.well-known/coap-eap with no ongoing authentication No Ongoing Authentication from the EAP authenticator</name> Authenticator</name>
            <artset>
              <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="256" width="432" viewBox="0 0 432 256" class="diagram" text-anchor="middle" font-family="monospace" font-size="13px" stroke-linecap="round">
                  <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 8,48 L 80,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 40,160 L 360,160" 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"/>
                  <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="48,160 36,154.4 36,165.6" fill="black" transform="rotate(180,40,160)"/>
                  <g class="text">
                    <text x="16" y="36">EAP</text>
                    <text x="52" y="36">peer</text>
                    <text x="304" y="36">EAP</text>
                    <text x="376" y="36">authenticator</text>
                    <text x="72" y="68">*POST</text>
                    <text x="184" y="68">/.well-known/coap-eap</text>
                    <text x="12" y="84">0)</text>
                    <text x="96" y="84">No-Response</text>
                    <text x="128" y="100">Payload("/a/eap/1")</text>
                    <text x="260" y="132">POST</text>
                    <text x="320" y="132">a/eap/1</text>
                    <text x="176" y="148">Payload</text>
                    <text x="228" y="148">(EAP</text>
                    <text x="264" y="148">Req</text>
                    <text x="320" y="148">Id||CS-C)</text>
                    <text x="12" y="164">1)</text>
                    <text x="60" y="196">4.04</text>
                    <text x="96" y="196">Not</text>
                    <text x="136" y="196">found</text> y="196">Found</text>
                    <text x="196" y="228">*Old</text>
                  </g>
                </svg>
              </artwork>
              <artwork type="ascii-art" align="center"><![CDATA[
 EAP peer                            EAP authenticator
 ----------                              ----------
    |  *POST /.well-known/coap-eap            |
 0) |  No-Response                            |
    |  Payload("/a/eap/1")                    |
    |               ------------------------->|
    |                          POST /a/eap/1  |
    |              Payload (EAP Req/Id||CS-C) |
 1) |<----------------------------------------|
    |                                         |
    | 4.04 Not found Found                          |
    |---------------------------------------->|
                       *Old
]]></artwork>
            </artset>
          </figure>
        </section>
      </section>
      <section anchor="proxy">
        <name>Proxy operation Operation in CoAP-EAP</name>
        <t>The CoAP-EAP operation is intended to be compatible with the use of intermediary entities between the EAP peer and the EAP authenticator when direct communication is not possible. In this context, CoAP proxies can be used as enablers of the CoAP-EAP exchange.</t>
        <t>This specification is limited to using standard CoAP <xref target="RFC7252"/> 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 the integration of CoAP intermediaries in the CoAP-EAP exchange.</t>
        <t>When using proxies in the CoAP-EAP, CoAP-EAP exchange, it should be considered that the exchange contains a role-reversal process at the beginning of the exchange. In the first message, the EAP peer acts as a CoAP client and the EAP authenticator acts as the CoAP server. 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 Message 0, the proxy will act as forward, and as reverse for the rest. Additionally, in the first exchange, the EAP peer, as a CoAP client, sends the URI for the next CoAP message in the payload of a request. This is not the typical behavior, as URIs referring to new services/resources appear in Location-Path and/or Location-Query Options in CoAP responses. Hence, the proxy will have to treat the payload of message 0, Message 0 as if it were a Location-Path Option of a CoAP response.</t> 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 anchor="coap-eap-media-type">
      <name>CoAP-EAP Media type format</name> Type Format</name>
      <t>In the CoAP-EAP exchange, the following format will be used. This is the format is specified by application/coap-eap the "application/coap-eap" media type, see type will be used. See <xref target="mediatypes"/>.</t>
      <t>In CoAP-EAP 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 first message (0) in <xref target="figure1"/>.</t> target="figure3"/>.</t>
      <t>In all the other cases, an EAP message will be followed by the CBOR Object specified in <xref target="cbor-coap-eap"/>. A visual example of the second case can be found in <xref target="figure5"/>.</t> target="figure7"/> (<xref target="crypto-negotiation"/>).</t>
    </section>
    <section anchor="cbor-coap-eap">
      <name>CBOR Objects in CoAP-EAP</name>
      <t>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). There may also be a need to extend the information that has to be exchanged in the future. This section specifies the CBOR <xref target="RFC8949"/> data structure <xref target="RFC8949"/> to exchange information between the EAP peer and the EAP authenticator in the CoAP payload.</t> payload.

<!-- [rfced] Section 5:  We found this sentence confusing, because
the plural "Examples" is used but the text that follows shows an
"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="figure11"/> target="figure6"/> shows the specification of the CBOR Object to exchange information in CoAP-EAP</t> CoAP-EAP.</t>
      <figure anchor="figure11"> anchor="figure6">
        <name>CBOR data structure Data Structure for CoAP-EAP</name>
        <artwork align="center"><![CDATA[
   CoAP-EAP_Info = {
      ?  1 : [+ int],     ; Cipher Suite (CS-C or CS-I)
      ?  2 : bstr,        ; RID-C
      ?  3 : bstr,        ; RID-I
      ?  4 : uint         ; Session-Lifetime
  }
]]></artwork>
      </figure>
      <t>The parameters contain the following information:</t>
      <ol spacing="normal" type="1"><li>
          <t>Cipher spacing="normal">
        <li>Cipher Suite: Is an An array with the list of proposed, or selected, COSE
        CBOR Object Signing and Encryption (COSE) algorithms for OSCORE. If the
field is carried over a request, the meaning is the
        a proposed cipher suite, suite is indicated; if it is carried over a
        response, it corresponds to the agreed-upon cipher suite.</t>
        </li>
        <li>
          <t>RID-I: suite.</li>
        <li>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.</li>
        <li>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.</li>
        <li>Session-Lifetime: The time that the session is valid, in seconds.</li>
      </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.</t>
        </li>
        <li>
          <t>RID-C: 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.</t>
        </li>
        <li>
          <t>Session-Lifetime: Is time Context.

Currently:
 2.  RID-C: The Recipient ID of the session is valid, in seconds.</t>
        </li>
      </ol> 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 specific authorization parameters.</t>
      <t>The indexes from 65001 to 65535 are reserved for experimentation.</t>
    </section>
    <section anchor="key_deriv">
      <name>Cipher suite negotiation Suite Negotiation and key derivation</name> Key Derivation</name>
      <section anchor="crypto-negotiation">
        <name>Cipher suite negotiation</name> Suite Negotiation</name>
        <t>OSCORE runs after the EAP authentication, using the cipher suite selected in the cipher suite negotiation (Steps 1 and 2). To negotiate the cipher suite, CoAP-EAP follows a simple approach: the The EAP authenticator sends a list, in decreasing order of preference, with the identifiers of the supported cipher suites (Step 1). In the response to that message (Step 2), the EAP peer sends its choice.

<!-- [rfced] Section 6.1:  Does "Steps 1 and 2" here refer to
Steps 1 and 2 in Figure 3 or Steps 1 and 2 in Figure 8?
For ease of the reader, we suggest adding a response with citation for the choice.</t>
appropriate figure.

Original:
 OSCORE runs after the EAP authentication, using the cipher suite
 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="figure5"/>. target="figure7"/>. An example of the exchange with for the cipher suite negotiation is shown in <xref target="figure6"/>, target="figure8"/>, where it can be
appreciated the disposition of both the EAP-Request/Identity and EAP-Response/Identity, followed by the CBOR object defined in <xref target="cbor-coap-eap"/>, containing the cipher suite field for the cipher suite negotiation.</t>
        <figure anchor="figure5">
          <name>cipher suites 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> Payload</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="112" width="400" viewBox="0 0 400 112" class="diagram" 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 56,32 L 56,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 272,32 L 272,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 8,32 L 392,32" fill="none" stroke="black"/>
                <path d="M 8,64 L 392,64" fill="none" stroke="black"/>
                <path d="M 264,32 C 272.83064,32 280,39.16936 280,48" fill="none" stroke="black"/>
                <path d="M 288,32 C 279.16936,32 272,39.16936 272,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"/>
                <g class="text">
                  <text x="28" y="52">Code</text>
                  <text x="100" y="52">Identifier</text>
                  <text x="180" y="52">Length</text>
                  <text x="244" y="52">Data</text>
                  <text x="308" y="52">cipher</text>
                  <text x="364" y="52">suites</text>
                  <text x="80" y="84">EAP</text>
                  <text x="124" y="84">Packet</text> y="84">packet</text>
                  <text x="316" y="84">CBOR</text>
                  <text x="360" y="84">array</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
+-----+-----------+-------+------++-------------+
|Code |Identifier |Length | Data ||cipher suites|
+-----+-----------+-------+------++-------------+
        EAP Packet packet                   CBOR array
]]></artwork>
          </artset>
        </figure>
        <figure anchor="figure6">
          <name>cipher suite negotiation</name> anchor="figure8">
          <name>Cipher Suite Negotiation</name>
          <artset>
            <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="256" width="424" viewBox="0 0 424 256" class="diagram" 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 368,72 L 368,208" 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 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,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,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" fill="black" transform="rotate(180,40,160)"/>
                <g class="text">
                  <text x="24" y="36">EAP</text>
                  <text x="60" y="36">peer</text>
                  <text x="328" y="36">EAP</text>
                  <text x="368" y="36">Auth.</text> y="36">auth.</text>
                  <text x="24" y="52">(CoAP</text>
                  <text x="80" y="52">server)</text>
                  <text x="336" y="52">(CoAP</text>
                  <text x="392" y="52">client)</text>
                  <text x="168" y="100">...</text>
                  <text x="260" y="132">POST</text>
                  <text x="316" y="132">/a/eap/1</text>
                  <text x="80" y="148">Payload</text>
                  <text x="132" y="148">(EAP</text>
                  <text x="184" y="148">Req/Id,</text>
                  <text x="288" y="148">CBORArray[0,1,2])</text>
                  <text x="12" y="164">1)</text>
                  <text x="60" y="180">2.01</text>
                  <text x="112" y="180">Created</text>
                  <text x="200" y="180">Location-Path</text>
                  <text x="300" y="180">[/a/eap/2]</text>
                  <text x="72" y="196">Payload</text>
                  <text x="124" y="196">(EAP</text>
                  <text x="180" y="196">Resp/Id,</text>
                  <text x="272" y="196">CBORArray[0])</text>
                  <text x="12" y="212">2)</text>
                  <text x="200" y="228">...</text>
                </g>
              </svg>
            </artwork>
            <artwork type="ascii-art" align="center"><![CDATA[
  EAP peer                              EAP Auth. auth.
 (CoAP server)                          (CoAP client)
 -------------                          -------------
    |                                         |
    |               ...                       |
    |---------------------------------------->|
    |                          POST /a/eap/1  |
    |  Payload (EAP Req/Id, CBORArray[0,1,2]) |
 1) |<----------------------------------------|
    | 2.01 Created Location-Path [/a/eap/2]   |
    | Payload (EAP Resp/Id, CBORArray[0])     |
 2) |---------------------------------------->|
                        ...
]]></artwork>
          </artset>
        </figure>
        <t>In case
        <t>If there is no CBOR array stating specifying the cipher suites, the default cipher suites are applied. If the EAP authenticator sends a restricted list of cipher suites that are willing to accept, can be accepted, it <bcp14>MUST</bcp14> include the default value 0 0, since it is mandatory to implement. The EAP peer will have at least that option available.</t>
        <t>The cipher suite requirements are inherited from the ones those established by OSCORE <xref target="RFC8613"/>, which are COSE algorithms <xref target="RFC9053"/>. By default, the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm is SHA-256 and the AEAD Authenticated Encryption with Associated Data (AEAD) algorithm is AES-CCM-16-64-128 <xref target="RFC9053"/>. ("HMAC" stands for "Hashed Message Authentication Code".) Both are mandatory to implement. The other supported and negotiated cipher suites are the following:</t> as follows:</t>

        <ul spacing="normal">
          <li>
            <t>0) AES-CCM-16-64-128, SHA-256 (default)</t>
          </li>
          <li>
            <t>1) A128GCM, SHA-256</t>
          </li>
          <li>
            <t>2) A256GCM, SHA-384</t>
          </li>
          <li>
            <t>3) ChaCha20/Poly1305, SHA-256</t>
          </li>
          <li>
            <t>4) ChaCha20/Poly1305, SHAKE256</t>
          </li>
        </ul>

<!-- [rfced] Sections 6.1 and Appendix A:  Do these algorithms need
to be numbered?  If yes, will this numbering scheme be clear to
readers?

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 the Master Session Key (MSK), MSK, which is considered fresh key material, the HKDF-Expand function will be used (shortened here as KDF). Why "KDF") will be used. See <xref target="limit_eap_medhods"/> regarding why the use of this function is enough, enough and it is not necessary to use KDF-Extract is explained in <xref target="limit_eap_medhods"/>.</t> KDF-Extract.</t>
      </section>
      <section anchor="OSCORE">
        <name>Deriving the OSCORE Security Context</name>
        <t>The derivation of the OSCORE security context 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 detection of downgrading attacks.

<!-- [rfced] Section 6.2:  Does "Steps 7 and 8" here refer to
Steps 7 and 8 in Figure 3?  If yes, for ease of the reader we suggest
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> 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 Section 3.2.1 of <xref target="RFC8613"/>). target="RFC8613" sectionFormat="of" section="3.2.1"/>). It should be noted that the ID Context is not 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>
        <artwork align="center"><![CDATA[
Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length)
]]></artwork>

        <t>where:</t>
        <ul spacing="normal">
          <li>
            <t>The MSK is exported by the EAP method. Discussion about the The use of the MSK for key derivation is done discussed in <xref target="security_considerations"/>.</t>
          </li>
          <li>
            <t>CS is the concatenation of the content of the cipher suite negotiation, negotiation -- 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 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).

<!-- [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).</t> 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>
            <t>"COAP-EAP OSCORE MASTER SECRET" is the ASCII code representation of the non-NULL terminated 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>
            <t>CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated.</t>
          </li>
          <li>
            <t>length is the size of the output key material.</t>
          </li>
        </ul>
        <t>The Master Salt, similarly

        <t>Similarly to the Master Secret, the Master Salt can be derived as follows:</t>
        <artwork align="center"><![CDATA[
Master Salt = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SALT", length)
]]></artwork>

        <t>where:</t>
        <ul spacing="normal">
          <li>
            <t>The MSK is exported by the EAP method. Discussion about the The use of the MSK for the key derivation is done discussed in <xref target="security_considerations"/>.</t>
          </li>
          <li>
            <t>CS is the concatenation of the content of the cipher suite negotiation, negotiation -- 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 or nor CS-I were not sent, was sent (i.e., default algorithms are used) 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>
            <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>
            <t>CS and "COAP-EAP OSCORE MASTER SALT" are concatenated.</t>
          </li>
          <li>
            <t>length is the size of the output key material.</t>
          </li>
        </ul>

        <t>Since the MSK is used to derive the Master Key, the correct verification of the OSCORE protected OSCORE-protected request (Step 7) and response (Step 8) confirms that the EAP authenticator and the EAP peer have the same Master Secret, achieving key confirmation.</t>
        <t>To prevent a downgrading attack, the content of the cipher suite negotiation (which is referred
(referred to here as CS) "CS") negotiation is embedded in the Master Secret derivation. If an attacker changes the value of the cipher suite negotiation, the result will be different OSCORE security contexts, which ends up with a in turn will result in failure in Steps 7 and 8.</t>
        <t>The EAP authenticator will use the Recipient ID of the EAP peer (RID-I) as the Sender ID for its OSCORE Sender Context. The EAP peer will use this value as the Recipient ID for its Recipient Context.</t>
        <t>The EAP peer will use the Recipient ID of the EAP authenticator (RID-C) as the Sender ID for its OSCORE Sender Context. The EAP authenticator will use this value as the Recipient ID for its Recipient Context.</t>
      </section>
    </section>
    <section anchor="implementation_considerations">
      <name>Discussion</name>
      <section anchor="coap-as-eap-lower-layer">
        <name>CoAP as the EAP lower layer</name> Lower Layer</name>
        <t>This section discusses the suitability of the CoAP protocol as the EAP lower layer and reviews the requisites imposed by EAP on any protocol transporting EAP. What EAP expects from its lower layers can be found in Section 3.1 of <xref target="RFC3748"/>, target="RFC3748" sectionFormat="of" section="3.1"/>, which is elaborated next:</t>
        <t>Unreliable transport. EAP
  <dl spacing="normal" newline="false">
        <dt>Unreliable transport:</dt><dd>EAP does not assume that lower layers are reliable, but it can benefit from a reliable lower layer. In this sense, CoAP provides a reliability mechanism (e.g., using Confirmable messages).</t>
        <t>Lower layer messages).</dd>
        <dt>Lower-layer error detection. EAP detection:</dt><dd>EAP relies on lower layer lower-layer error detection (e.g., CRC, checksum, MIC, Message Integrity Check (MIC), etc.). For simplicity, CoAP-EAP delegates error detection to the lower layers, such as the link layer or transport layer (e.g., UDP over IPv6 or TCP).</t>
        <t>Lower layer security. EAP TCP).</dd>
        <dt>Lower-layer security:</dt><dd>EAP does not require security services from the lower layers.</t>
        <t>Minimum MTU.  Lower layers.</dd>
        <dt>Minimum MTU:</dt><dd>Lower layers need to provide an EAP MTU size of 1020 octets or greater. CoAP assumes an upper bound of 1024 octets for its payload, which covers the EAP requirements when in the CoAP payload only the EAP message is sent. sent in the CoAP payload. In the case of Messages 1 and 2 in <xref target="figure1"/>, target="figure3"/>, those messages have extra information apart from EAP. Nevertheless, the EAP Req/Id has a fixed length of 5 bytes. Message 2 2, with the EAP Resp/Id, would limit the length of the identity being used to the CoAP payload maximum size (1024) - len( CS-I || RID-I ) - EAP Response header (5 bytes), which leaves enough space for sending even lengthy identities. Nevertheless, this limitation can be overcome by using CoAP block-wise transfer<xref transfers <xref target="RFC7959"/>.
Note: When EAP is proxied over an a AAA framework, the Access-Request packets in RADIUS <bcp14>MUST</bcp14> 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.

<!-- [rfced] Section 7.1:  We changed this text as noted below.
Please review carefully (including our expansion of "AVP" for ease of
the reader), and let us know if anything is incorrect.

Original:
 Note: When EAP
 is proxied over an AAA framework, the Access-Request packets in
 RADIUS MUST contain a Framed-MTU attribute with the value 1024, and
 the Framed-MTU AVP to 1024 in DIAMETER This attribute signals the AAA
 server that it should limit its responses to 1024 octets.</t>
        <t>Ordering guarantees. octets.

Currently:
 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 lower-layer ordering guarantees for correct operation. Regarding message ordering, every time a new message 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 the name of the new resource via Location-Path or Location-Query options. This way, the application shows that its state has advanced.</t> advanced.</dd>
  </dl>
<!-- Quoted text is DNE; [LB] verified all three quoted excerpts. -->
        <t>Although the <xref target="RFC3748"/> states: states that "EAP provides its own support for duplicate elimination and retransmission", retransmission," EAP is also reliant on lower layer
lower-layer ordering guarantees. In this regard, <xref target="RFC3748"/> talks about possible duplication and says: says, "Where the lower layer is reliable, it will provide the EAP layer with a non-duplicated stream of packets. However, while it is desirable that lower layers provide for non-duplication, this is not a requirement". requirement." 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 <bcp14>SHOULD</bcp14> be set to an infinite value, so that retransmissions do not occur at the EAP layer."</t>
      </section>
      <section anchor="size-of-the-eap-lower-layer-vs-eap-method-size">
        <name>Size of the EAP lower layer vs Lower Layer vs. EAP method size</name> Method Size</name>
        <t>Regarding the impact that an EAP lower layer will have on the number of bytes of the whole authentication exchange, there is <xref target="CoAP-EAP"/> provides a comparison with another network layer-based network-layer-based EAP lower layer, PANA <xref target="RFC5191"/>, the Protocol for Carrying Authentication for Network Access (PANA) as defined in <xref target="coap-eap"/>.</t> target="RFC5191"/>.</t>
        <t>The EAP method being transported will take most of the exchange, however, exchange. However, the impact of the EAP lower layer cannot be ignored, especially in very constrained communication technologies, technologies such as the ones found in IoT, those with limited capabilities.</t> capabilities (e.g., as can be found in IoT networks).</t>
        <t>Note: For scenarios involving constrained devices and network scenarios, networks, the use of the latest versions of EAP methods (e.g., EAP-AKA' <xref target="RFC5448"/>, EAP-TLS 1.3 <xref target="RFC9190"/>) is recommended in favor of older versions with the goal of economization, economizing, or EAP methods more adapted for IoT networks (e.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 anchor="security_considerations">
      <name>Security Considerations</name>
      <t>There are some security
      <t>Security aspects to be considered, such as considered include how authorization is managed, the use of Master Session Key (MSK) the MSK as key material, and how trust in the EAP authenticator is established. Additional considerations such as EAP channel binding as per <xref target="RFC6677"/> are also discussed here.</t>
      <section anchor="limit_eap_medhods">
        <name>Use of EAP Methods</name>
        <t>This document limits the use of EAP methods to the ones those compliant with <xref target="RFC4017"/> specification, 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 anchor="authorization">
        <name>Authorization</name>
        <t>Authorization is part of bootstrapping. It serves to establish whether the EAP peer can join and the set of conditions it must adhere to. The authorization data will be gathered from the organization that is responsible for the EAP peer and sent to the EAP authenticator in case if a AAA infrastructure is deployed.</t>
        <t>In standalone mode, the authorization information will be in the EAP authenticator. If the pass-through mode is used, authorization data received from the AAA server can be delivered by the AAA protocol (e.g., RADIUS or Diameter).  Providing more fine-grained authorization data can be with done by transporting the transport of SAML data using the Security Assertion Markup Language (SAML) in RADIUS <xref target="RFC7833"/>.
After bootstrapping, additional authorization information may be needed to operate in the security domain. This can be taken care of by the solutions proposed in the ACE Authentication and Authorization for Constrained Environments (ACE) WG, such as the use of OAuth <xref target="RFC9200"/>, among other solutions, to provide Authentication and Authorization for Constrained Environments.</t> 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 anchor="allowing-coap-eap-traffic-to-perform-authentication">
        <name>Allowing CoAP-EAP traffic Traffic to perform authentication</name> Perform Authentication</name>
        <t>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 <bcp14>MUST</bcp14> authorize exclusively unprotected IP traffic to be sent between the EAP peer and the EAP authenticator during the authentication with 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 protected. 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.

<!-- [rfced] Section 8.3:

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.</t> 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 link layer <bcp14>MAY</bcp14> provide support to transport CoAP-EAP without an IP address by using link-layer frames (e.g. (e.g., by defining a new Key Management Protocol ID in per IEEE 802.15.9 <xref target="ieee802159"/>).</t> target="IEEE802159"/>).</t>
      </section>
      <section anchor="freshness-of-the-key-material">
        <name>Freshness of the key material</name> Key Material</name>
        <t>In CoAP-EAP CoAP-EAP, there is no nonce exchange to provide freshness to the keys derived from the MSK. The MSK MSKs and Extended Master Session Key (EMSK) keys according to the EAP Key Management Framework <xref target="RFC5247"/> EMSKs are fresh key material. material per <xref target="RFC5247"/>. Since only one authentication is established per EAP authenticator, there is no need to generate additional key material. In case If a new MSK is required, a re-authentication can be done, done by running the process again or using a more lightweight EAP method to derive additional key material as elaborated in <xref target="re-authentication"/>.</t>
      </section>
      <section anchor="channel-binding-support">
        <name>Channel Binding support</name>
        <name>Channel-Binding Support</name>
        <t>According to the <xref target="RFC6677"/>, channel binding, as related to EAP, is sent through the EAP method supporting it.</t>

        <t>To satisfy the requirements of the document, the EAP lower-layer identifier (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.</t> 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 anchor="additional-security-considerations">
        <name>Additional Security Considerations</name>
        <t>In the authentication process, there it is a possibility of possible for an entity forging to forge messages to generate denial of service denial-of-service (DoS) attacks on any of the entities involved. For instance, an attacker can forge multiple initial messages to start an authentication (Step 0) with the EAP authenticator as if they were sent by different EAP peers. Consequently, the EAP authenticator will start an authentication process for each message received in Step 0, sending the EAP Request/Id (Step 1).</t> 1).

<!-- [rfced] Section 8.6:  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:
 For instance, an attacker can forge
 multiple initial messages to start an authentication (Step 0) with
 the EAP authenticator as if they were sent by different EAP peers. -->

</t>
        <t>To minimize the effects of this DoS attack, it is <bcp14>RECOMMENDED</bcp14> that the EAP authenticator limits limit the rate at which it processes incoming messages in Step 0 to provide robustness against denial of service (DoS) DoS attacks. The details of rate limiting are outside the scope of this specification. Nevertheless, the rate of these messages is also limited by the bandwidth available between the EAP peer and the EAP authenticator. This bandwidth will be especially limited in constrained links (e.g., LPWAN). Low-Power WANs (LPWANs)). Lastly, it is also <bcp14>RECOMMENDED</bcp14> to reduce at a minimum the state in the EAP authenticator at least until the EAP Response/Id is received by the EAP authenticator.</t>
        <t>Another security-related concern is how to ensure that the EAP peer joining the security domain can trust the EAP authenticator. This issue is elaborated in the EAP Key Management Framework <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 association is derived from the MSK. If the EAP authenticator has the MSK, it is because the AAA Server server of the EAP peer trusted the EAP authenticator.</t>
      </section>
    </section>
    <section anchor="IANA">
      <name>IANA Considerations</name>
      <t>This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding the registration of values related to CoAP-EAP.</t>
      <section anchor="ciphersuite">
        <name>CoAP-EAP Cipher Suites</name>

<!-- [IANA FLAG] Took out the extra "Specification Required" in the
     text here (Section 9.1) and in Sections 9.2 and 9.8; it's a list
     of the categories, so no need to list "Specification Required"
     twice in each sentence. -->

        <t>IANA has created a new registry titled "CoAP-EAP Cipher Suites" under the a new registry group name named "CoAP-EAP protocol". Protocol".  The registration procedures are "Specification
Required", "Private Use", and "Standards Action with Expert Review" and "Specification Required" following the indications (see <xref target="RFC8126"/>), as shown in <xref target="ciphersute-registration-ranges"/>.</t> 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">
          <name>CoAP-EAP
          <name>Registration Procedures for CoAP-EAP Cipher Suites Registration Procedures</name> Suites</name>
          <thead>
            <tr>
              <th align="center">Range</th>
              <th align="center">Registration
              <th>Range</th>
              <th>Registration Procedures</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">-65536
              <td>-65536 to -25</td>
              <td align="center">Specification
              <td>Specification Required</td>
            </tr>
            <tr>
              <td align="center">-24
              <td>-24 to -21</td>
              <td align="center">Private
              <td>Private Use</td>
            </tr>
            <tr>
              <td align="center">-20
              <td>-20 to 23</td>
              <td align="center">Standards
              <td>Standards Action with Expert Review</td>
            </tr>
            <tr>
              <td align="center">24
              <td>24 to 65535</td>
              <td align="center">Specification
              <td>Specification Required</td>
            </tr>
          </tbody>
        </table>
        <t>The columns of the registry are Value, Algorithms, Description Description, and Reference, where Value is an integer, integer and the other columns are text strings.  The initial contents of the registry registrations are shown in <xref target="ciphersute-initial-value"/>.</t>
        <table anchor="ciphersute-initial-value">
          <name>CoAP-EAP Cipher Suites initial values</name> Suites: Initial Registrations</name>
          <thead>
            <tr>
              <th align="left">Value</th>
              <th align="left">Algorithms</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">0</td>
              <td align="left">10, -16</td>
              <td align="left">AES-CCM-16-64-128, SHA-256</td>
              <td align="left">[[this document]]</td> align="left">RFC 9820</td>
            </tr>
            <tr>
              <td align="left">1</td>
              <td align="left">1, -16</td>
              <td align="left">A128GCM, SHA-256</td>
              <td align="left">[[this document]]</td> align="left">RFC 9820</td>
            </tr>
            <tr>
              <td align="left">2</td>
              <td align="left">3, -43</td>
              <td align="left">A256GCM, SHA-384</td>
              <td align="left">[[this document]]</td> align="left">RFC 9820</td>
            </tr>
            <tr>
              <td align="left">3</td>
              <td align="left">24, -16</td>
              <td align="left">ChaCha20/Poly1305, SHA-256</td>
              <td align="left">[[this document]]</td> align="left">RFC 9820</td>
            </tr>
            <tr>
              <td align="left">4</td>
              <td align="left">24, -45</td>
              <td align="left">ChaCha20/Poly1305, SHAKE256</td>
              <td align="left">[[this document]]</td> align="left">RFC 9820</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="llid">
        <name>CDDL in CoAP-EAP Information elements</name> Elements</name>
        <t>IANA has created a new registry titled "CoAP-EAP Information element" Elements" under the a new registry group name named "CoAP-EAP protocol". Protocol".  The registration procedure procedures are "Specification Required", "Private Use", "Standards Action with Expert Review" and Review", "Private Use", "Specification Required" following the indications Required", and "Experimental Use" (see <xref target="RFC8126"/>),
as shown in <xref target="coap-eap-ie-registration-ranges"/>.</t> target="coap-eap-ie-registration-ranges"/>.
</t>
        <table anchor="coap-eap-ie-registration-ranges">
          <name>CoAP-EAP
          <name>Registration Procedures for CoAP-EAP Information Elements Registration Procedures</name> Elements</name>
          <thead>
            <tr>
              <th align="center">Range</th>
              <th align="center">Registration
              <th>Range</th>
              <th>Registration Procedures</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0
              <td>0 to 23</td>
              <td align="center">Standards
              <td>Standards Action with Expert Review</td>
            </tr>
            <tr>
              <td align="center">24
              <td>24 to 49</td>
              <td align="center">Private
              <td>Private Use</td>
            </tr>
            <tr>
              <td align="center">50
              <td>50 to 65000</td>
              <td align="center">Specification
              <td>Specification Required</td>
            </tr>
            <tr>
              <td align="center">65001
              <td>65001 to 65535</td>
              <td align="center">Experimental
              <td>Experimental Use</td>
            </tr>
          </tbody>
        </table>
        <t>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.  The initial registrations are shown in <xref target="coap-eap-ie-values"/>.

<!-- [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 initial contents columns of the registry are described in <xref target="coap-eap-ie-values"/>.</t> 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">
          <name>CoAP-EAP Information Elements initial content</name> Elements: Initial Registrations</name>
          <thead>
            <tr>
              <th align="left">Name</th>
              <th align="left">Label</th>
              <th align="left">CBOR Type</th>
              <th align="left">Description</th>
              <th align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Cipher Suite</td>
              <td align="left">1</td>
              <td align="left">CBOR Array</td>
              <td align="left">List of the proposed or selected COSE algorithms for OSCORE</td>
              <td align="left">[[this document]]</td> align="left">RFC 9820</td>
            </tr>
            <tr>
              <td align="left">RID-C</td>
              <td align="left">2</td>
              <td align="left">Byte String</td>
              <td align="left">It contains align="left">Contains the Recipient ID of the EAP authenticator</td>
              <td align="left">[[this document]]</td> align="left">RFC 9820</td>
            </tr>
            <tr>
              <td align="left">RID-I</td>
              <td align="left">3</td>
              <td align="left">Byte String</td>
              <td align="left">It contains align="left">Contains the Recipient ID of the EAP peer</td>
              <td align="left">[[this document]]</td> align="left">RFC 9820</td>
            </tr>
            <tr>
              <td align="left">Session-Lifetime</td>
              <td align="left">4</td>
              <td align="left">uint</td>
              <td align="left">Contains the time that the session is valid valid, in seconds</td>
              <td align="left">[[this document]]</td> align="left">RFC 9820</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="wellknown">
        <name>The Well-Known URI URIs Registry</name>
        <t>IANA has added the well-known URI "coap-eap" to the "Well-Known URIs" registry under the group name "Well-Known URIs" registry group defined by <xref target="RFC8615"/>.</t>
        <ul spacing="normal">
          <li>
            <t>URI suffix: coap-eap</t>
          </li>
          <li>
            <t>Change controller: IETF</t>
          </li>
          <li>
            <t>Specification document(s): [[this document]]</t>
          </li>
          <li>
            <t>Related information: None</t>
          </li>
          <li>
            <t>Status: permanent</t>
          </li>
        </ul>
	<dl spacing="compact" newline="false">
          <dt>URI Suffix:</dt><dd>coap-eap</dd>
          <dt>Reference:</dt><dd>RFC 9820</dd>
	  <dt>Status:</dt><dd>permanent</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
	</dl>
      </section>
      <section anchor="lowerlayer">
        <name>The EAP lower layer identifier registry</name> Lower Layers Registry</name>
        <t>IANA has added the identifier of CoAP-EAP "CoAP-EAP" to the registry "EAP Lower Layer" Layers" registry (defined by <xref target="RFC6677"/>) under the Extensible "Extensible Authentication Protocol (EAP) Registry defined by <xref target="RFC6677"/>.</t>
        <ul spacing="normal">
          <li>
            <t>Value: TBD.</t>
          </li>
          <li>
            <t>Lower Layer: CoAP-EAP</t>
          </li>
          <li>
            <t>Specification document(s): [[this document]]</t>
          </li>
        </ul> Registry".</t>
	<dl spacing="compact" newline="false">
          <dt>Value:</dt><dd>10</dd>
          <dt>Lower Layer:</dt><dd>CoAP-EAP</dd>
          <dt>Reference:</dt><dd>RFC 9820</dd>
	</dl>
      </section>
      <section anchor="mediatypes">
        <name>Media Types Registry</name>
        <t>IANA has added the media types type "application/coap-eap" to the "Media Types" registry. <xref target="coap-eap-media-type"/> defines the format.</t>
        <ul spacing="normal">
          <li>
            <t>Type name: application</t>
          </li>
          <li>
            <t>Subtype name: coap-eap</t>
          </li>
          <li>
            <t>Required parameters: N/A</t>
          </li>
          <li>
            <t>Optional parameters: N/A</t>
          </li>
          <li>
            <t>Encoding considerations: binary</t>
          </li>
          <li>
            <t>Security considerations: See

	<dl spacing="normal" newline="false">
          <dt>Type name:</dt><dd>application</dd>
          <dt>Subtype name:</dt><dd>coap-eap</dd>
          <dt>Required parameters:</dt><dd>N/A</dd>
          <dt>Optional parameters:</dt><dd>N/A</dd>
          <dt>Encoding considerations:</dt><dd>binary</dd>
          <dt>Security considerations:</dt><dd>See <xref target="security_considerations"/> of [[this document]].</t>
          </li>
          <li>
            <t>Interoperability considerations: N/A</t>
          </li>
          <li>
            <t>Published specification: [[this document]]</t>
          </li>
          <li>
            <t>Applications RFC 9820.</dd>
          <dt>Interoperability considerations:</dt><dd>N/A</dd>
          <dt>Published specification:</dt><dd>RFC 9820</dd>
          <dt>Applications that use this media type: To type:</dt><dd>To be identified</t>
          </li>
          <li>
            <t>Fragment identified</dd>
          <dt>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 considerations:</dt><dd>N/A</dd>
          <dt>Additional information:</dt>
	  <dd><t><br/></t>
	  <dl spacing="compact">
            <dt>Magic number(s):</dt><dd>N/A</dd>
            <dt>File extension(s):</dt><dd>N/A</dd>
            <dt>Macintosh file type code(s): N/A</t>
              </li>
            </ul>
          </li>
          <li>
            <t>Person code(s):</dt><dd>N/A</dd>
          </dl></dd>
          <dt>Person and email address to contact for further information: ace@ietf.org</t>
          </li>
          <li>
            <t>Intended usage: COMMON</t>
          </li>
          <li>
            <t>Restrictions information:</dt><dd>ace@ietf.org</dd>
          <dt>Intended usage:</dt><dd>COMMON</dd>
          <dt>Restrictions on usage: N/A</t>
          </li>
          <li>
            <t>Author: See usage:</dt><dd>N/A</dd>
          <dt>Author:</dt><dd>See the "Authors' Addresses" section of [[this document]].</t>
          </li>
          <li>
            <t>Change Controller: IETF</t>
          </li>
        </ul> RFC 9820.</dd>
          <dt>Change Controller:</dt><dd>IETF</dd>
        </dl>
      </section>
      <section anchor="content-format">
        <name>CoAP Content-Formats Registry</name>
        <t>IANA has added the media types type "application/coap-eap" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters" registry group, following the specification in Section 12.3 of <xref target="RFC7252"/>.</t> target="RFC7252" sectionFormat="of" section="12.3"/>.</t>
        <table anchor="content-format_registry">
          <name>CoAP Content-Formats Registry</name>
          <thead>
            <tr>
              <th align="center">Media
              <th>Media Type</th>
              <th align="center">Content
              <th>Content Encoding</th>
              <th align="center">ID</th>
              <th align="center">Reference</th>
              <th>ID</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">application/coap-eap</td>
              <td align="center">-</td>
              <td align="center">TBD</td>
              <td align="center">[[this document]]</td>
              <td>application/coap-eap</td>
              <td>-</td>
              <td>269</td>
              <td>RFC 9820</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="resource-type">
        <name>Resource Type (rt=) Link Target Attribute Values Registry</name>
        <t>IANA has added the resource type "core.coap-eap" to the "Resource Type (rt=) Link Target Attribute Values" registry under the group name "Constrained RESTful Environments (CoRE) Parameters".</t>
        <ul spacing="normal">
          <li>
            <t>Value: "core.coap-eap"
            </t>
            <ul spacing="normal">
              <li>
                <t>Description: CoAP-EAP resource.</t>
              </li>
              <li>
                <t>Reference: [[this document]]</t>
              </li>
            </ul>
          </li>
        </ul> Parameters" registry group.</t>

<table anchor="resource-type-reg">
  <name>Resource Type (rt=) Link Target Attribute Values Registry</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Description</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>core.coap-eap</td>
      <td>CoAP-EAP resource</td>
      <td>RFC 9820</td>
    </tr>
  </tbody>
</table>

      </section>
      <section anchor="expert-review-instructions">
        <name>Expert Review Instructions</name>
        <t>The IANA registries established in this document are defined as apply the
   "Specification Required", "Private Use", "Standards Action with Expert Review",
and "Experimental Use" and "Specification Required". policies.  (See also <xref target="RFC8126"/>.)
   This section provides general guidelines for what experts should focus on, but as they are designated experts for a reason, they should be granted flexibility.</t>
        <ul spacing="normal">
          <li>
            <t>When defining the use of CoAP-EAP Information Elements: Experts Elements (IEs), experts are expected to evaluate how the values are defined, their scope, and whether they align with CoAP-EAP's functionality and constraints. They are expected to assess if whether the values are clear, well-structured, well structured, and follow CoAP and CoAP-EAP conventions, such as concise encoding for constrained environments. They should ensure that these IEs can seamlessly integrate with existing CoAP implementations and extensions. It is Experts are also expected that they to verify if that IE values are protected from unauthorized modification or misuse during transmission.</t>
          </li>
          <li>
            <t>When adding new cipher suites:  Experts suites, experts must ensure that algorithm values are sourced from the appropriate registry when required. They should also consider seeking input from relevant IETF working groups regarding the accuracy of registered parameters.</t>
          </li>
        </ul>
      </section>
    </section>
  </middle>
  <back>

    <displayreference target="I-D.ietf-emu-eap-edhoc" to="EAP-EDHOC"/>

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5247.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3748.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8613.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6677.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7959.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>

<!-- draft-ietf-emu-eap-edhoc (I-D Exists) -->
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> anchor="I-D.ietf-emu-eap-edhoc">
   <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC5247" target="https://www.rfc-editor.org/info/rfc5247" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5247.xml">
          <front>
            <title>Extensible Authentication Protocol (EAP) Key Management Framework</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 3748, enables extensible network access authentication. This document specifies the EAP key hierarchy and provides a framework for the transport and usage of keying material and parameters generated by EAP authentication algorithms, known as "methods". It also provides a detailed system-level security analysis, describing 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/rfc3748" 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 (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3748"/>
          <seriesInfo name="DOI" value="10.17487/RFC3748"/>
        </reference>
        <reference anchor="RFC7252" target="https://www.rfc-editor.org/info/rfc7252" 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 web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless 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-machine (M2M) applications such as smart energy and building automation.</t>
              <t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity 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/rfc8613" 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 Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols.</t>
              <t>Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252.</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/rfc8174" 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</title>
            <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 protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC6677" target="https://www.rfc-editor.org/info/rfc6677" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6677.xml">
          <front>
            <title>Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods</title>
            <author fullname="S. Hartman" initials="S." role="editor" surname="Hartman"/>
            <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 Extensible Authentication Protocol (EAP) methods to address the "lying Network Access Service (NAS)" problem as well as the "lying provider" problem. [STANDARDS-TRACK]</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/rfc8323" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8323.xml">
          <front>
            <title>CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets</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="Raymor"/>
            <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 document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 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/rfc8949" 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 format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.</t>
              <t>This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange 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/rfc7959" 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="Shelby"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for 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 Security (DTLS). These transports only offer fragmentation, which is even more problematic 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 extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, 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 generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7959"/>
          <seriesInfo name="DOI" value="10.17487/RFC7959"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.ietf-emu-eap-edhoc" target="https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-edhoc-02" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-emu-eap-edhoc.xml">
          <front>
            <title>Using
      <title>Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC)</title>
      <author fullname="Dan Garcia-Carrillo" initials="D." surname="Garcia-Carrillo"> surname="Garcia-Carrillo" fullname="Dan Garcia-Carrillo">
         <organization>University of Oviedo</organization>
      </author>
      <author fullname="Rafael Marin-Lopez" initials="R." surname="Marin-Lopez"> surname="Marin-Lopez" fullname="Rafael Marin-Lopez">
         <organization>University of Murcia</organization>
      </author>
      <author fullname="Göran Selander" initials="G." surname="Selander"> surname="Selander" fullname="Göran Selander">
         <organization>Ericsson</organization>
      </author>
      <author initials="J." surname="Preuß Mattsson" fullname="John Preuß Mattsson" initials="J. P." surname="Mattsson"> Mattsson">
         <organization>Ericsson</organization>
      </author>
            <date day="21" month="October" year="2024"/>
            <abstract>
              <t>The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the EAP authentication method EAP- EDHOC, based on Ephemeral Diffie-Hellman Over COSE (EDHOC). EDHOC provides a lightweight authenticated Diffie-Hellman key exchange with ephemeral keys, using COSE to provide security services efficiently encoded in CBOR. This document also provides guidance on authentication and authorization for EAP-EDHOC.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-emu-eap-edhoc-02"/>
        </reference>
        <reference anchor="RFC7967" target="https://www.rfc-editor.org/info/rfc7967" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7967.xml">
          <front>
            <title>Constrained Application Protocol (CoAP) Option for No Server Response</title>
            <author fullname="A. Bhattacharyya" initials="A." surname="Bhattacharyya"/>
      <author fullname="S. Bandyopadhyay" initials="S." surname="Bandyopadhyay"/>
            <author fullname="A. Pal" initials="A." surname="Pal"/>
            <author fullname="T. Bose" initials="T." surname="Bose"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>There can be machine-to-machine (M2M) scenarios where server responses to client requests are redundant. This kind of open-loop exchange (with no response path from the server to the client) may be desired to minimize resource consumption in constrained systems while updating many resources simultaneously or performing high-frequency updates. CoAP already provides Non-confirmable (NON) messages that are not acknowledged by the recipient. However, the request/response semantics still require the server to respond with a status code indicating "the result of the attempt to understand and satisfy the request", per RFC 7252.</t>
              <t>This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes. The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request. This option may be effective for both unicast and multicast requests. This document also discusses a few examples of applications that benefit from this option.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7967"/>
          <seriesInfo name="DOI" value="10.17487/RFC7967"/>
        </reference>
        <reference anchor="RFC5869" target="https://www.rfc-editor.org/info/rfc5869" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml">
          <front>
            <title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
            <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 building block in various protocols and applications. The key derivation function (KDF) is intended to support a wide range of applications and requirements, and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</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/rfc4764" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4764.xml">
          <front>
            <title>The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication 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 Protocol (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 document describes the use of this channel only for protected exchange of result indications, but future EAP-PSK extensions may use the channel for other purposes. EAP-PSK is designed for authentication over insecure networks such as IEEE 802.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/rfc5191" 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 Authentication Protocol (EAP) to enable network access authentication between clients and access networks. In EAP terms, PANA is a UDP-based EAP lower layer that runs between 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/rfc5433" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5433.xml">
          <front>
            <title>Extensible Authentication Protocol - Generalized Pre-Shared Key (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) method called EAP Generalized Pre-Shared Key (EAP-GPSK). This method is a lightweight 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/rfc5448" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5448.xml">
          <front>
            <title>Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')</title>
            <author fullname="J. Arkko" initials="J." surname="Arkko"/>
            <author fullname="V. Lehtovirta" initials="V." surname="Lehtovirta"/>
            <author fullname="P. Eronen" initials="P." surname="Eronen"/>
            <date month="May" year="2009"/>
            <abstract>
              <t>This specification defines a new EAP method, EAP-AKA', which is a small revision of the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1.</t>
              <t>This specification also updates RFC 4187, EAP-AKA, to prevent bidding down attacks from EAP-AKA'. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5448"/>
          <seriesInfo name="DOI" value="10.17487/RFC5448"/>
        </reference>
        <reference anchor="RFC6696" target="https://www.rfc-editor.org/info/rfc6696" 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 framework supporting multiple types of authentication methods. In systems where EAP is used for authentication, it is desirable to avoid repeating the entire EAP exchange with another authenticator. This document specifies extensions to EAP and the EAP keying hierarchy to support an EAP method-independent protocol for efficient re- authentication between the peer and an EAP re-authentication server through 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/rfc7833" 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)</title>
            <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" surname="Perez-Mendez"/>
            <date month="May" year="2016"/>
            <abstract>
              <t>This document describes the use of the Security Assertion Markup Language (SAML) with RADIUS in the context of the Application Bridging for Federated 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 Assertions and protocol messages within RADIUS, allowing SAML entities to communicate using the binding. The two profiles describe the application of this binding for ABFAB authentication and assertion Query/Request, enabling a Relying Party to request authentication of, or assertions for, users or machines (clients). These clients may be named using a Network Access Identifier (NAI) name identifier format. Finally, the subject confirmation methods allow requests and queries to be issued for a previously authenticated user or machine without needing to explicitly identify them as the subject. The use surname="Lopez-Gomez" fullname="Francisco Lopez-Gomez">
         <organization>University of the artifacts defined in this document is not exclusive to ABFAB. They can be applied in any Authentication, Authorization, 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/rfc8824" 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"/> Murcia</organization>
      </author>
      <date month="June" year="2021"/>
            <abstract>
              <t>This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages 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 leverage 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/rfc9147" 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 Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, 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 exception 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/rfc4137" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4137.xml">
          <front>
            <title>State Machines for Extensible Authentication Protocol (EAP) Peer 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-through), EAP backend authenticator (for use on Authentication, Authorization, and Accounting (AAA) servers), and EAP full authenticator (for both local and pass-through). This set of state machines shows how EAP can be implemented to support deployment in either a peer/authenticator or peer/authenticator/AAA Server environment. The peer and stand-alone authenticator machines are illustrative of how the EAP protocol defined in RFC 3748 may be implemented. The backend and full/pass-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 model includes events and actions for the interaction between the EAP Switch and EAP methods. A brief description of the EAP "Switch" model is given in the Introduction section.</t>
              <t>The state machine and associated model are informative only. Implementations may achieve the same results using different methods. This memo provides 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/rfc9140" 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 for multiple authentication methods. This document defines the EAP-NOOB authentication 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 peer device and authentication server to authenticate the in-band key exchange. The device must have a nonnetwork input or output interface, such as a display, microphone, speaker, or blinking light, that can send or receive dynamically generated 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/rfc9176" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9176.xml">
          <front>
            <title>Constrained RESTful Environments (CoRE) Resource Directory</title>
            <author fullname="C. Amsüss" initials="C." role="editor" surname="Amsü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 Stok"/>
            <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 called a Resource Directory (RD), which contains information about resources held on 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 interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes 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/rfc8615" 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/rfc9200" 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 authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to 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/rfc9190" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9190.xml">
          <front>
            <title>EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3</title>
            <author fullname="J. Preuß Mattsson" initials="J." surname="Preuß Mattsson"/>
            <author fullname="M. Sethi" initials="M." surname="Sethi"/>
            <date month="February" year="2022"/>
            <abstract>
              <t>The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9190"/>
          <seriesInfo name="DOI" value="10.17487/RFC9190"/>
        </reference>
        <reference anchor="RFC9031" target="https://www.rfc-editor.org/info/rfc9031" 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="Vuč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 new device, called a "pledge", to securely join a 6TiSCH (IPv6 over the Time-Slotted Channel Hopping mode of IEEE 802.15.4) network. The framework requires that the pledge and the JRC (Join Registrar/Coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network, and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and it describes how to configure the rest of the 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/rfc4017" 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 wireless LAN deployments. The material in this document has been approved by IEEE 802.11 and is being presented as an IETF RFC for informational purposes. This memo 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/rfc9053" 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 designed 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 set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) 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/rfc4186" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4186.xml">
          <front>
            <title>Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)</title>
            <author fullname="H. Haverinen" initials="H." role="editor" surname="Haverinen"/>
            <author fullname="J. Salowey" initials="J." role="editor" surname="Salowey"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>This document specifies an Extensible Authentication Protocol (EAP) mechanism for authentication and session key distribution using the Global System for Mobile Communications (GSM) Subscriber Identity Module (SIM). GSM is a second generation mobile network standard. The EAP-SIM mechanism specifies enhancements to GSM authentication and key agreement whereby multiple authentication triplets can be combined to create authentication responses and session keys of greater strength than the individual GSM triplets. The mechanism also includes network authentication, user anonymity support, result indications, and a fast re-authentication procedure. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4186"/>
          <seriesInfo name="DOI" value="10.17487/RFC4186"/>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <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 Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract> day="4" year="2025" />
   </front>
   <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/> name="Internet-Draft" value="draft-ietf-emu-eap-edhoc-04"/>
</reference>

	<xi:include
href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7967.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4764.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5191.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5433.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5448.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6696.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7833.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8824.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9147.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4137.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9140.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9176.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8615.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9200.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9190.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9031.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4017.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9053.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4186.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>

        <reference anchor="EAP-framework-IoT" anchor="EAP-Framework-IoT" target="https://ieeexplore.ieee.org/document/9579387">
          <front>
            <title>Secure Network Access Authentication for IoT Devices: EAP Framework vs. Individual Protocols</title>
            <author initials="M." surname="Sethi" fullname="Ericsson"> fullname="Mohit Sethi">
              <organization/>
            </author>
            <author initials="T." surname="Aura" fullname="Tuomas Aura">
              <organization/>
            </author>
            <date year="2021"/>
          </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 anchor="lo-coap-eap" anchor="LO-CoAP-EAP" target="https://www.mdpi.com/1424-8220/17/11/2646">
          <front>
            <title>A CoAP-Based Network Access Authentication Service for Low-Power Wide Area Networks: LO-CoAP-EAP</title>
            <author initials="D." surname="Garcia-Carrillo" fullname="Dan Garcia-Carrillo">
              <organization/>
            </author>
            <author initials="R." surname="Marin-Lopez" fullname="Rafael Marin-Lopez">
              <organization/>
            </author>
            <author initials="A." surname="Kandasamy" fullname="Arunprabhu Kandasamy">
              <organization/>
            </author>
            <author initials="A." surname="Pelov" fullname="Alexander Pelov">
              <organization/>
            </author>
            <date year="2017"/>
          </front>
          <seriesInfo name="DOI" value="10.3390/s17112646"/>
          <refcontent>Sensors, vol. 17, no. 11</refcontent>
        </reference>

        <reference anchor="coap-eap" anchor="CoAP-EAP" target="https://www.mdpi.com/1424-8220/16/3/358">
          <front>
            <title>Lightweight CoAP-Based Bootstrapping Service for the Internet of Things</title>
            <author initials="D." surname="Garcia-Carrillo" fullname="Dan Garcia-Carrillo">
              <organization/>
            </author>
            <author initials="R." surname="Marin-Lopez" fullname="Rafael Marin-Lopez">
              <organization/>
            </author>
            <date year="2016"/>
          </front>
          <seriesInfo name="DOI" value="10.3390/s16030358"/>
          <refcontent>Sensors, vol. 16, no. 3</refcontent>
        </reference>

        <reference anchor="TS133.501" target="">
          <front>
            <title>5G; Security architecture and procedures for 5G System</title>
            <author>
              <organization>ETSI</organization>
            </author>
            <date year="2018"/>
          </front>
          <seriesInfo name="ETSI TS" value="133 501"/>
          <refcontent>V15.2.0</refcontent>
        </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)</title>
            <author initials="" surname="ETSI" fullname="ETSI">
              <organization/>
            </author>
            <date year="2018"/>
          </front>
        </reference> (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="">
          <front>
            <title>ZigBee
            <title>Zigbee IP Specification (Zigbee Document 095023r34)</title>
            <author initials="" surname="Zigbee Alliance" fullname="Zigbee Alliance">
              <organization/>
            <author>
              <organization>Zigbee Alliance</organization>
            </author>
            <date year="2014"/>
          </front>
        </reference>

<!-- [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" anchor="IEEE802159" target="">
          <front>
            <title>IEEE Standard for Transport of Key Management Protocol (KMP) Datagrams</title>
            <author initials="" surname="IEEE" fullname="IEEE">
              <organization/>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2021"/> month="January" year="2022"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.15.9-2021"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2022.9690134"/>
        </reference>

        <reference anchor="THREAD" target="">
          <front>
            <title>Thread specification Specification 1.3</title>
            <author initials="" surname="Thread Group" fullname="Thread Group">
              <organization/>
            <author>
              <organization>Thread Group</organization>
            </author>
            <date year="2023"/>
          </front>
        </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>
    <?line 789?>

<section anchor="flow-of-operation-dtls">
      <name>Flow of operation Operation (DTLS establishment)</name> Establishment)</name>
      <t>CoAP-EAP makes it possible to derive a PSK Pre-Shared Key (PSK) from the MSK to allow (D)TLS PSK-based authentication between the EAP peer and the EAP authenticator instead of using OSCORE. In the case of using (D)TLS to establish a security association, there is a limitation on the use of intermediaries between the EAP peer and the EAP authenticator, as (D)TLS breaks the end-to-end communications 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 peer and the EAP authenticator using the keying material exported by the EAP authentication. The general flow is essentially the same as in the case of OSCORE, except 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 <bcp14>MUST</bcp14> be interpreted by the EAP peer as an alternate success indication, which will end up with the MSK and the DTLS_PSK derivation for the (D)TLS authentication based on the PSK.</t>
      <figure anchor="fig-dtls">
        <name>CoAP-EAP flow Flow of operation Operation with DTLS</name>
        <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">
              <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 16,48 L 112,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,160 L 416,160" 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 320,190 L 416,190" fill="none" stroke="black"/>
              <path d="M 320,194 L 416,194" fill="none" stroke="black"/>
              <path d="M 152,224 L 168,224" fill="none" stroke="black"/>
              <path d="M 344,224 L 360,224" fill="none" stroke="black"/>
              <polygon class="arrowhead" points="424,112 412,106.4 412,117.6" fill="black" transform="rotate(0,416,112)"/>
              <polygon class="arrowhead" points="368,224 356,218.4 356,229.6" fill="black" transform="rotate(0,360,224)"/>
              <polygon class="arrowhead" points="160,224 148,218.4 148,229.6" fill="black" transform="rotate(180,152,224)"/>
              <polygon class="arrowhead" points="104,160 92,154.4 92,165.6" fill="black" transform="rotate(180,96,160)"/>
              <g class="text">
                <text x="40" y="36">EAP</text>
                <text x="76" y="36">peer</text>
                <text x="344" y="36">EAP</text>
                <text x="416" y="36">authenticator</text>
                <text x="216" y="68">...</text>
                <text x="116" y="84">2.01</text>
                <text x="168" y="84">Created</text>
                <text x="256" y="84">Location-Path</text>
                <text x="364" y="84">[/a/eap/(n)]</text>
                <text x="128" y="100">Payload</text>
                <text x="188" y="100">(EAP-X</text>
                <text x="240" y="100">Resp)</text>
                <text x="68" y="116">6)</text>
                <text x="448" y="132">MSK</text>
                <text x="172" y="148">(D)TLS</text>
                <text x="216" y="148">1.3</text>
                <text x="260" y="148">Client</text>
                <text x="312" y="148">Hello</text>
                <text x="448" y="148">|</text>
                <text x="32" y="164">MSK</text>
                <text x="68" y="164">7)</text>
                <text x="32" y="180">|</text>
                <text x="468" y="180">DTLS_PSK</text>
                <text x="228" y="196">DTLS</text>
                <text x="284" y="196">hanshake</text> y="196">handshake</text>
                <text x="36" y="212">DTLS_PSK</text>
                <text x="208" y="228">Protected</text>
                <text x="268" y="228">with</text>
                <text x="316" y="228">(D)TLS</text>
              </g>
            </svg>
          </artwork>
          <artwork type="ascii-art" align="center"><![CDATA[
    EAP peer                              EAP authenticator
  -------------                           -------------
                          ...
           | 2.01 Created Location-Path [/a/eap/(n)] |
           | Payload (EAP-X Resp)                    |
        6) |---------------------------------------->|
           |                                         | MSK
           |       (D)TLS 1.3 Client Hello           |  |
   MSK  7) |<----------------------------------------|  V
    |      |                                         | DTLS_PSK
    V      |===============DTLS hanshake=============| handshake============|
 DTLS_PSK  |                                         |
                   <-(Protected with (D)TLS)->
]]></artwork>
        </artset>
      </figure>
      <t><xref target="fig-dtls"/> shows

<!-- [rfced] Figure 9:

a) Please note that we changed "hanshake" to "handshake".  However,
in the last steps of HTML and PDF output files, the operation for CoAP-EAP when (D)TLS is used space after the "e" in
"hanshake" was removed in the process.  We cannot determine where in
the SVG a coordinate should be modified to protect correct the communication between spacing.
Please correct the EAP peer SVG in the edited copy of the XML.

b) We see "down" arrows between MSK and DTLS_PSK in the EAP authenticator using ASCII art
for this figure, but they do not appear in the keying material exported by SVG.  If you would
like to add the EAP authentication. The general flow is essentially arrows in the same as SVG, please correct the SVG in the case
edited copy of OSCORE, except that DTLS negotiation is established the XML.

c) We see "(Protected with (D)TLS)" in Step 7). Once DTLS negotiation has finished successfully, the EAP peer is granted access to ASCII art but
"Protected with (D)TLS" in the domain. Step 7 <bcp14>MUST</bcp14> be interpreted by SVG.  If you prefer the EAP peer as an alternate success indication, which will end up with parentheses,
please correct the MSK and SVG in the DTLS_PSK derivation for edited copy of the (D)TLS authentication based on PSK.</t> XML.  If you prefer
that the parentheses be removed, let us know, and we will update the
ASCII art accordingly. -->

      <t>According to <xref target="RFC8446"/> target="RFC8446"/>, the provision of the PSK out-of-band out of band also requires the provision of the KDF hash algorithm and the PSK identity. 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 if DTLS wants to be used instead of OSCORE. For the same reason, the PSK identity is derived from (RID-C) (RID-I) as defined in <xref target="dtls-psk"/>.

<!-- [rfced] Appendix A:

a) As it appears that "Steps 1 and 2" here refer to Steps 1 and 2 in
Figure 8 (as opposed to Steps 1 and 2 in Figure 3), may we add a
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 <xref target="dtls-psk"/>.</t> Appendix A.1. -->

</t>
      <t>Analogous to how the cipher suite is negotiated for OSCORE <xref target="crypto-negotiation"/>, (<xref target="crypto-negotiation"/>), the EAP authenticator sends a list, in decreasing order of preference, with the identifiers of the hash algorithms supported (Step 1). In the response, the EAP peer sends the 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 (see <xref target="cbor-coap-eap"/>).   An example of how the fields are arranged in the CoAP payload can be seen in <xref target="figure5"/>.</t>
      <t>In case target="figure7"/>.</t>
      <t>If there is no CBOR array stating specifying the cipher suites, the default cipher suites are applied. If the EAP authenticator sends a restricted list of cipher suites that is willing to accept, can be accepted, it <bcp14>MUST</bcp14> include the default value 0 0, since it is mandatory to implement. The EAP peer will have at least that option available.</t>
      <t>For DTLS, the negotiated cipher suite is used to determine the hash function to be used to derive the "DTLS PSK" from the MSK:</t>
      <t>The MSK. The following hash algorithms considered are the following:</t> considered:</t>
      <ul spacing="normal">
        <li>
          <t>5) TLS_SHA256</t>
        </li>
        <li>
          <t>6) TLS_SHA384</t>
        </li>
        <li>
          <t>7) TLS_SHA512</t>
        </li>
      </ul>

<!-- [rfced] Appendix A:  Should "considered" be "supported" in this
sentence, along the lines of "The other supported and negotiated
cipher suites are the following" as seen in Section 6.1?

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 if that the EAP authenticator intends to establish an OSCORE security association or a DTLS security association after the authentication is completed. If both options appear in the cipher suite negotiation, the OSCORE security association will be preferred over DTLS.</t>
      <section anchor="dtls-psk">
        <name>Deriving DTLS PSK and identity</name> Identity</name>
        <t>To enable DTLS after an EAP authentication, the Identity and the PSK for DTLS is are defined. The Identity in this case is generated by concatenating the exchanged Sender ID and the Recipient ID.</t>
        <artwork><![CDATA[
                CoAP-EAP PSK Identity = RID-C || RID-I
]]></artwork>
        <t>It is also possible to derive a pre-shared key 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 derived that can be later truncated later if needed:</t>
        <artwork><![CDATA[
                DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length). length)
]]></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>
        <ul spacing="normal">
          <li>
            <t>MSK
            <t>The MSK is exported by the EAP method.</t>
          </li>
          <li>
            <t>"CoAP-EAP DTLS PSK" is the ASCII code representation of the non-NULL terminated non-NULL-terminated string (excluding the double quotes around it).</t>
          </li>
          <li>
            <t>length is the size of the output key material.</t>
          </li>
        </ul>
      </section>
    </section>
    <section anchor="using-coap-eap-for-distributing-key-material-for-iot-networks">
      <name>Using CoAP-EAP for distributing key material Distributing Key Material for IoT networks</name>
      <t>Similarly, Networks</name>
      <t>Similarly to the example of in <xref target="dtls-psk"/>, where a shared key PSK for DTLS is derived, it is possible to provide key material to different link-layers link layers after the CoAP-EAP authentication is complete.</t>
      <t>One complete.

<!-- [rfced] Appendix B:  Because "PSK" stands for "Pre-Shared Key",
should "a shared key PSK" be "a PSK"?

Original:
 Similarly, to the example of Appendix A.1, where a shared key PSK for
 DTLS is that derived, it is possible to provide key material to different
 link-layers after the CoAP-EAP authentication is complete. -->

</t>
      <t>For example, CoAP-EAP could be used to derive the required PSK required to run the 6TiSCH Constrained Join Protocol (CoJP) for IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) <xref target="RFC9031"/>.</t> target="RFC9031"/>. ("TSCH" stands for "Time-Slotted Channel Hopping".)</t>
      <t>Another example is would be 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 Zigbee IP <xref target="ZigbeeIP"/> or the THREAD protocol <xref target="THREAD"/>. After CoAP-EAP execution, a security association based on OSCORE protects any exchange between the EAP peer and the EAP authenticator. This security association can be used for distributing the Network Key securely and other required parameters. How the Network Key is distributed after a successful CoAP-EAP authentication is out of outside the scope of this document.</t>
      <t>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.

<!-- [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.</t>
 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 anchor="examples-of-use-case-scenario">
      <name>Examples of
      <name>Example Use Case Scenario</name> Scenarios</name>
      <t>In IoT, IoT networks, for an EAP peer to act as a trustworthy entity within a security domain, certain key material needs to be shared between the EAP peer and the EAP authenticator.</t>
      <t>Next, examples of different use case scenarios will be elaborated on, about on as related to the usage of CoAP-EAP.</t>
      <t>Generally, four entities are involved:</t>
      <ul spacing="normal">
        <li>
          <t>2
          <t>Two EAP peers (A and B).

<!-- [rfced] Appendix C:  "EAP peers (A and B), which are EAP peers.
They are the EAP peers.</t> 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>
          <t>1
          <t>One EAP authenticator (C). The EAP authenticator manages a domain where EAP peers can be deployed. In IoT, IoT networks, it can be considered a more powerful machine than the EAP peers.</t>
        </li>
        <li>
          <t>1
          <t>One AAA server (AAA) - server. Optional. The AAA server is not constrained. Here, the EAP authenticator is operating in pass-through mode.

<!-- [rfced] Appendix C:  "the EAP authenticator acts as an Authentication, Authorization, EAP
authenticator" read oddly and Accounting Server, which was difficult to follow.  We updated
this sentence as noted below.  If this update is not constrained. incorrect, please
clarify the text.

Original:
 Here, the EAP authenticator acts as an EAP authenticator in pass-through mode.</t> pass-
 through mode.

Currently:
 Here, the EAP authenticator is operating in pass-
 through mode. -->

</t>
        </li>
      </ul>
      <t>Generally, any EAP peer wanting to join the domain managed by the EAP authenticator <bcp14>MUST</bcp14> perform a CoAP-EAP authentication with the EAP authenticator (C). This authentication <bcp14>MAY</bcp14> involve an external AAA server.  This means that A the EAP peers (A and B, B), once deployed, will run CoAP-EAP once, as a bootstrapping phase, to establish a security association with C. Moreover, any other entity, which entity that wants to join and establish communications with EAP peers under
C's domain must also do the same.</t>
      <t>By using EAP, the flexibility of having different types of credentials can be achieved. For instance, if a device that is not battery-dependent battery dependent and not very constrained is available, a heavier authentication method could be used. With varied EAP peers and networks, authentication methods that are more lightweight (e.g., EAP-NOOB <xref target="RFC9140"/>, EAP-AKA' <xref target="RFC5448"/>, EAP-PSK <xref target="RFC4764"/>, EAP-EDHOC <xref target="I-D.ietf-emu-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.

<!-- [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<xref target="RFC9140"/>, EAP-AKA'<xref target="RFC5448"/>, EAP-PSK<xref target="RFC4764"/>, EAP-EDHOC<xref target="I-D.ietf-emu-eap-edhoc"/>, 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.</t> 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">
        <name>Example 1:  CoAP-EAP in Using ACE</name>
        <t>In
        <t>When using ACE, the process of client registration and provisioning of credentials to the client is not specified. The process of Client client registration and provisioning can be achieved using CoAP-EAP. Once the process of authentication with EAP is completed, the fresh key material is shared between the EAP peer and the EAP authenticator. In this instance, With ACE, the EAP authenticator and the Authorization Server (AS) of ACE can be co-located.</t>
        <t>Next, a general way to exemplify how Client client registration can be performed using CoAP-EAP is presented, to allow two EAP peers (A and B) to communicate and interact after a successful client registration.</t>
        <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 with EAP peer A. In phases.</t>

<ul spacing="normal">
<li><t>In the first phase, EAP peer A does not yet belong to EAP authenticator C's domain.  Then, it communicates with C and authenticates with CoAP-EAP, which, optionally, communicates with the AAA server to complete the authentication process. If the authentication is successful, a fresh MSK is shared between C and EAP peer A. This key material allows EAP peer A to establish a security association with the C. Some authorization information may also be provided in this step. In case If EAP is used in standalone mode, the AS itself itself, having information about the devices devices, can be the entity providing said authorization information.</t>
        <t>If authentication and authorization are correct, EAP peer A has been is enrolled in the EAP authenticator C's domain for some period of time. In particular, <xref target="RFC5247"/> recommends 8 hours, though the entity providing the authorization information can establish this lifetime.  In the same manner, B needs to perform the same process with CoAP-EAP to be part of EAP authenticator C's domain.</t>
        <t>In domain.</t></li>
        <li><t>In the second phase, when EAP peer A wants to talk to EAP peer B, it contacts EAP authenticator C for authorization to access EAP peer B and obtain all the required information to do that securely (e.g., keys, tokens, authorization information, etc.).  This phase does NOT require the usage of CoAP-EAP.  The details of this phase are out of outside the scope of this document, and document; the ACE framework is used for this purpose purpose. See <xref target="RFC9200"/>.</t>
        <t>In target="RFC9200"/>.</t></li>
        <li><t>In the third phase, EAP peer A can access EAP peer B with the credentials and information obtained from EAP authenticator C in during the second phase. This access can be repeated without contacting the EAP authenticator, while the credentials given to A are still valid.  The details of this phase are out of outside the scope of this document.</t> document.

<!-- [rfced] Appendix C.1:  Does "while" in this sentence mean "at
the same time as" or "as long as" (per the "as long as the key
material is still valid" phrase in the "It is worth noting that the
first phase ..." paragraph)?

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 the
EAP authenticator C's domain.  Once it is performed successfully, the communications are local to the 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 keys are about to expire, the EAP peer can engage in a re-authentication to renew the key material,
as explained in <xref target="re-authentication"/>, 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 renew
 join the key material.</t> 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 anchor="example-2-multi-domain-with-aaa-infrastructures">
        <name>Example 2: Multi-domain Multiple Domains with AAA infrastructures</name> Infrastructures</name>
        <t>A device (A) of the domain acme.org, which acme.org uses a specific kind of credential (e.g., AKA) and intends to join the um.es domain. This user does not belong to this domain, for which first it first performs a client registration using CoAP-EAP. For To do this, it interacts with the EAP authenticator's domain, which in turn communicates with an a AAA infrastructure (acting as a AAA client). 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. C's domain. In this scenario, the AS under AS, in the role of the EAP authenticator authenticator, receives the key material from the AAA infrastructure</t> 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 anchor="example-3-single-domain-with-aaa-infrastructure">
        <name>Example 3: Single domain Domain with a AAA infrastructure</name>
        <t>As Infrastructure</name>
        <t>In this scenario, a University Campus, with university campus has several Faculty buildings and faculty buildings, where each one building has its criteria or policies in place to manage EAP peers under an AS. All buildings belong to the same domain (e.g., um.es). All these buildings are managed with a AAA infrastructure. A new device (A) with credentials from the domain (e.g., um.es) will be able to perform the device registration with an EAP authenticator (C) of any building if they are managed by the same general domain.</t>
      </section>
      <section anchor="example-4-single-domain-without-aaa-infrastructure">
        <name>Example 4: Single domain without Domain Without a AAA infrastructure</name> Infrastructure</name>
        <t>In another case, without a AAA infrastructure, with an EAP authenticator that has co-located the EAP server, and using EAP standalone mode, all the devices can be managed within the same domain locally. Client registration of an EAP peer (A) with a Controller (C) can also be performed in the same manner.</t>
      </section>
      <section anchor="other-use-cases">
        <name>Other use cases</name> Use Cases</name>
        <section anchor="coap-eap-network-access-control">
          <name>CoAP-EAP for network access authentication</name> Network Access Authentication</name>
          <t>One of the first steps for an EAP peer is to perform the authentication to gain access to the network. To do so, the device first must first be authenticated and granted authorization to gain access to the network. Additionally, security parameters such as credentials can be derived from the authentication process, allowing the trustworthy operation of the EAP peer in a particular network by joining the security domain. By using EAP, this can be achieved with flexibility and scalability, because of the different EAP methods available and the ability to rely on AAA infrastructures if needed to support multi-domain scenarios, which is a key feature when the EAP peers deployed under the same security domain belong, for example, to different organizations.</t>
          <t>In
          <t>The following two cases apply to the process of joining a network, there are two cases: 1) the network:
1)&nbsp;the node does not have an IPv6 address; 2) the node does have has an IPv6 address (e.g., link-local IPv6 or IPv6 global address).</t> address) and 2)&nbsp;the node does not have an IPv6 address.</t>
          <t>In networks where the device is placed, and in place but no IP support is available until the EAP peer is authenticated, specific support for this EAP lower layer 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 KMP Key Management
Protocol (KMP) ID can be defined to add such support in the case of IEEE 802.15.9 <xref target="ieee802159"/>. target="IEEE802159"/>, where it can be assumed that the device has at least a link-layer IPv6 address.

<!-- [rfced] Appendix C.5.1:  We corrected the incomplete
"Where can ..." sentence as follows.  If this change is not correct,
please provide clarifying text.

Original (the previous sentence is included for context):
 For
 example, in IEEE 802.15.4 networks, a new KMP ID can be defined to
 add such support in the case of IEEE 802.15.9 [ieee802159].  Where
 can be assumed that the device has at least a link-layer IPv6 address.</t>
 address.

Currently (now one sentence that includes the expansion for "KMP"):
 For
 example, in IEEE 802.15.4 networks, a new Key Management Protocol
 (KMP) ID can be defined to add such support in the case of IEEE
 802.15.9 [IEEE802159], where it can be assumed that the device has at
 least a link-layer IPv6 address. -->

</t>
          <t>When the EAP peer intends to be admitted into the network, it would search for an entity that offers the CoAP-EAP service, be it directly via the EAP authenticator directly, or through the an intermediary (i.e., proxy). See <xref target="discovery-section"/>.</t>
          <t>CoAP-EAP will run between the EAP peer and the EAP authenticator or through an intermediary entity such as a proxy, as happens in a mesh network, where the EAP authenticator could be placed to 1 one or more hops away from the EAP peer. 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 <xref target="fig-network-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, the
EAP peer can follow the same process as that described in
<xref target="fig-network-proxy"/>.</t>
          <t>Thus, target="proxy"/> 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).

<!-- [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 <xref target="coap-eap-network-access-control"/>
 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.</t> 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, completed and the OSCORE security association is established with the EAP authenticator, the EAP peer receives the local configuration parameters for the network (e.g. (e.g., a network key) and can configure a global IPv6 address. Moreover, there is no need of for a CoAP proxy after a successful authentication.</t>
          <t>For removal, if the EAP authenticator decides to remove a particular 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 express that the network access state is removed, and the device will no longer belong 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 material to the devices that still belong to the network, excluding the removed device, following a similar model as similar to CoJP for 6TiSCH Join Protocol <xref target="RFC9031"/> or Zigbee IP<xref IP <xref target="ZigbeeIP"/>. The specifics on how this process is to be done, is out of done are outside the scope of this document.</t>
          <figure anchor="fig-network-proxy">
            <name>CoAP-EAP through Through CoAP proxy</name> Proxy</name>
            <artset>
              <artwork type="svg" align="center"><svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="144" width="568" viewBox="0 0 568 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 72,32 L 72,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 440,32 L 440,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 144,32 L 216,32" fill="none" stroke="black"/>
                  <path d="M 440,32 L 560,32" fill="none" stroke="black"/>
                  <path d="M 80,64 L 136,64" fill="none" stroke="black"/>
                  <path d="M 224,64 L 432,64" fill="none" stroke="black"/>
                  <path d="M 8,80 L 72,80" fill="none" stroke="black"/>
                  <path d="M 144,80 L 216,80" fill="none" stroke="black"/>
                  <path d="M 440,80 L 560,80" fill="none" stroke="black"/>
                  <path d="M 224,112 L 248,112" fill="none" stroke="black"/>
                  <path d="M 416,112 L 440,112" fill="none" stroke="black"/>
                  <polygon class="arrowhead" points="448,112 436,106.4 436,117.6" fill="black" transform="rotate(0,440,112)"/>
                  <polygon class="arrowhead" points="440,64 428,58.4 428,69.6" fill="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,64 220,58.4 220,69.6" fill="black" transform="rotate(180,224,64)"/>
                  <polygon class="arrowhead" points="144,64 132,58.4 132,69.6" fill="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)"/>
                  <g class="text">
                    <text x="32" y="52">EAP</text>
                    <text x="180" y="52">CoAP</text>
                    <text x="480" y="52">EAP</text>
                    <text x="36" y="68">peer</text>
                    <text x="184" y="68">Proxy</text> y="68">proxy</text>
                    <text x="504" y="68">authenticator</text>
                    <text x="108" y="84">CoAP</text>
                    <text x="324" y="84">CoAP</text>
                    <text x="328" y="100">OSCORE/DTLS</text>
                    <text x="284" y="116">Security</text> y="116">security</text>
                    <text x="368" y="116">Association</text> y="116">association</text>
                  </g>
                </svg>
              </artwork>
              <artwork type="ascii-art" align="center"><![CDATA[
  +-------+        +--------+                           +--------------+
  | EAP   |        |  CoAP  |                           |   EAP        |
  | peer  |<------>|  Proxy  proxy |<------------------------->| authenticator|
  +-------+  CoAP  +--------+           CoAP            +--------------+
                                     OSCORE/DTLS
                             <--(Security Association)-->
                             <--(security association)-->
]]></artwork>
            </artset>
          </figure>

<!-- [rfced] Figure 10:  We see "(security association)" in the ASCII
art but "security association" 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. -->

          <t>Given that EAP is also used for network access authentication, this service can be adapted to other technologies. For technologies -- for instance, to provide network access control to very constrained technologies (e.g., LoRa network). Authors in Long Range (LoRa) networks). The authors of <xref target="lo-coap-eap"/> target="LO-CoAP-EAP"/> provide a study of a minimal version of CoAP-EAP for LPWAN networks LPWANs, with interesting results. In this specific case, the compression as provided by SCHC Static Context Header Compression (SCHC) for CoAP <xref target="RFC8824"/> can be leveraged.</t>
        </section>
        <section anchor="coap-eap-for-service-authentication">
          <name>CoAP-EAP for service authentication</name> Service Authentication</name>
          <t>It is not uncommon that the infrastructure where the device is deployed and the services of the EAP peer are managed by different organizations. Therefore, in addition to the authentication for network access control, the possibility of a secondary authentication to access different services has to be considered. This process of authentication, for example, will provide the necessary key material to establish a secure channel and interact with the entity in charge of granting access to different services.</t>
          <t>In 5G, for example, consider primary and secondary authentication using EAP <xref target="TS133.501"/>.</t>
        </section>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>We would like to thank the reviewers of this work: Paul Wouters, Heikki Vatiainen, Josh Howlett, Deb Cooley, Eliot Lear, Alan DeKok, Carsten Bormann, Mohit Sethi, Benjamin Kaduk, Christian Amsuss, John Mattsson, Goran Selander, Alexandre Petrescu, Pedro Moreno-Sanchez and Eduardo Ingles-Sanchez.</t> <contact
      fullname="Paul Wouters"/>, <contact fullname="Heikki Vatiainen"/>,
      <contact fullname="Josh Howlett"/>, <contact fullname="Deb Cooley"/>,
      <contact fullname="Eliot Lear"/>, <contact fullname="Alan DeKok"/>,
      <contact fullname="Carsten Bormann"/>, <contact fullname="Mohit
      Sethi"/>, <contact fullname="Benjamin Kaduk"/>, <contact
      fullname="Christian Amsüss"/>, <contact fullname="John Preuß Mattsson"/>,
      <contact fullname="Göran Selander"/>, <contact fullname="Alexandre
      Petrescu"/>, <contact fullname="Pedro Moreno-Sanchez"/>, and <contact
      fullname="Eduardo Ingles-Sanchez"/>.</t>
      <t>We would also like to thank Gabriel Lopez-Millan <contact fullname="Gabriel
      Lopez-Millan"/> for the first review of this document, and we would like to thank Ivan Jimenez-Sanchez <contact fullname="Ivan Jimenez-Sanchez"/> for the first
      proof-of-concept implementation of this idea, Julian <contact fullname="Julian
      Niklas Schimmelpfennig Schimmelpfennig"/> for the implementation of the Erbium-based IoT
      device implementation, and Daniel <contact fullname="Daniel Menendez Gonzalez
      Gonzalez"/> for the Python implementation.</t>
      <t>And thank
      <t>Thanks also to <contact fullname="Alexander Pelov"/> and <contact
 fullname="Laurent Toutain"/> for their valuable comments to Alexander Pelov and Laurent Toutain, comments, especially for 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>
  </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>