RFC 9820
Authentication Service Based on the Extensible Authentication Protocol (EAP) for Use with the Constrained Application Protocol (CoAP)
Title Block β¨
Okay bestie, let's get the paperwork out of the way first π This is RFC 9820, published September 2025 as a Standards Track document, which means it's a real Internet standard and not just a suggestion π It's written by R. Marin-Lopez (University of Murcia) and D. Garcia-Carrillo (University of Oviedo). The ISSN is 2070-1721. It doesn't obsolete or update any other RFCs. Part 1 of 9 is the intro, so buckle up π
Quick heads up on the title: it's Authentication Service Based on the Extensible Authentication Protocol (EAP) for Use with the Constrained Application Protocol (CoAP). Yes it's a mouthful, no cap π
Abstract β¨
Okay so this doc is giving: an authentication service that uses CoAP as the transport to carry EAP π¦ It defines an EAP lower layer based on CoAP called "CoAP-EAP" πΈ The main goal is to authenticate a CoAP-enabled IoT device (the EAP peer) that wants to join a security domain run by a Controller (the EAP authenticator) π₯ The second thing it does is derive key material to protect the CoAP messages between them, using OSCORE (Object Security for Constrained RESTful Environments) π So the two of them end up with a security association set up, and that's the whole vibe π
Status of This Memo β¨
This is an Internet Standards Track document π
It's a product of the IETF and represents the consensus of the IETF community π«Ά It got public review and was approved for publication by the IESG (Internet Engineering Steering Group). If you want the deets on Internet Standards, check out Section 2 of RFC 7841 π§
For the current status, errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9820 π
Copyright Notice β¨
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved π
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Read those carefully, bestie, because they spell out your rights and restrictions π Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License π
Table of Contents β¨
Here's the full map, copied exactly so you can find your way around πΊοΈ
1. Introduction
1.1. Requirements Language
2. General Architecture
3. CoAP-EAP Operation
3.1. Discovery
3.2. Flow of Operation (OSCORE Establishment)
3.3. Re-Authentication
3.4. Managing the State of the Service
3.5. Error Handling
3.5.1. EAP Authentication Failure
3.5.2. Non-Responsive Endpoint
3.5.3. Duplicated Message with /.well-known/coap-eap
3.6. Proxy Operation in CoAP-EAP
4. CoAP-EAP Media Type Format
5. CBOR Objects in CoAP-EAP
6. Cipher Suite Negotiation and Key Derivation
6.1. Cipher Suite Negotiation
6.2. Deriving the OSCORE Security Context
7. Discussion
7.1. CoAP as the EAP Lower Layer
7.2. Size of the EAP Lower Layer vs. EAP Method Size
8. Security Considerations
8.1. Use of EAP Methods
8.2. Authorization
8.3. Allowing CoAP-EAP Traffic to Perform Authentication
8.4. Freshness of the Key Material
8.5. Channel-Binding Support
8.6. Additional Security Considerations
9. IANA Considerations
9.1. CoAP-EAP Cipher Suites
9.2. CDDL in CoAP-EAP Information Elements
9.3. The Well-Known URIs Registry
9.4. The EAP Lower Layers Registry
9.5. Media Types Registry
9.6. CoAP Content-Formats Registry
9.7. Resource Type (rt=) Link Target Attribute Values Registry
9.8. Expert Review Instructions
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Flow of Operation (DTLS Establishment)
A.1. Deriving DTLS_PSK and Identity
Appendix B. Using CoAP-EAP for Distributing Key Material for IoT
Networks
Appendix C. Example Use Case Scenarios
C.1. Example 1: CoAP-EAP Using ACE
C.2. Example 2: Multiple Domains with AAA Infrastructures
C.3. Example 3: Single Domain with a AAA Infrastructure
C.4. Example 4: Single Domain Without a AAA Infrastructure
C.5. Other Use Cases
C.5.1. CoAP-EAP for Network Access Authentication
C.5.2. CoAP-EAP for Service Authentication
Acknowledgments
Authors' Addresses1. Introduction πΈ
Okay so this doc specifies an authentication service (an application!) that uses EAP [RFC3748] and is built on top of CoAP [RFC7252]. It's called "CoAP-EAP" π¦ It lets two CoAP endpoints authenticate each other using EAP and set up an OSCORE security association between them π More specifically, it says how CoAP can act as a constrained, link-layer-independent, reliable EAP lower layer [RFC3748], carrying EAP messages between a CoAP server (acting as the EAP peer) and a CoAP client (acting as the EAP authenticator) inside CoAP messages π The CoAP client can optionally contact a backend AAA (Authentication, Authorization, and Accounting) infrastructure to finish the EAP negotiation, as the EAP spec [RFC3748] describes β¨
Now, the EAP methods that can ride on CoAP-EAP MUST export cryptographic material [RFC5247] π Some examples are EAP-GPSK [RFC5433], EAP-SIM [RFC4186], EAP-AKA' [RFC5448], EAP-TLS 1.3 [RFC9190], and EAP-EDHOC [EAP-EDHOC], etc. π§ (CBOR means "Concise Binary Object Representation", just so you know π) Honestly, any EAP method designed in the EAP Method Update (EMU) Working Group that exports the Master Session Key (MSK) can be used with CoAP-EAP π The MSK is the basis for further crypto derivations, so CoAP messages get protected after authentication π‘οΈ Once the CoAP-EAP operation is done, an OSCORE security association exists between the endpoints. You can use that keying material to generate other security associations too. Appendix A shows how to set up a (D)TLS security association using the keying material from the EAP authentication π
Now the IoT part, which is the main reason this exists π IoT networks have very constrained links (think limited bandwidth) and devices with limited capabilities π Here the IoT device is the entity that wants to be authenticated with EAP so it can join a domain managed by a Controller π«Ά The IoT device is the EAP peer, and the Controller is the one steering the authentication (the EAP authenticator). From here on, the IoT device is called the EAP peer and the Controller is called the EAP authenticator π In these setups, EAP methods with fewer exchanges, shorter messages, and crypto algorithms that suit constrained devices are preferable β¨ The benefits of the EAP framework in IoT networks are highlighted in [EAP-Framework-IoT] π¦
1.1. Requirements Language π
Okay, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here π So if you see them in lowercase, they're just regular words, periodt π
Readers are expected to already know the terms and concepts from CoAP [RFC7252], EAP [RFC3748] [RFC5247], and OSCORE [RFC8613] π So brush up on those first, bestie π
2. General Architecture π§
Okay so Figure 1 shows the architecture π¦ Here, the EAP peer acts as a CoAP server for this service, and the domain EAP authenticator acts as a CoAP client π The reason? EAP Requests always travel from the EAP server to the EAP peer, and EAP Responses always travel from the EAP peer to the EAP server. So the roles line up with the message flow π₯
It's worth noting that the EAP authenticator MAY interact with a backend AAA infrastructure when EAP pass-through mode is used. That puts the EAP server in the AAA server, which holds the info needed to authenticate the EAP peer π
The protocol stack is in Figure 2 β¨ CoAP-EAP is an application built on top of CoAP, and on top of the application sits an EAP state machine that can run any EAP method π«Ά For this spec, the EAP method MUST support key derivation and export as specified in [RFC5247]: an MSK of at least 64 octets and an Extended Master Session Key (EMSK) of at least 64 octets π CoAP-EAP also leans on CoAP's reliability mechanisms to carry EAP: either CoAP over UDP with Confirmable messages [RFC7252], or CoAP over TCP, TLS, or WebSockets [RFC8323] π
+--------+ +--------------+ +----------+
| EAP | | EAP | | AAA/ |
| peer |<------>| authenticator|<----------->|EAP server|
+--------+ CoAP +--------------+ AAA +----------+
(optional)
<---- SCOPE OF THIS DOCUMENT ---->
Figure 1: CoAP-EAP Architecture +-----------------------------------+
| EAP State Machine |
+-----------------------------------+
| Application (CoAP-EAP) | <-- This Document
+-----------------------------------+
| Requests / Responses / Signaling | RFC 7252 / RFC 8323
+-----------------------------------+
| Message / Message Framing | RFC 7252 / RFC 8323
+-----------------------------------+
| Unreliable / Reliable Transport | RFC 7252 / RFC 8323
+-----------------------------------+
Figure 2: CoAP-EAP StackPart 1 of 9 is done, bestie π Hit me up for part 2 when you're ready ππ¦
3. CoAP-EAP Operation β¨
Okay so bestie, CoAP-EAP uses reliable delivery as defined in CoAP [RFC7252] [RFC8323], which means EAP retransmission time is set to an infinite value, as mentioned in [RFC3748]. π To keep everything in the right order, CoAP-EAP uses Hypermedia as the Engine of Application State (HATEOAS). π¦ Each step of the EAP authentication accesses a brand-new resource on the CoAP server (the EAP peer). The previous resource gets removed once the new one is created, which tells everyone which resource handles the next step. It's giving breadcrumb trail π
One of the best things about EAP is that we can pick from a huge variety of authentication methods. π Iconic, honestly.
In CoAP-EAP, the EAP peer only has one authentication session with a specific EAP authenticator, and it does not process any other EAP authentication in parallel with that same authenticator. π₯ So a single ongoing EAP authentication is permitted for the same EAP peer and the same EAP authenticator. Worth noting, though: the EAP authenticator is allowed to have parallel EAP sessions with multiple EAP peers. Main character energy for the authenticator π
To access the authentication service, this document defines the well-known URI "coap-eap" (see Section 9.3). π The /.well-known/coap-eap URI is used with "coap", "coap+tcp", or "coap+ws".
3.1. Discovery π
Before the CoAP-EAP exchange happens, the EAP peer needs to discover the EAP authenticator or the entity that will enable the CoAP-EAP exchange (i.e., an intermediary). π§ The discovery process is outside the scope of this document, so we're not going there today.
The CoAP-EAP application can be accessed through the URI "coap-eap" for the trigger message (see Section 3.2, 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 [RFC9176].
Implementation notes: There are different methods 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. So, after receiving the Router Advertisement (RA) messages from the Border Router, the EAP peer may engage in the CoAP-EAP exchange. Bestie, that's the vibe β¨
3.2. Flow of Operation (OSCORE Establishment) π¦
Figure 3 shows the general flow of operation for CoAP-EAP to authenticate using EAP and establish an OSCORE Security Context. π The flow doesn't show a specific EAP method. Instead, the chosen EAP method is represented by 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 the media type "application/coap-eap". See Section 9.5.
The steps for this flow of operation are as follows:
- 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' CoAP option [RFC7967] so it doesn't wait for a response that isn't 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 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 during 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 that the URI is for the EAP peer. This has no meaning for the protocol but helps with debugging.
- "counter" is an incrementing unique number for every new EAP Request.
So, per Figure 3, the URI for the first resource would be "/a/eap/1". π
- 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, or EAP-Req/Id) and the Recipient ID of the EAP authenticator (RID-C) for OSCORE, and MAY 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 Section 6.1. π
- 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-Response/Identity, or EAP-Resp/Id). β¨ Then, the CoAP-EAP application assigns a new resource to the ongoing authentication process (e.g., "/a/eap/2") and deletes the previous one ("/a/eap/1"). Finally, the CoAP-EAP application sends a '2.01 Created' response with the new resource identifier in the Location-Path (and/or Location-Query) Options for the next step. The EAP Response, the Recipient ID of the EAP peer (RID-I), and the selected cipher suite for OSCORE (CS-I) are included in the payload. In this step, the EAP peer MAY create an OSCORE Security Context (see Section 6.2). The required MSK will be available once the EAP authentication is successful (Step 7). π₯
- Steps 3-6. From now on, the EAP authenticator and the EAP peer exchange EAP packets related to the EAP method (EAP-X), transported in the CoAP message payload. The EAP authenticator uses the POST method to send EAP Requests to the EAP peer. The EAP peer uses a CoAP response to carry the EAP Response in the payload. EAP Requests and responses are represented in Figure 3 as "EAP-X-Req" and "EAP-X-Resp", respectively. When a POST message arrives (e.g., "/a/eap/1") carrying an EAP Request message, and it's 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. That's how ordering guarantees are achieved, periodt. Finally, an EAP Response is sent in the payload of a CoAP response that also indicates the new resource in the Location-Path (and/or Location-Query) Options. If an error occurs while processing a legitimate message, the server MUST return a '4.00 Bad Request'. Error handling is discussed in Section 3.5. π
Hmm, wait, I need to correct something in the bullet above: the original says the server "will return" a '4.00 Bad Request', so that wording must not be a MUST. Here is the faithful version of that sentence:
If an error occurs while processing a legitimate message, the server will return a '4.00 Bad Request'. Error handling is discussed in Section 3.5. π
- Step 7. When the EAP authentication ends successfully, the EAP authenticator obtains the MSK exported by the EAP method, an EAP Success message, and some authorization information [RFC5247] (e.g., Session-Lifetime). π The EAP authenticator creates the OSCORE Security Context using the MSK and the Recipient IDs of both entities exchanged in Steps 1 and 2. The establishment of the OSCORE Security Context is defined in Section 6.2. Then, the EAP authenticator sends the POST message protected with OSCORE for key confirmation, including the EAP Success. The EAP authenticator MAY also send a Session-Lifetime, in seconds, which is represented by an unsigned integer in a CBOR Object (see Section 5). If this Session-Lifetime is not sent, the EAP peer assumes a default value of 8 hours, as RECOMMENDED in [RFC5247]. The reception of the OSCORE-protected POST message is considered by the EAP peer as an alternate indication of success [RFC3748]. The EAP peer state machine 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. π§
- Step 8. If the EAP authentication and the verification of the OSCORE-protected POST (Step 7) are successful, then the EAP peer answers with an OSCORE-protected '2.04 Changed'. From this point on, communication with the last resource (e.g., "/a/eap/(n)") MUST be protected with OSCORE. If allowed by application policy, the same OSCORE Security Context MAY be used to protect communication to other resources between the same endpoints. π
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 | v
| Payload(EAP Success||*Session-Lifetime)| OSCORE
MSK 7)|<----------------------------------------| CTX
| | |
v | 2.04 Changed |
OSCORE | OSCORE |
CTX 8)|---------------------------------------->|
*Session-Lifetime is optional
Figure 3: CoAP-EAP Flow of Operation with OSCOREHold up, I got sloppy in that last bit, so let me fix the Step 3-6 bullet and the Step 7 bullet properly. The original wording is "will" not "MUST" for the server error, and the Step 3-6 text is what the original says. Here is the corrected version of the whole section so nothing is changed in force:
- Steps 3-6. From now on, the EAP authenticator and the EAP peer exchange EAP packets related to the EAP method (EAP-X), transported in the CoAP message payload. π¦ The EAP authenticator uses the POST method to send EAP Requests to the EAP peer. The EAP peer uses a CoAP response to carry the EAP Response in the payload. EAP Requests and responses are represented in Figure 3 as "EAP-X-Req" and "EAP-X-Resp", respectively. When a POST message arrives (e.g., "/a/eap/1") carrying an EAP Request message, and it's 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. That's how ordering guarantees are achieved, periodt. Finally, an EAP Response is sent in the payload of a CoAP response that also indicates the new resource in the Location-Path (and/or Location-Query) Options. If an error occurs while processing a legitimate message, the server will return a '4.00 Bad Request'. Error handling is discussed in Section 3.5. π
Sorry bestie, I also slipped a MUST into the Step 3-6 bullet earlier, which was wrong. The keyword list in the original is the source of truth, so the corrected bullet above is the one to use. Everything else in this part stays as it is. π
3.3. Re-Authentication π
okay so when the CoAP-EAP state is getting close to expiring, the EAP peer might wanna start a new authentication process (re-authentication) to renew the state π . the main goal is getting fresh keying material (MSK/EMSK), which then lets you derive a brand new OSCORE Security Context. that means a leaked key doesn't stay useful forever π. the keying material MUST be renewed before the Session-Lifetime expires π¨. by default, the EAP key management framework [RFC5247] sets 8 hours as the refresh default β°. some EAP methods, like Nimble Out-of-Band Authentication for EAP (EAP-NOOB) [RFC9140] or EAP-AKA' [RFC5448], offer fast reconnect so re-auth goes quicker πββοΈ. the EAP Re-authentication Protocol (ERP) [RFC6696] MAY also be used to skip repeating the whole EAP exchange β¨.
the re-authentication message flow is the same as the one in Figure 3 π. the difference is that two CoAP-EAP states are active at once during re-auth: the current CoAP-EAP state and the new CoAP-EAP state, which gets created once re-auth has finished successfully π¦. once re-auth is completed successfully, the current CoAP-EAP state is deleted and replaced by the new one. if re-auth fails for any reason, the current CoAP-EAP state stays usable until it expires, or it gets renewed during a later re-authentication attempt πΈ.
if re-auth fails, it's up to the EAP peer to decide when to start a new re-authentication before the current EAP state expires π«Ά.
3.4. Managing the State of the Service ποΈ
the EAP peer and the EAP authenticator both keep state during the CoAP-EAP negotiation π€. the CoAP-EAP state has a few important parts:
- A reference to an instance of the EAP (peer or authenticator/server) state machine.
- The resource for the next message in the negotiation (e.g.,
"/a/eap/2"). - The MSK, which is exported when the EAP authentication is successful. CoAP-EAP can access the different variables via the EAP state machine (see [RFC4137]).
- A reference to the OSCORE context.
once it's created, the EAP authenticator MAY choose to delete the state, as shown in Figure 4 ποΈ. on the flip side, the EAP peer may need to renew the CoAP-EAP state because the key material is close to expiring, as mentioned in Section 3.3 β³.
there are situations where the current CoAP-EAP state might need to be removed π. for example, because it expired or was forcibly removed, the EAP peer has to be kicked out of the security domain πͺ. that exchange is illustrated in Figure 4 π.
if the EAP authenticator decides it needs 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. the request references the last CoAP-EAP state resource given by the CoAP server, and its identifier will be the last one received (e.g., "/a/eap/(n)" in Figure 3) π¨. this message is protected by the OSCORE security association to prevent forgery π. when the CoAP server gets this message, it sends back a response to the EAP authenticator with the code '2.02 Deleted', which is also protected by the OSCORE security association β
. if no response from the EAP peer arrives after EXCHANGE_LIFETIME, the EAP authenticator removes the state π§Ή.
EAP peer EAP authenticator
------------- -------------
| |
| DELETE /a/eap/(n) |
| OSCORE |
|<--------------------------------------|
| |
| 2.02 Deleted |
| OSCORE |
|-------------------------------------->|Figure 4: Deleting State
3.5. Error Handling π
this section walks through how different errors get handled: EAP authentication failure (Section 3.5.1), a non-responsive endpoint (Section 3.5.2), and duplicated messages (Section 3.5.3) π§©.
3.5.1. EAP Authentication Failure π ββοΈ
EAP authentication can fail in different situations (e.g., wrong credentials) β. the result is that the EAP authenticator sends an EAP Failure message because the EAP authentication failed (Step 7 in Figure 3). in this case, the EAP peer MUST send a response '4.01 Unauthorized' in Step 8. so Steps 7 and 8 aren't protected here, because no MSK gets exported and the OSCORE Security Context hasn't been generated yet π«£.
if EAP authentication fails during re-authentication and the EAP authenticator sends an EAP Failure, the current CoAP-EAP state is still usable until it expires π.
3.5.2. Non-Responsive Endpoint π΄
if for any reason one of the entities goes non-responsive, the CoAP-EAP state SHOULD be removed after a stipulated amount of time β±οΈ. that amount of time can be adjusted to match the policies set by the application or use case where CoAP-EAP is used π―. as a default value, the CoAP EXCHANGE_LIFETIME parameter, as defined in CoAP [RFC7252], gets used π.
removing the CoAP-EAP state in the EAP authenticator assumes that the EAP peer will need to authenticate again π.
according to CoAP, EXCHANGE_LIFETIME covers the time it takes until a client stops expecting a response to a request β. a timer gets reset every time a message is sent β²οΈ. by default, CoAP-EAP uses the EXCHANGE_LIFETIME value as a timer in both the EAP peer and the EAP authenticator. if the authentication process hasn't finished within that time, the CoAP-EAP state gets removed π§Ό.
the EAP peer removes the CoAP-EAP state if either EXCHANGE_LIFETIME triggers or the EAP peer state machine returns an eapFail π.
the EAP authenticator removes the CoAP-EAP state if either EXCHANGE_LIFETIME triggers or, when the EAP authenticator is running in pass-through mode (i.e., the EAP authentication is performed against a AAA server), the EAP authenticator state machine returns "aaaTimeout" [RFC4137] π.
3.5.3. Duplicated Message with /.well-known/coap-eap π―
the trigger message (Step 0 in Figure 3) that contains the URI /coap-eap needs some extra thought, because that resource is always available on the EAP authenticator π.
if a trigger message shows up at the EAP authenticator during an ongoing authentication with the same EAP peer, the EAP authenticator MUST silently discard it π€«.
if an old "POST /.well-known/coap-eap" (Step 0 in Figure 5) arrives at the EAP authenticator and no authentication is ongoing, the EAP authenticator may understand that a new authentication process is requested. so the EAP authenticator starts a new EAP authentication π. however, if the EAP peer didn't start any authentication, it sends back a '4.04 Not Found' in the response (Figure 5) π.
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 |
|---------------------------------------->|
*OldFigure 5: /.well-known/coap-eap with No Ongoing Authentication from the EAP Authenticator
3.6. Proxy Operation in CoAP-EAP πΈ
CoAP-EAP is meant to play nicely with intermediary entities between the EAP peer and the EAP authenticator, for when direct communication isn't possible π€. in this setup, CoAP proxies can be used as enablers of the CoAP-EAP exchange π§.
this specification sticks to standard CoAP [RFC7252] and standardized CoAP options [RFC8613] π. it doesn't define any new CoAP options. that's expected to make it easier to bring CoAP intermediaries into the CoAP-EAP exchange π .
when you use proxies in the CoAP-EAP exchange, you should keep in mind that the exchange includes a role reversal at the beginning π. in the first message, the EAP peer acts as a CoAP client and the EAP authenticator acts as the CoAP server. in the remaining exchanges the roles flip: the EAP peer acts as the CoAP server, and the EAP authenticator acts as the CoAP client πͺ. when a proxy is in the exchange, it acts as a forward proxy for message 0, and as a reverse proxy for the rest π.
also, 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. that's not typical behavior, because URIs for new services/resources usually show up in Location-Path and/or Location-Query Options in CoAP responses π. so the proxy has to treat the payload of Message 0 as if it were a Location-Path Option of a CoAP response π§ .
4. CoAP-EAP Media Type Format β¨
in the CoAP-EAP exchange, the format specified by the "application/coap-eap" media type gets used π¦. see Section 9.5 π.
CoAP-EAP can send two different things in the payload π. the first one is a relative URI. that payload is present for the first message (0) in Figure 3 πΊοΈ.
in every other case, an EAP message is followed by the CBOR Object specified in Section 5 π§. a visual example of that second case is in Figure 7 (Section 6.1) π.
5. CBOR Objects in CoAP-EAP β¨
okay so during the CoAP-EAP exchange, the two sides need to swap some info π«Ά like which cipher suites to negotiate, or authorization stuff like Session-Lifetime. And we might wanna add more stuff later, so this section defines a CBOR data structure [RFC8949] that the EAP peer and EAP authenticator use to pass info around in the CoAP payload π
Figure 6 shows the CBOR Object for this:
CoAP-EAP_Info = {
? 1 : [+ int], ; Cipher Suite (CS-C or CS-I)
? 2 : bstr, ; RID-C
? 3 : bstr, ; RID-I
? 4 : uint ; Session-Lifetime
}Figure 6: CBOR Data Structure for CoAP-EAP
The parameters hold the following info π
- Cipher Suite: an array listing the COSE algorithms (CBOR Object Signing and Encryption) for OSCORE that are either proposed or selected π. If it rides along in a request, it's a proposal. If it rides along in a response, it's the agreed-upon cipher suite β¨.
- 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 π¦.
- 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 πΈ.
- Session-Lifetime: how long the session is valid, in seconds β³.
Other indexes can be used to carry extra values whenever they're needed, like specific authorization parameters π§.
The indexes from 65001 to 65535 are reserved for experimentation π§ͺ.
6. Cipher Suite Negotiation and Key Derivation π
6.1. Cipher Suite Negotiation
OSCORE runs after the EAP authentication, using whichever cipher suite gets picked during the cipher suite negotiation (Steps 1 and 2 in Figure 3) π. The negotiation is pretty simple, honestly π. The EAP authenticator sends a list, ordered from most to least preferred, with the identifiers of the cipher suites it supports (Step 1 in Figure 8). Then the EAP peer replies with its choice (Step 2 in Figure 8) π.
That list goes into the payload after the EAP message as a CBOR array. Figure 7 shows how the fields are laid out in the CoAP payload, and Figure 8 shows an example of the whole cipher suite negotiation. Both the EAP Request (EAP-Req/Id) and EAP Response (EAP-Resp/Id) carry the CBOR Object (Section 5) with the cipher suite field in it π.
+------+------------+--------+------+-----------------+
| Code | Identifier | Length | Data | cipher suites |
+------+------------+--------+------+-----------------+
<---------- EAP Packet ----------> <-- CBOR array -->Figure 7: Cipher Suites in the CoAP Payload
EAP peer EAP 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)|---------------------------------------->|
...Figure 8: Cipher Suite Negotiation
If there's no CBOR array specifying the cipher suites, the default cipher suites get applied π. If the EAP authenticator sends a restricted list of cipher suites it's willing to accept, it MUST include the default value 0, since that one is mandatory to implement. That way the EAP peer always has at least one option available π«Ά.
The cipher suite requirements come from the ones OSCORE set [RFC8613], which are COSE algorithms [RFC9053]. By default, the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) uses SHA-256, and the Authenticated Encryption with Associated Data (AEAD) algorithm is AES-CCM-16-64-128 [RFC9053]. (HMAC stands for "Hashed Message Authentication Code", in case you were wondering π€.) Both of those are mandatory to implement π . Here are the other supported and negotiated cipher suites. The hash algorithms are included for cases where the specification adds DTLS support later (TLS_SHA256, TLS_SHA384, TLS_SHA512; see Appendix A) β¨:
- 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
This specification uses the HKDF defined in [RFC5869] to derive the key material it needs π. Since the key derivation uses the MSK, which counts as fresh key material, only the HKDF-Expand function (shortened here to "KDF") gets used. Section 8.1 explains why that's enough and why KDF-Extract isn't needed π§ .
6.2. Deriving the OSCORE Security Context
Deriving the OSCORE Security Context is what lets the EAP peer and EAP authenticator secure their communication once the MSK has been exported π. It gives you confidentiality, integrity, key confirmation (Steps 7 and 8 in Figure 3), and detection of downgrading attacks π‘οΈ.
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 [RFC8613]). It should be noted that the ID Context is not provided for the OSCORE Security Context derivation π.
The Master Secret can be derived with the chosen cipher suite and the KDF like this π§:
Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length)where:
- The MSK is exported by the EAP method. The use of the MSK for key derivation is discussed in Section 8.
- CS is the concatenation of the content of the cipher suite negotiation, meaning the concatenation of two CBOR arrays CS-C and CS-I (with CBOR ints as elements), as defined in Section 5. 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).
- "COAP-EAP OSCORE MASTER SECRET" is the ASCII code representation of the non-NULL-terminated string (excluding the double quotes around it).
- CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated.
- length is the size of the output key material.
The Master Salt works the same way π·:
Master Salt = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SALT", length)where:
- The MSK is exported by the EAP method. The use of the MSK for key derivation is discussed in Section 8.
- CS is the concatenation of the content of the cipher suite negotiation, meaning the concatenation of two CBOR arrays CS-C and CS-I (with CBOR ints as elements), as defined in Section 5. 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).
- "COAP-EAP OSCORE MASTER SALT" is the ASCII code representation of the non-NULL-terminated string (excluding the double quotes around it).
- CS and "COAP-EAP OSCORE MASTER SALT" are concatenated.
- length is the size of the output key material.
Since the MSK is used to derive the Master Key, correctly verifying the OSCORE-protected request (Step 7) and response (Step 8) confirms that the EAP authenticator and the EAP peer have the same Master Secret. That's the key confirmation π₯³.
To prevent a downgrading attack, the cipher suite negotiation content (referred to here as "CS") gets embedded in the Master Secret derivation π΅οΈββοΈ. If an attacker changes the value of the cipher suite negotiation, the result is different OSCORE Security Contexts, which then cause failures in Steps 7 and 8. Caught you, bestie π«.
The EAP authenticator uses the Recipient ID of the EAP peer (RID-I) as the Sender ID for its OSCORE Sender Context. The EAP peer uses this value as the Recipient ID for its Recipient Context π¦.
The EAP peer uses the Recipient ID of the EAP authenticator (RID-C) as the Sender ID for its OSCORE Sender Context. The EAP authenticator uses this value as the Recipient ID for its Recipient Context πΈ.
7. Discussion π
7.1. CoAP as the EAP Lower Layer π
okay so this section is where we check whether CoAP is actually a good fit to carry EAP π It's giving "does this protocol pass the vibe check," and the vibe check is EAP's list of demands for its lower layers. You can find those in Section 3.1 of [RFC3748], and here's the breakdown, bestie π«Ά
- Unreliable transport: EAP doesn't assume its lower layers are reliable, but it can benefit from a reliable one π‘οΈ CoAP has its own reliability mechanism (for example, using Confirmable messages), so that's a W.
- Lower-layer error detection: EAP leans on the lower layer to catch errors (CRC, checksum, Message Integrity Check (MIC), etc.) π To keep things simple, CoAP-EAP hands error detection off to the lower layers, like the link layer or transport layer (for example, UDP over IPv6 or TCP).
- Lower-layer security: EAP does not require security services from the lower layers. No cap, it's not picky about this one π
- Minimum MTU: 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, and that covers EAP's needs when the CoAP payload carries only the EAP message. Messages 1 and 2 in Figure 3 carry extra info on top of EAP, though. The EAP-Req/Id has a fixed length of 5 bytes. Message 2, which holds the EAP-Resp/Id, limits the identity you can use to the CoAP payload maximum size (1024) minus
len( CS-I || RID-I )minus the EAP Response header (5 bytes). That still leaves plenty of room for even lengthy identities β¨ And if you do need more room, CoAP block-wise transfers [RFC7959] can get past this limit.
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. In Diameter, the Framed-MTU Attribute-Value Pair (AVP) with a value of 1024 does the job. This tells the AAA server to keep its responses to 1024 octets, which is very much the main character energy of signaling π¬
- Ordering guarantees: EAP depends on its lower layer for correct ordering π’ Every time a new message shows up at the authentication service hosted by the EAP peer, a new resource gets created. That's announced with a
2.01 Createdresponse code, along with the name of the new resource in Location-Path or Location-Query Options. So the application shows that its state has moved forward, and it's honestly so iconic π
Now here's the tea on duplicates. [RFC3748] says that "EAP provides its own support for duplicate elimination and retransmission," but EAP still relies on lower-layer ordering guarantees too π€ On possible duplication, [RFC3748] 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." CoAP gives a non-duplicated stream of packets and gets that desirable non-duplication done β Also, [RFC3748] says that when EAP runs over a reliable lower layer, "the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer." Reliability is handled one layer down, so EAP doesn't need to retransmit on its own π
7.2. Size of the EAP Lower Layer vs. EAP Method Size π¦
okay, so how many bytes does the lower layer add to the whole authentication exchange? [CoAP-EAP] compares it against another network-layer-based EAP lower layer, the Protocol for Carrying Authentication for Network Access (PANA) defined in [RFC5191] π
The EAP method being carried takes up most of the exchange π₯Ή But the lower layer still matters, especially on very constrained technologies with limited capabilities (like the ones you'll find in IoT networks). Every byte counts there π
Note: To improve efficiency in environments with constrained devices and networks, the latest versions of EAP methods (for example, EAP-AKA' [RFC5448], EAP-TLS 1.3 [RFC9190]) are recommended over older versions. EAP methods better suited to IoT networks (for example, EAP-NOOB [RFC9140], EAP-EDHOC [EAP-EDHOC], etc.) are also recommended.
8. Security Considerations β¨
okay, this part is serious, bestie π Security aspects include how authorization is managed, how the MSK is used as key material, and how trust in the EAP authenticator is established π There's also EAP channel binding as per [RFC6677], which gets discussed here too.
8.1. Use of EAP Methods π
This document only lets you use EAP methods that comply with [RFC4017], and those give you strong and fresh session keys like the MSK πͺ Because of that assumption, the HKDF-Expand function gets used directly, as clarified in [RFC5869].
8.2. Authorization πͺͺ
Authorization is part of bootstrapping, and it decides whether the EAP peer can join and which conditions it has to follow π The authorization data gets gathered from the organization responsible for the EAP peer, and it's sent to the EAP authenticator if a AAA infrastructure is deployed.
In standalone mode, the authorization info lives in the EAP authenticator. In pass-through mode, authorization data received from the AAA server can be delivered by the AAA protocol (for example, RADIUS or Diameter). If you want more fine-grained authorization data, you can transport it with the Security Assertion Markup Language (SAML) in RADIUS [RFC7833] π After bootstrapping, the device may still need extra authorization info to operate in the security domain. The Authentication and Authorization for Constrained Environments (ACE) WG's solutions can handle that, such as using OAuth [RFC9200], among other solutions to provide ACE.
8.3. Allowing CoAP-EAP Traffic to Perform Authentication π¦
CoAP is an application protocol, so CoAP-EAP assumes certain IP connectivity on the link between the EAP peer and the EAP authenticator in order to run π 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. Once authentication succeeds, the key material generated by the EAP authentication (MSK) and any other traffic can be authorized if it's protected. Worth noting: if the EAP authenticator isn't on the same link as the EAP peer and an intermediate entity (for example, a CoAP proxy) helps with the process, this concept also applies to the communication between the EAP peer and the intermediary π§
Alternatively, the link layer MAY provide support for transporting CoAP-EAP without an IP address, by using link-layer frames (for example, by defining a new Key Management Protocol ID per IEEE 802.15.9 [IEEE802159]) π¦
8.4. Freshness of the Key Material πΈ
In CoAP-EAP, there's no nonce exchange to provide freshness to the keys derived from the MSK π The MSKs and EMSKs are fresh key material per [RFC5247]. Since only one authentication gets established per EAP authenticator, there's no need to generate additional key material. If a new MSK is required, you can run a re-authentication by running the process again, or by using a more lightweight EAP method to derive additional key material, as elaborated in Section 3.3 β³
8.5. Channel-Binding Support π
According to [RFC6677], channel binding, as it relates to EAP, is sent through the EAP method that supports it π«Ά
To satisfy the requirements of this document, the EAP lower-layer identifier for CoAP-EAP (10, as assigned by IANA; see Section 9.4) needs to be sent in the EAP Lower-Layer Attribute if RADIUS is used π·οΈ
8.6. Additional Security Considerations π
In the authentication process, an entity can forge messages to launch denial-of-service (DoS) attacks on any of the entities involved. For example, an attacker can forge multiple initial messages to start an authentication (Step 0 in Figure 3) with the EAP authenticator, as if they were sent by different EAP peers. So the EAP authenticator will start an authentication process for every message received in Step 0, and it sends the EAP-Req/Id (Step 1). Not okay, honestly π€
To minimize the effects of this DoS attack, it is RECOMMENDED that the EAP authenticator limit the rate at which it processes incoming messages in Step 0, for robustness against DoS attacks. The details of rate limiting are outside the scope of this specification. The rate of these messages is also limited by the bandwidth available between the EAP peer and the EAP authenticator, and that bandwidth is especially limited on constrained links (for example, Low-Power WANs (LPWANs)) π Lastly, it is also RECOMMENDED to reduce the state in the EAP authenticator to a minimum, at least until the EAP-Resp/Id is received by the EAP authenticator π§Ή
Another security concern is how to make sure the EAP peer joining the security domain can trust the EAP authenticator. This issue is elaborated in [RFC5247]. The EAP peer knows it can trust the EAP authenticator because the key used to establish the security association is derived from the MSK. If the EAP authenticator has the MSK, it's because the AAA server of the EAP peer trusted the EAP authenticator π‘οΈπ
9. IANA Considerations π
9.1. CoAP-EAP Cipher Suites π§
IANA has created a new registry titled "CoAP-EAP Cipher Suites" under a new registry group named "CoAP-EAP". The registration procedures are "Specification Required", "Private Use", and "Standards Action with Expert Review" (see [RFC8126]), as shown in Table 1 π
+===============+=====================================+
| Range | Registration Procedures |
+===============+=====================================+
| -65536 to -25 | Specification Required |
+---------------+-------------------------------------+
| -24 to -21 | Private Use |
+---------------+-------------------------------------+
| -20 to 23 | Standards Action with Expert Review |
+---------------+-------------------------------------+
| 24 to 65535 | Specification Required |
+---------------+-------------------------------------+
Table 1: Registration Procedures for CoAP-EAP
Cipher SuitesThe columns of the registry are Value, Algorithms, Description, and Reference. Value is an integer, and the other columns are text strings. The initial registrations are shown in Table 2 π
+=======+============+=============================+===========+
| Value | Algorithms | Description | Reference |
+=======+============+=============================+===========+
| 0 | 10, -16 | AES-CCM-16-64-128, SHA-256 | RFC 9820 |
+-------+------------+-----------------------------+-----------+
| 1 | 1, -16 | A128GCM, SHA-256 | RFC 9820 |
+-------+------------+-----------------------------+-----------+
| 2 | 3, -43 | A256GCM, SHA-384 | RFC 9820 |
+-------+------------+-----------------------------+-----------+
| 3 | 24, -16 | ChaCha20/Poly1305, SHA-256 | RFC 9820 |
+-------+------------+-----------------------------+-----------+
| 4 | 24, -45 | ChaCha20/Poly1305, SHAKE256 | RFC 9820 |
+-------+------------+-----------------------------+-----------+
Table 2: CoAP-EAP Cipher Suites: Initial Registrations9.2. CDDL in CoAP-EAP Information Elements β¨
okay so IANA made a brand new registry called "CoAP-EAP Information Elements" π and it lives under a brand new registry group called "CoAP-EAP" π¦. The registration procedures are "Standards Action with Expert Review", "Private Use", "Specification Required", and "Experimental Use" (see [RFC8126]), and Table 3 is the cute little map of which number range gets which procedure π
+================+=====================================+
| Range | Registration Procedures |
+================+=====================================+
| 0 to 23 | Standards Action with Expert Review |
+----------------+-------------------------------------+
| 24 to 49 | Private Use |
+----------------+-------------------------------------+
| 50 to 65000 | Specification Required |
+----------------+-------------------------------------+
| 65001 to 65535 | Experimental Use |
+----------------+-------------------------------------+
Table 3: Registration Procedures for CoAP-EAP
Information ElementsThe columns of the registry are Name, Label, CBOR Type, Description, and Reference πΈ Label is an integer and everything else is a text string, bestie. The initial registrations are in Table 4 π
+==================+=======+========+===============+===========+
| Name | Label | CBOR | Description | Reference |
| | | Type | | |
+==================+=======+========+===============+===========+
| Cipher Suite | 1 | CBOR | List of the | RFC 9820 |
| | | Array | proposed or | |
| | | | selected COSE | |
| | | | algorithms | |
| | | | for OSCORE | |
+------------------+-------+--------+---------------+-----------+
| RID-C | 2 | Byte | Contains the | RFC 9820 |
| | | String | Recipient ID | |
| | | | of the EAP | |
| | | | authenticator | |
+------------------+-------+--------+---------------+-----------+
| RID-I | 3 | Byte | Contains the | RFC 9820 |
| | | String | Recipient ID | |
| | | | of the EAP | |
| | | | peer | |
+------------------+-------+--------+---------------+-----------+
| Session-Lifetime | 4 | uint | Contains the | RFC 9820 |
| | | | time that the | |
| | | | session is | |
| | | | valid, in | |
| | | | seconds | |
+------------------+-------+--------+---------------+-----------+
Table 4: CoAP-EAP Information Elements: Initial Registrations9.3. The Well-Known URIs Registry π¦
IANA has added the well-known URI coap-eap to the "Well-Known URIs" registry under the "Well-Known URIs" registry group defined by [RFC8615] β¨
URI Suffix: coap-eap
Reference: RFC 9820
Status: permanent
Change Controller: IETF9.4. The EAP Lower Layers Registry π
IANA has added the identifier "CoAP-EAP" to the "EAP Lower Layers" registry (defined by [RFC6677]) under the "Extensible Authentication Protocol (EAP) Registry" π
Value: 10
Lower Layer: CoAP-EAP
Reference: RFC 98209.5. Media Types Registry π
IANA has added the media type application/coap-eap to the "Media Types" registry, and Section 4 is where the format gets defined π«Ά
Type name: application
Subtype name: coap-eap
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: See Section 8 of RFC 9820.
Interoperability considerations: N/A
Published specification: RFC 9820
Applications that use this media type: To be identified
Fragment identifier considerations: N/A
Additional information:
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person and email address to contact for further information:
ace@ietf.org
Intended usage: COMMON
Restrictions on usage: N/A
Author: See the "Authors' Addresses" section of RFC 9820.
Change Controller: IETF9.6. CoAP Content-Formats Registry π
IANA has added the media type application/coap-eap to the "CoAP Content-Formats" registry under the "Constrained RESTful Environments (CoRE) Parameters" registry group, following the specification in Section 12.3 of [RFC7252] π₯ Table 5 shows the entry:
+======================+==================+=====+===========+
| Media Type | Content Encoding | ID | Reference |
+======================+==================+=====+===========+
| application/coap-eap | - | 269 | RFC 9820 |
+----------------------+------------------+-----+-----------+
Table 5: CoAP Content-Formats Registry9.7. Resource Type (rt=) Link Target Attribute Values Registry π
IANA has added the resource type core.coap-eap to the "Resource Type (rt=) Link Target Attribute Values" registry under the "Constrained RESTful Environments (CoRE) Parameters" registry group π§
+===============+===================+===========+
| Value | Description | Reference |
+===============+===================+===========+
| core.coap-eap | CoAP-EAP resource | RFC 9820 |
+---------------+-------------------+-----------+
Table 6: Resource Type (rt=) Link Target
Attribute Values Registry9.8. Expert Review Instructions π«Ά
The IANA registries established in this document apply the "Specification Required", "Private Use", "Standards Action with Expert Review", and "Experimental Use" policies π (See also [RFC8126].) This section gives general guidelines for what experts should focus on, but since they're designated experts for a reason, they should be granted flexibility β¨
- When defining the use of CoAP-EAP Information 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 whether the values are clear, 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. Experts are also expected to verify that IE values are protected from unauthorized modification or misuse during transmission.
- When adding new cipher 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.
10. References π
10.1. Normative References πΈ
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, <https://www.rfc-editor.org/info/rfc5247>.
[RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, <https://www.rfc-editor.org/info/rfc6677>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.
10.2. Informative References
Okay bestie, here's the background reading pile πβ¨ These are the "good to know" references that give the context, all kept exactly as they're listed below π
[CoAP-EAP] Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP-
Based Bootstrapping Service for the Internet of Things",
Sensors, vol. 16, no. 3, DOI 10.3390/s16030358, 2016,
<https://www.mdpi.com/1424-8220/16/3/358>.
[EAP-EDHOC]
Garcia-Carrillo, D., Marin-Lopez, R., Selander, G., PreuΓ
Mattsson, J., and F. Lopez-Gomez, "Using the Extensible
Authentication Protocol (EAP) with Ephemeral Diffie-
Hellman over COSE (EDHOC)", Work in Progress, Internet-
Draft, draft-ietf-emu-eap-edhoc-05, 30 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-
edhoc-05>.
[EAP-Framework-IoT]
Sethi, M. and T. Aura, "Secure Network Access
Authentication for IoT Devices: EAP Framework vs.
Individual Protocols", IEEE Communications Standards
Magazine, vol. 5, no. 3, pp. 34-39,
DOI 10.1109/MCOMSTD.201.2000088, 2021,
<https://ieeexplore.ieee.org/document/9579387>.
[IEEE802159]
IEEE, "IEEE Standard for Transport of Key Management
Protocol (KMP) Datagrams", IEEE Std 802.15.9-2021,
DOI 10.1109/IEEESTD.2022.9690134, January 2022,
<https://doi.org/10.1109/IEEESTD.2022.9690134>.
[LO-CoAP-EAP]
Garcia-Carrillo, D., Marin-Lopez, R., Kandasamy, A., and
A. Pelov, "A CoAP-Based Network Access Authentication
Service for Low-Power Wide Area Networks: LO-CoAP-EAP",
Sensors, vol. 17, no. 11, DOI 10.3390/s17112646, 2017,
<https://www.mdpi.com/1424-8220/17/11/2646>.
[RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March
2005, <https://www.rfc-editor.org/info/rfc4017>.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137,
DOI 10.17487/RFC4137, August 2005,
<https://www.rfc-editor.org/info/rfc4137>.
[RFC4186] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible
Authentication Protocol Method for Global System for
Mobile Communications (GSM) Subscriber Identity Modules
(EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006,
<https://www.rfc-editor.org/info/rfc4186>.
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
Pre-Shared Key Extensible Authentication Protocol (EAP)
Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,
<https://www.rfc-editor.org/info/rfc4764>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>.
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication
Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method",
RFC 5433, DOI 10.17487/RFC5433, February 2009,
<https://www.rfc-editor.org/info/rfc5433>.
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, DOI 10.17487/RFC5448, May 2009,
<https://www.rfc-editor.org/info/rfc5448>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed.,
"EAP Extensions for the EAP Re-authentication Protocol
(ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012,
<https://www.rfc-editor.org/info/rfc6696>.
[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
RADIUS Attribute, Binding, Profiles, Name Identifier
Format, and Confirmation Methods for the Security
Assertion Markup Language (SAML)", RFC 7833,
DOI 10.17487/RFC7833, May 2016,
<https://www.rfc-editor.org/info/rfc7833>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824,
DOI 10.17487/RFC8824, June 2021,
<https://www.rfc-editor.org/info/rfc8824>.
[RFC9031] VuΔiniΔ, M., Ed., Simon, J., Pister, K., and M.
Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
RFC 9031, DOI 10.17487/RFC9031, May 2021,
<https://www.rfc-editor.org/info/rfc9031>.
[RFC9053] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053,
August 2022, <https://www.rfc-editor.org/info/rfc9053>.
[RFC9140] Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band
Authentication for EAP (EAP-NOOB)", RFC 9140,
DOI 10.17487/RFC9140, December 2021,
<https://www.rfc-editor.org/info/rfc9140>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<https://www.rfc-editor.org/info/rfc9147>.
[RFC9176] AmsΓΌss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
P. van der Stok, "Constrained RESTful Environments (CoRE)
Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
2022, <https://www.rfc-editor.org/info/rfc9176>.
[RFC9190] PreuΓ Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the
Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>.
[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>.
[TS133.501]
ETSI, "5G; Security architecture and procedures for 5G
System", V18.9.0, ETSI TS 133 501, April 2025,
<https://www.etsi.org/deliver/
etsi_ts/133500_133599/133501/18.09.00_60/
ts_133501v180900p.pdf>.Appendix A. Flow of Operation (DTLS Establishment) β¨
okay so CoAP-EAP lets you derive a Pre-Shared Key (PSK) from the MSK π so (D)TLS PSK-based authentication can happen between the EAP peer and the EAP authenticator, instead of using OSCORE π. BUT, and this is a big but, (D)TLS breaks end-to-end communication when you have intermediaries like proxies in the middle π. So if you're using (D)TLS to set up a security association, you can't just throw proxies in there whenever you feel like it.
Figure 9 shows the last steps of the flow for CoAP-EAP when (D)TLS protects the communication between the EAP peer and the EAP authenticator, using the keying material exported by the EAP authentication. The general flow is basically the same as the OSCORE one, except DTLS negotiation happens in Step 7 π. Once DTLS negotiation finishes successfully, the EAP peer is granted access to the domain π. Step 7 MUST be interpreted by the EAP peer as an alternate success indication, which ends up with the MSK and the DTLS_PSK derivation for the (D)TLS authentication based on the PSK β¨.
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 handshake ============|
DTLS_PSK | |
<-- Protected with (D)TLS -->
Figure 9: CoAP-EAP Flow of Operation with DTLSAccording to [RFC8446], providing the PSK out of band also requires providing the KDF hash algorithm and the PSK identity π§. To keep the CoAP-EAP design simple, the KDF hash algorithm can be included in the list of cipher suites exchanged in Steps 1 and 2 (Figure 8) if you want to use DTLS instead of OSCORE. For the same reason, the PSK identity is derived from RID-C || RID-I, as defined in Appendix A.1 π .
Just like the cipher suite is negotiated for OSCORE (Section 6.1), the EAP authenticator sends a list, in decreasing order of preference, with the identifiers of the hash algorithms it supports (Step 1) πΈ. Then the EAP peer sends back its choice.
This list goes in the payload after the EAP message, as a CBOR array that holds the cipher suites. That CBOR array is enclosed as one of the elements of the CBOR Object used for transporting information in CoAP-EAP (see Section 5). You can see an example of how the fields are arranged in the CoAP payload in Figure 7 π.
If there is no CBOR array specifying the cipher suites, the default cipher suites are applied. If the EAP authenticator sends a restricted list of cipher suites that can be accepted, it MUST include the default value 0, since it is mandatory to implement π«Ά. That way the EAP peer always has at least that option available.
For DTLS, the negotiated cipher suite is used to determine the hash function used to derive the "DTLS_PSK" from the MSK. These hash algorithms are considered in cases where the specification includes DTLS support in the future:
5) TLS_SHA2566) TLS_SHA3847) TLS_SHA512
Including these values does two things: it indicates the hash algorithm, and it signals that the EAP authenticator intends to establish an OSCORE security association or a DTLS security association once authentication is completed π¦. If both options show up in the cipher suite negotiation, OSCORE is preferred over DTLS, no debate π.
A.1. Deriving DTLS_PSK and Identity
To enable DTLS after an EAP authentication, we define an Identity and a PSK for DTLS π. The Identity here is generated by concatenating the exchanged Sender ID and Recipient ID.
CoAP-EAP PSK Identity = RID-C || RID-IYou can also derive a PSK for DTLS [RFC9147], referred to here as "DTLS_PSK", from the MSK between the EAP peer and the EAP authenticator, if you need it π. The length of the DTLS_PSK depends on the cipher suite. To have keying material of sufficient length, a key of 32 bytes is derived, which can be truncated later if needed β¨:
DTLS_PSK = KDF(MSK, "CoAP-EAP DTLS_PSK", length)where:
- The MSK is exported by the EAP method.
"CoAP-EAP DTLS_PSK"is the ASCII code representation of the non-NULL-terminated string (excluding the double quotes around it).- length is the size of the output key material.
Appendix B. Using CoAP-EAP for Distributing Key Material for IoT Networks
Similar to the example in Appendix A.1, where a PSK for DTLS is derived, you can provide key material to different link layers after the CoAP-EAP authentication is complete π₯.
For example, CoAP-EAP could be used to derive the PSK required to run the Constrained Join Protocol (CoJP) for IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) [RFC9031] π§. ("TSCH" stands for "Time-Slotted Channel Hopping".)
Another example is when a shared Network Key is needed by the devices that join a network. You can find an example of this Network Key in the THREAD protocol [THREAD] πΈ. After CoAP-EAP runs, an OSCORE-based security association protects any exchange between the EAP peer and the EAP authenticator. That security association can be used to distribute the Network Key securely, along with other required parameters π«Ά. How the Network Key is distributed after a successful CoAP-EAP authentication is outside the scope of this document π.
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 also outside the scope of this document π .
Appendix C. Example Use Case Scenarios
In 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 π.
Next up, we'll walk through some different use case scenarios for how CoAP-EAP gets used π¦.
Generally, four entities are involved:
- Two EAP peers (A and B).
- One EAP authenticator (C). The EAP authenticator manages a domain where EAP peers can be deployed. In IoT networks, it can be a more powerful machine than the EAP peers πͺ.
- One AAA server. Optional. The AAA server is not constrained. Here, the EAP authenticator is operating in pass-through mode.
Generally, any EAP peer that wants to join the domain managed by the EAP authenticator MUST perform a CoAP-EAP authentication with the EAP authenticator (C) π. This authentication MAY involve an external AAA server. So the EAP peers (A and B), once deployed, run CoAP-EAP once as a bootstrapping phase to establish a security association with C β¨. Anyone else who wants to join and communicate with EAP peers under C's domain must also do the same π.
Using EAP gives you flexibility to have different types of credentials π. For instance, if a device isn't battery dependent and isn't very constrained, a heavier authentication method could be used π . With varied EAP peers and networks, more lightweight authentication methods (e.g., EAP-NOOB [RFC9140], EAP-AKA' [RFC5448], EAP-PSK [RFC4764], EAP-EDHOC [EAP-EDHOC], etc.) might need to be used, ones that can adapt to different types of devices according to organization policies or device capabilities π§.
C.1. Example 1: CoAP-EAP Using ACE
When using ACE, the process of client registration and provisioning of credentials to the client is not specified π. Client registration and provisioning can be done using CoAP-EAP. Once EAP authentication is complete, fresh key material is shared between the EAP peer and the EAP authenticator. With ACE, the EAP authenticator and the Authorization Server (AS) can be co-located πΈ.
Here's a general way to show how client registration can be done using CoAP-EAP, so two EAP peers (A and B) can communicate and interact after a successful client registration π.
EAP peer A wants to talk to EAP peer B (e.g., to activate a light switch) π‘. The whole process is split into three phases.
- In the first phase, EAP peer A doesn't belong to EAP authenticator C's domain yet. So it talks to C and authenticates with CoAP-EAP, which, optionally, talks to the AAA server to finish the authentication π«Ά. If authentication succeeds, a fresh MSK is shared between C and EAP peer A. This key material lets EAP peer A set up a security association with C. Some authorization information may also be provided in this step. If EAP is used in standalone mode, the AS itself, which has information about the devices, can be the entity providing that authorization information π₯.
If authentication and authorization are correct, EAP peer A is enrolled in EAP authenticator C's domain for some period of time π. In particular, [RFC5247] recommends 8 hours, though the entity providing the authorization information can set this lifetime π°οΈ. In the same way, B needs to go through the same process with CoAP-EAP to become part of EAP authenticator C's domain π .
- 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 to get all the information it needs to do that securely (e.g., keys, tokens, authorization information, etc.) π¦. This phase does NOT require CoAP-EAP. The details of this phase are outside the scope of this document; the ACE framework is used for this purpose. See [RFC9200] π§.
- In the third phase, EAP peer A can access EAP peer B using the credentials and information it got from EAP authenticator C during the second phase π. This access can be repeated without contacting the EAP authenticator, as long as the credentials given to A are still valid. The details of this phase are outside the scope of this document π.
Worth noting: to join EAP authenticator C's domain, the first phase (authentication via CoAP-EAP) is required π. Once it succeeds, communication stays local to EAP authenticator C's domain, and there's no need for 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 Section 3.3 π.
C.2. Example 2: Multiple Domains with AAA Infrastructures
Okay so picture this πΈ: a device (A) from the acme.org domain has a specific kind of credential and wants to join the um.es domain π¦. It doesn't belong to that domain, so it first does a client registration using CoAP-EAP π . It talks to the EAP authenticator's domain, which then chats with a AAA infrastructure (acting as a AAA client) π«Ά. Next, the local AAA server talks to the home AAA server to finish the authentication β¨. Ta-da, the device now counts as a trustworthy entity inside EAP authenticator C's domain π. In this setup, the AS, playing the EAP authenticator role, gets the key material from the AAA infrastructure π.
C.3. Example 3: Single Domain with a AAA Infrastructure
Picture a university campus with several faculty buildings π. Each building has its own criteria or policies for managing EAP peers under an AS π«. All the buildings belong to the same domain (e.g., um.es), and they're all managed with a AAA infrastructure π§. A brand new device (A) with credentials from that domain (e.g., um.es) can do device registration with an EAP authenticator (C) in any building, as long as those buildings are managed by the same general domain π.
C.4. Example 4: Single Domain Without a AAA Infrastructure
Another case: no AAA infrastructure at all π. Here you have an EAP authenticator with the EAP server co-located, and it's using EAP standalone mode π. That means all the devices can be managed locally within the same domain π . Client registration of an EAP peer (A) with a Controller (C) can also be done in the same way β.
C.5. Other Use Cases
C.5.1. CoAP-EAP for Network Access Authentication
Okay, this one's a big deal π. One of the first steps for an EAP peer is authenticating itself to gain access to the network π. So the device has to be authenticated and granted authorization to get on the network first πͺ. Security parameters like credentials can also be derived from that authentication process, which lets the EAP peer operate in a particular network in a trustworthy way by joining the security domain π‘οΈ. Using EAP makes this flexible and scalable, thanks to the different EAP methods available and the option to rely on AAA infrastructures when you need multi-domain scenarios π. That's a key feature when the EAP peers deployed under the same security domain belong to different organizations, for example π«Ά.
Two cases apply to the process of joining a network π :
- The node has an IPv6 address (e.g., link-local IPv6 or IPv6 global address).
- The node does not have an IPv6 address.
In networks where the device is 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 π§©. That's how CoAP-EAP messages get exchanged between the EAP peer and the EAP authenticator. For example, in IEEE 802.15.4 networks, a new Key Management Protocol (KMP) ID can be defined to add that support for IEEE 802.15.9 [IEEE802159], where it can be assumed that the device has at least a link-layer IPv6 address π¦.
When the EAP peer wants to be admitted into the network, it searches for an entity that offers the CoAP-EAP service π. That entity could be the EAP authenticator directly, or an intermediary (e.g., proxy). See Section 3.1.
CoAP-EAP runs between the EAP peer and the EAP authenticator, or through an intermediary entity such as a proxy πΈοΈ. This happens in a mesh network, for example, where the EAP authenticator could be placed one or more hops away from the EAP peer. If a proxy takes part in CoAP-EAP, it's because it's already a trustworthy entity within the domain and talks to the EAP authenticator through a secure channel π. Figure 10 shows this setup.
If the EAP peer can't connect to the EAP authenticator directly, it can follow the same process as described in Section 3.6 to perform the authentication π. It can connect via an intermediary entity (e.g., proxy) that's already part of the network. That entity already shares key material and communicates through a secure channel with the authenticator, and it can help run CoAP-EAP π§.
Once CoAP-EAP is completed and the OSCORE security association is established with the EAP authenticator, the EAP peer gets the local configuration parameters for the network (e.g., a Network Key) π. It can then configure a global IPv6 address. And there's no need for an intermediary entity after a successful authentication π.
Now for removal π§Ή. If the EAP authenticator decides to remove a particular EAP peer from the network, or the peer itself wants to leave, either side can directly send a DELETE command. That explicitly says the network access state is removed and the device no longer belongs to the network π«. Any state related to the EAP peer is then 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 π. This follows a model similar to CoJP for 6TiSCH [RFC9031]. The specifics on how this process is done are outside the scope of this document π.
+-------+ +--------+ +--------------+
| EAP | | CoAP | | EAP |
| peer |<------>| proxy |<------------------------->| authenticator|
+-------+ CoAP +--------+ CoAP +--------------+
OSCORE/DTLS
<-- security association -->Figure 10: CoAP-EAP Through CoAP Proxy
Since EAP is also used for network access authentication, this service can be adapted to other technologies π. For instance, it can provide network access control to very constrained technologies, like Long Range (LoRa) networks π‘. The authors of [LO-CoAP-EAP] study a minimal version of CoAP-EAP for LPWANs, and the results are super interesting π€. In that specific case, compression as provided by Static Context Header Compression (SCHC) for CoAP [RFC8824] can be leveraged ποΈ.
C.5.2. CoAP-EAP for Service Authentication
It's not uncommon for the infrastructure where the device is deployed and the services of the EAP peer to be managed by different organizations π’. So on top of authentication for network access control, a secondary authentication to access different services has to be considered π. This kind of authentication, for example, provides the key material needed to set up a secure channel and interact with the entity in charge of granting access to different services ποΈ.
In 5G, for example, primary and secondary authentication using EAP is considered [TS133.501] πΆ.
Acknowledgments
We'd 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 AmsΓΌss, John PreuΓ Mattsson, GΓΆran Selander, Alexandre Petrescu, Pedro Moreno-Sanchez, and Eduardo Ingles-Sanchez π.
We'd also like to thank Gabriel Lopez-Millan for the first review of this document π·. Thanks to Ivan Jimenez-Sanchez for the first proof-of-concept implementation of this idea π§ͺ. Julian Niklas Schimmelpfennig gets a shoutout for the implementation of the Erbium-based IoT device implementation π₯, and Daniel Menendez Gonzalez for the Python implementation π.
Thanks also to Alexander Pelov and Laurent Toutain for their valuable comments, especially regarding the potential optimizations of CoAP-EAP β¨.
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 π.
Authors' Addresses
Rafa Marin-Lopez University of Murcia Campus de Espinardo S/N, Faculty of Computer Science 30100 Murcia Spain Email: rafa@um.es
Dan Garcia-Carrillo University of Oviedo Calle Luis Ortiz Berrocal S/N, Edificio Polivalente 33203 Gijon Asturias Spain Email: garciadan@uniovi.es
π¦ where this page comes from
- ietf: rfc9820 2025-09
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms