rfc9820v1.txt   rfc9820.txt 
Internet Engineering Task Force (IETF) R. Marin-Lopez Internet Engineering Task Force (IETF) R. Marin-Lopez
Request for Comments: 9820 University of Murcia Request for Comments: 9820 University of Murcia
Category: Standards Track D. Garcia-Carrillo Category: Standards Track D. Garcia-Carrillo
ISSN: 2070-1721 University of Oviedo ISSN: 2070-1721 University of Oviedo
July 2025 August 2025
Authentication Service Based on the Extensible Authentication Protocol Authentication Service Based on the Extensible Authentication Protocol
(EAP) for Use with the Constrained Application Protocol (CoAP) (EAP) for Use with the Constrained Application Protocol (CoAP)
Abstract Abstract
This document specifies an authentication service that uses the This document specifies an authentication service that uses the
Extensible Authentication Protocol (EAP) transported employing Constrained Application Protocol (CoAP) as a transport method to
Constrained Application Protocol (CoAP) messages. As such, it carry the Extensible Authentication Protocol (EAP). As such, it
defines an EAP lower layer based on CoAP called "CoAP-EAP". One of defines an EAP lower layer based on CoAP called "CoAP-EAP". One of
the main goals is to authenticate a CoAP-enabled Internet of Things the main goals is to authenticate a CoAP-enabled Internet of Things
(IoT) device (EAP peer) that intends to join a security domain (IoT) device (EAP peer) that intends to join a security domain
managed by a Controller (EAP authenticator). Secondly, it allows managed by a Controller (EAP authenticator). Secondly, it allows
deriving key material to protect CoAP messages exchanged between them deriving key material to protect CoAP messages exchanged between them
based on Object Security for Constrained RESTful Environments based on Object Security for Constrained RESTful Environments
(OSCORE), enabling the establishment of a security association (OSCORE), enabling the establishment of a security association
between them. between them.
Status of This Memo Status of This Memo
skipping to change at line 97 skipping to change at line 97
9.3. The Well-Known URIs Registry 9.3. The Well-Known URIs Registry
9.4. The EAP Lower Layers Registry 9.4. The EAP Lower Layers Registry
9.5. Media Types Registry 9.5. Media Types Registry
9.6. CoAP Content-Formats Registry 9.6. CoAP Content-Formats Registry
9.7. Resource Type (rt=) Link Target Attribute Values Registry 9.7. Resource Type (rt=) Link Target Attribute Values Registry
9.8. Expert Review Instructions 9.8. Expert Review Instructions
10. References 10. References
10.1. Normative References 10.1. Normative References
10.2. Informative References 10.2. Informative References
Appendix A. Flow of Operation (DTLS Establishment) Appendix A. Flow of Operation (DTLS Establishment)
A.1. Deriving DTLS PSK and Identity A.1. Deriving DTLS_PSK and Identity
Appendix B. Using CoAP-EAP for Distributing Key Material for IoT Appendix B. Using CoAP-EAP for Distributing Key Material for IoT
Networks Networks
Appendix C. Example Use Case Scenarios Appendix C. Example Use Case Scenarios
C.1. Example 1: CoAP-EAP Using ACE C.1. Example 1: CoAP-EAP Using ACE
C.2. Example 2: Multiple Domains with AAA Infrastructures C.2. Example 2: Multiple Domains with AAA Infrastructures
C.3. Example 3: Single Domain with a AAA Infrastructure C.3. Example 3: Single Domain with a AAA Infrastructure
C.4. Example 4: Single Domain Without a AAA Infrastructure C.4. Example 4: Single Domain Without a AAA Infrastructure
C.5. Other Use Cases C.5. Other Use Cases
C.5.1. CoAP-EAP for Network Access Authentication C.5.1. CoAP-EAP for Network Access Authentication
C.5.2. CoAP-EAP for Service Authentication C.5.2. CoAP-EAP for Service Authentication
skipping to change at line 203 skipping to change at line 203
Extended Master Session Key (EMSK) of at least 64 octets. CoAP-EAP Extended Master Session Key (EMSK) of at least 64 octets. CoAP-EAP
also relies on CoAP reliability mechanisms in CoAP to transport EAP: also relies on CoAP reliability mechanisms in CoAP to transport EAP:
CoAP over UDP with Confirmable messages [RFC7252] or CoAP over TCP, CoAP over UDP with Confirmable messages [RFC7252] or CoAP over TCP,
TLS, or WebSockets [RFC8323]. TLS, or WebSockets [RFC8323].
+--------+ +--------------+ +----------+ +--------+ +--------------+ +----------+
| EAP | | EAP | | AAA/ | | EAP | | EAP | | AAA/ |
| peer |<------>| authenticator|<----------->|EAP server| | peer |<------>| authenticator|<----------->|EAP server|
+--------+ CoAP +--------------+ AAA +----------+ +--------+ CoAP +--------------+ AAA +----------+
(optional) (optional)
<----(SCOPE OF THIS DOCUMENT)----> <---- SCOPE OF THIS DOCUMENT ---->
Figure 1: CoAP-EAP Architecture Figure 1: CoAP-EAP Architecture
+---------------------------------+ +-----------------------------------+
| EAP State Machine | | EAP State Machine |
+---------------------------------+ +-----------------------------------+
| Application (CoAP-EAP) | <-- This Document | Application (CoAP-EAP) | <-- This Document
+---------------------------------+ +-----------------------------------+
| Request / Responses / Signaling | RFC 7252 / RFC 8323 | Requests / Responses / Signaling | RFC 7252 / RFC 8323
+---------------------------------+ +-----------------------------------+
| Message / Message Framing | RFC 7252 / RFC 8323 | Message / Message Framing | RFC 7252 / RFC 8323
+---------------------------------+ +-----------------------------------+
| Unreliable / Reliable Transport | RFC 7252 / RFC 8323 | Unreliable / Reliable Transport | RFC 7252 / RFC 8323
+---------------------------------+ +-----------------------------------+
Figure 2: CoAP-EAP Stack Figure 2: CoAP-EAP Stack
3. CoAP-EAP Operation 3. CoAP-EAP Operation
Because CoAP-EAP uses reliable delivery as defined in CoAP [RFC7252] Because CoAP-EAP uses reliable delivery as defined in CoAP [RFC7252]
[RFC8323], EAP retransmission time is set to an infinite value, as [RFC8323], EAP retransmission time is set to an infinite value, as
mentioned in [RFC3748]. To maintain ordering guarantees, CoAP-EAP mentioned in [RFC3748]. To maintain ordering guarantees, CoAP-EAP
uses Hypermedia as the Engine of Application State (HATEOAS). Each uses Hypermedia as the Engine of Application State (HATEOAS). Each
step during the EAP authentication accesses a new resource in the step during the EAP authentication accesses a new resource in the
skipping to change at line 251 skipping to change at line 251
multiple EAP peers. multiple EAP peers.
To access the authentication service, this document defines the well- To access the authentication service, this document defines the well-
known URI "coap-eap" (see Section 9.3). The /.well-known/coap-eap known URI "coap-eap" (see Section 9.3). The /.well-known/coap-eap
URI is used with "coap", "coap+tcp", or "coap+ws". URI is used with "coap", "coap+tcp", or "coap+ws".
3.1. Discovery 3.1. Discovery
Before the CoAP-EAP exchange takes place, the EAP peer needs to Before the CoAP-EAP exchange takes place, the EAP peer needs to
discover the EAP authenticator or the entity that will enable the discover the EAP authenticator or the entity that will enable the
CoAP-EAP exchange (e.g., an intermediary proxy). The discovery CoAP-EAP exchange (i.e., an intermediary). The discovery process is
process is outside the scope of this document. outside the scope of this document.
The CoAP-EAP application can be accessed through the URI "coap-eap" 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 for the trigger message (see Section 3.2, Step 0). The CoAP-EAP
service can be discovered by asking directly about the services service can be discovered by asking directly about the services
offered. This information can also be available in the resource offered. This information can also be available in the resource
directory [RFC9176]. directory [RFC9176].
Implementation notes: There are different methods for discovering the Implementation notes: There are different methods for discovering the
IPv6 address of the EAP authenticator or intermediary entity. For IPv6 address of the EAP authenticator or intermediary entity. For
example, in a 6LoWPAN network, the Border Router will typically act example, in a 6LoWPAN network, the Border Router will typically act
as the EAP authenticator hence, after receiving the Router as the EAP authenticator. Hence, after receiving the Router
Advertisement (RA) messages from the Border Router, the EAP peer may Advertisement (RA) messages from the Border Router, the EAP peer may
engage in the CoAP-EAP exchange. engage in the CoAP-EAP exchange.
3.2. Flow of Operation (OSCORE Establishment) 3.2. Flow of Operation (OSCORE Establishment)
Figure 3 shows the general flow of operation for CoAP-EAP to Figure 3 shows the general flow of operation for CoAP-EAP to
authenticate using EAP and establish an OSCORE security context. The authenticate using EAP and establish an OSCORE Security Context. The
flow does not show a specific EAP method. Instead, the chosen EAP flow does not show a specific EAP method. Instead, the chosen EAP
method is represented by using a generic name (EAP-X). The flow method is represented by using a generic name (EAP-X). The flow
assumes that the EAP peer knows the EAP authenticator implements the assumes that the EAP peer knows the EAP authenticator implements the
CoAP-EAP service. A CoAP-EAP message has the media type CoAP-EAP service. A CoAP-EAP message has the media type
"application/coap-eap". See Section 9.5. "application/coap-eap". See Section 9.5.
The steps for this flow of operation are as follows: The steps for this flow of operation are as follows:
* Step 0. The EAP peer MUST start the CoAP-EAP process by sending a * Step 0. The EAP peer MUST start the CoAP-EAP process by sending a
"POST /.well-known/coap-eap" request (trigger message). This "POST /.well-known/coap-eap" request (trigger message). This
skipping to change at line 306 skipping to change at line 306
* "eap" is the name that indicates that the URI is for the EAP peer. * "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. This has no meaning for the protocol but helps with debugging.
* "counter" is an incrementing unique number for every new EAP * "counter" is an incrementing unique number for every new EAP
request. request.
So, per Figure 3, the URI for the first resource would be "a/eap/1". 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 * Step 1. The EAP authenticator sends a POST message to the
resource indicated in Step 0 (e.g., '/a/eap/1'). The payload in resource indicated in Step 0 (e.g., '/a/eap/1'). The payload in
this message contains the first EAP message (EAP Request/Identity) this message contains the first EAP message (EAP-Request/Identity)
and the Recipient ID of the EAP authenticator (RID-C) for OSCORE, 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 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 (CS-C) for OSCORE. If the cipher suite list is not included, the
default cipher suite for OSCORE is used. The details of the default cipher suite for OSCORE is used. The details of the
cipher suite negotiation are discussed in Section 6.1. cipher suite negotiation are discussed in Section 6.1.
* Step 2. The EAP peer processes the POST message sending the EAP * Step 2. The EAP peer processes the POST message sending the EAP
request (EAP-Req/Id) to the EAP peer state machine, which returns request (EAP-Req/Id) to the EAP peer state machine, which returns
an EAP response (EAP Resp/Id). Then, assigns a new resource to an EAP response (EAP-Resp/Id). Then, the CoAP-EAP application
the ongoing authentication process (e.g., '/a/eap/2') and deletes assigns a new resource to the ongoing authentication process
the previous one ('/a/eap/1'). Finally, sends a '2.01 Created' (e.g., '/a/eap/2') and deletes the previous one ('/a/eap/1').
response with the new resource identifier in the Location-Path Finally, the CoAP-EAP application sends a '2.01 Created' response
(and/or Location-Query) options for the next step. The EAP with the new resource identifier in the Location-Path (and/or
response, the Recipient ID of the EAP peer (RID-I), and the Location-Query) Options for the next step. The EAP response, the
selected cipher suite for OSCORE (CS-I) are included in the Recipient ID of the EAP peer (RID-I), and the selected cipher
payload. In this step, the EAP peer may create an OSCORE security suite for OSCORE (CS-I) are included in the payload. In this
context (see Section 6.2). The required MSK will be available step, the EAP peer may create an OSCORE Security Context (see
once the EAP authentication is successful (Step 7). 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 * Steps 3-6. From now on, the EAP authenticator and the EAP peer
will exchange EAP packets related to the EAP method (EAP-X), will exchange EAP packets related to the EAP method (EAP-X),
transported in the CoAP message payload. The EAP authenticator transported in the CoAP message payload. The EAP authenticator
will use the POST method to send EAP requests to the EAP peer. 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 The EAP peer will use a CoAP response to carry the EAP response in
payload. EAP requests and responses are represented in Figure 3 the payload. EAP requests and responses are represented in
using the nomenclature "EAP-X-Req" and "EAP-X-Resp", respectively. Figure 3 using the nomenclature "EAP-X-Req" and "EAP-X-Resp",
When a POST message arrives (e.g., '/a/eap/1') carrying an EAP respectively. When a POST message arrives (e.g., '/a/eap/1')
request message, if processed correctly by the EAP peer state carrying an EAP request message, if processed correctly by the EAP
machine, it returns an EAP Response. Along with each EAP peer state machine, it returns an EAP Response. Along with each
Response, a new resource is created (e.g., '/a/eap/3') for EAP Response, a new resource is created (e.g., '/a/eap/3') for
processing the next EAP request and the ongoing resource (e.g., processing the next EAP request and the ongoing resource (e.g.,
'/a/eap/2') is erased. This way, ordering guarantees are '/a/eap/2') is erased. This way, ordering guarantees are
achieved. Finally, an EAP response is sent in the payload of a achieved. Finally, an EAP response is sent in the payload of a
CoAP response that will also indicate the new resource in the CoAP response that will also indicate the new resource in the
Location-Path (and/or Location-Query) Options. If an error occurs Location-Path (and/or Location-Query) Options. If an error occurs
while processing a legitimate message, the server will return a while processing a legitimate message, the server will return a
"4.00 Bad Request". Error handling is discussed in Section 3.5. '4.00 Bad Request'. Error handling is discussed in Section 3.5.
* Step 7. When the EAP authentication ends successfully, the EAP * Step 7. When the EAP authentication ends successfully, the EAP
authenticator obtains the MSK exported by the EAP method, an EAP authenticator obtains the MSK exported by the EAP method, an EAP
Success message, and some authorization information (e.g., session Success message, and some authorization information (e.g.,
lifetime) [RFC5247]. The EAP authenticator creates the OSCORE Session-Lifetime) [RFC5247]. The EAP authenticator creates the
security context using the MSK and Recipient ID of both entities OSCORE Security Context using the MSK and Recipient ID of both
exchanged in Steps 1 and 2. The establishment of the OSCORE entities exchanged in Steps 1 and 2. The establishment of the
Security Context is defined in Section 6.2. Then, the EAP OSCORE Security Context is defined in Section 6.2. Then, the EAP
authenticator sends the POST message protected with OSCORE for key authenticator sends the POST message protected with OSCORE for key
confirmation, including the EAP Success. The EAP authenticator confirmation, including the EAP Success. The EAP authenticator
MAY also send a Session Lifetime, in seconds, which is represented MAY also send a Session-Lifetime, in seconds, which is represented
by an unsigned integer in a CBOR object (see Section 5). If this 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 Session-Lifetime is not sent, the EAP peer assumes a default value
of 8 hours, as RECOMMENDED in [RFC5247]. The reception of the of 8 hours, as RECOMMENDED in [RFC5247]. The reception of the
OSCORE-protected POST message is considered by the EAP peer as an OSCORE-protected POST message is considered by the EAP peer as an
alternate indication of success [RFC3748]. The EAP peer state alternate indication of success [RFC3748]. The EAP peer state
machine in the EAP peer interprets the alternate indication of machine in the EAP peer interprets the alternate indication of
success (similarly to the arrival of an EAP Success) and returns success (similarly to the arrival of an EAP Success) and returns
the MSK, which is used to create the OSCORE security context in 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 peer to process the protected POST message received from
the EAP authenticator. the EAP authenticator.
* Step 8. If the EAP authentication and the verification of the * Step 8. If the EAP authentication and the verification of the
OSCORE-protected POST (Step 7) are successful, then the EAP peer OSCORE-protected POST (Step 7) are successful, then the EAP peer
answers with an OSCORE-protected '2.04 Changed'. From this point answers with an OSCORE-protected '2.04 Changed'. From this point
on, communication with the last resource (e.g., '/a/eap/(n)') MUST on, communication with the last resource (e.g., '/a/eap/(n)') MUST
be protected with OSCORE. If allowed by application policy, the be protected with OSCORE. If allowed by application policy, the
same OSCORE security context MAY be used to protect communication same OSCORE Security Context MAY be used to protect communication
to other resources between the same endpoints. to other resources between the same endpoints.
EAP peer EAP authenticator EAP peer EAP authenticator
------------- ------------ ------------- ------------
| POST /.well-known/coap-eap | | POST /.well-known/coap-eap |
0)| No-Response | 0)| No-Response |
| Payload("/a/eap/1") | | Payload("/a/eap/1") |
|---------------------------------------->| |---------------------------------------->|
| POST /a/eap/1 | | POST /a/eap/1 |
| Payload(EAP Req/Id||CS-C||RID-C) | | Payload(EAP-Req/Id||CS-C||RID-C) |
1)|<----------------------------------------| 1)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/2] | | 2.01 Created Location-Path [/a/eap/2] |
| Payload(EAP Resp/Id||CS-I||RID-I) | | Payload(EAP-Resp/Id||CS-I||RID-I) |
2)|---------------------------------------->| 2)|---------------------------------------->|
| POST /a/eap/2 | | POST /a/eap/2 |
| Payload(EAP-X Req) | | Payload(EAP-X-Req) |
3)|<----------------------------------------| 3)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/3] | | 2.01 Created Location-Path [/a/eap/3] |
| Payload(EAP-X Resp) | | Payload(EAP-X-Resp) |
4)|---------------------------------------->| 4)|---------------------------------------->|
.... ....
| POST /a/eap/(n-1) | | POST /a/eap/(n-1) |
| Payload(EAP-X Req) | | Payload(EAP-X-Req) |
5)|<----------------------------------------| 5)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/(n)] | | 2.01 Created Location-Path [/a/eap/(n)] |
| Payload (EAP-X Resp) | | Payload(EAP-X-Resp) |
6)|---------------------------------------->| 6)|---------------------------------------->|
| | MSK | | MSK
| POST /a/eap/(n) | | | POST /a/eap/(n) | |
| OSCORE | | | OSCORE | v
| Payload(EAP Success||*Session-Lifetime)| OSCORE | Payload(EAP Success||*Session-Lifetime)| OSCORE
MSK 7)|<----------------------------------------| CTX MSK 7)|<----------------------------------------| CTX
| | | | | |
| | 2.04 Changed | v | 2.04 Changed |
OSCORE | OSCORE | OSCORE | OSCORE |
CTX 8)|---------------------------------------->| CTX 8)|---------------------------------------->|
*Session-Lifetime is optional *Session-Lifetime is optional
Figure 3: CoAP-EAP Flow of Operation with OSCORE Figure 3: CoAP-EAP Flow of Operation with OSCORE
3.3. Re-Authentication 3.3. Re-Authentication
When the CoAP-EAP state is close to expiring, the EAP peer may want When the CoAP-EAP state is close to expiring, the EAP peer may want
to start a new authentication process (re-authentication) to renew to start a new authentication process (re-authentication) to renew
the state. The main goal is to obtain new and fresh keying material the state. The main goal is to obtain new and fresh keying material
(MSK/EMSK) that, in turn, allows deriving a new OSCORE security (MSK/EMSK) that, in turn, allows deriving a new OSCORE Security
context, increasing the protection against key leakage. The keying Context, increasing the protection against key leakage. The keying
material MUST be renewed before the expiration of the Session- material MUST be renewed before the expiration of the Session-
Lifetime. By default, the EAP key management framework [RFC5247] Lifetime. By default, the EAP key management framework [RFC5247]
establishes a default value of 8 hours to refresh the keying establishes a default value of 8 hours to refresh the keying
material. Certain EAP methods such as Nimble Out-of-Band material. Certain EAP methods such as Nimble Out-of-Band
Authentication for EAP (EAP-NOOB) [RFC9140] or EAP-AKA' [RFC5448] Authentication for EAP (EAP-NOOB) [RFC9140] or EAP-AKA' [RFC5448]
provide fast reconnect for quicker re-authentication. The EAP Re- provide fast reconnect for quicker re-authentication. The EAP Re-
authentication Protocol (ERP) [RFC6696] MAY also be used to avoid the authentication Protocol (ERP) [RFC6696] MAY also be used to avoid the
repetition of the entire EAP exchange. repetition of the entire EAP exchange.
The re-authentication message flow will be the same as that shown in The re-authentication message flow will be the same as that shown in
skipping to change at line 507 skipping to change at line 508
authentication failure (Section 3.5.1), a non-responsive endpoint authentication failure (Section 3.5.1), a non-responsive endpoint
(Section 3.5.2), and duplicated messages (Section 3.5.3). (Section 3.5.2), and duplicated messages (Section 3.5.3).
3.5.1. EAP Authentication Failure 3.5.1. EAP Authentication Failure
The EAP authentication may fail in different situations (e.g., wrong The EAP authentication may fail in different situations (e.g., wrong
credentials). The result is that the EAP authenticator will send an credentials). The result is that the EAP authenticator will send an
EAP Failure message because of a failed EAP authentication (Step 7 in EAP Failure message because of a failed EAP authentication (Step 7 in
Figure 3). In this case, the EAP peer MUST send a response '4.01 Figure 3). In this case, the EAP peer MUST send a response '4.01
Unauthorized' in Step 8. Therefore, Steps 7 and 8 are not protected Unauthorized' in Step 8. Therefore, Steps 7 and 8 are not protected
in this case because no MSK is exported and the OSCORE security in this case because no MSK is exported and the OSCORE Security
context is not yet generated. Context is not yet generated.
If the EAP authentication fails during the re-authentication and the If the EAP authentication fails during the re-authentication and the
EAP authenticator sends an EAP failure, the current CoAP-EAP state EAP authenticator sends an EAP Failure, the current CoAP-EAP state
will still be usable until it expires. will still be usable until it expires.
3.5.2. Non-Responsive Endpoint 3.5.2. Non-Responsive Endpoint
If for any reason one of the entities becomes non-responsive, the If for any reason one of the entities becomes non-responsive, the
CoAP-EAP state SHOULD be removed after a stipulated amount of time. CoAP-EAP state SHOULD be removed after a stipulated amount of time.
The amount of time can be adjusted according to the policies The amount of time can be adjusted according to the policies
established by the application or use case where CoAP-EAP is used. established by the application or use case where CoAP-EAP is used.
As a default value, the CoAP EXCHANGE_LIFETIME parameter, as defined As a default value, the CoAP EXCHANGE_LIFETIME parameter, as defined
in CoAP [RFC7252], will be used. in CoAP [RFC7252], will be used.
The removal of the CoAP-EAP state in the EAP authenticator assumes The removal of the CoAP-EAP state in the EAP authenticator assumes
that the EAP peer will need to authenticate again. that the EAP peer will need to authenticate again.
According to CoAP, EXCHANGE_LIFETIME considers the time it takes According to CoAP, EXCHANGE_LIFETIME considers the time it takes
until a client stops expecting a response to a request. A timer is 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 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 value of EXCHANGE_LIFETIME as a timer in the EAP peer and
authenticator to remove the CoAP-EAP state if the authentication authenticator to remove the CoAP-EAP state if the authentication
process has not progressed in that time, in consequence, it has not process has not progressed to completion during that time.
been completed.
The EAP peer will remove the CoAP-EAP state if either the The EAP peer will remove the CoAP-EAP state if either the
EXCHANGE_LIFETIME is triggered or the EAP peer state machine returns EXCHANGE_LIFETIME is triggered or the EAP peer state machine returns
an eapFail. an eapFail.
The EAP authenticator will remove the CoAP-EAP state if either the The EAP authenticator will remove the CoAP-EAP state if either the
EXCHANGE_LIFETIME is triggered or, when the EAP authenticator is EXCHANGE_LIFETIME is triggered or, when the EAP authenticator is
operating in pass-through mode (i.e., the EAP authentication is operating in pass-through mode (i.e., the EAP authentication is
performed against a AAA server), the EAP authenticator state machine performed against a AAA server), the EAP authenticator state machine
returns "aaaTimeout" [RFC4137]. returns "aaaTimeout" [RFC4137].
3.5.3. Duplicated Message with /.well-known/coap-eap 3.5.3. Duplicated Message with /.well-known/coap-eap
The reception of the trigger message in Step 0 containing the URI The reception of the trigger message (Step 0 in Figure 3) containing
/coap-eap needs some additional considerations, as the resource is the URI /coap-eap needs some additional considerations, as the
always available in the EAP authenticator. resource is always available in the EAP authenticator.
If a trigger message (Step 0) arrives at the EAP authenticator during If a trigger message arrives at the EAP authenticator during an
an ongoing authentication with the same EAP peer, the EAP ongoing authentication with the same EAP peer, the EAP authenticator
authenticator MUST silently discard this trigger message. MUST silently discard this trigger message.
If an old "POST /.well-known/coap-eap" (Step 0) arrives at the EAP If an old "POST /.well-known/coap-eap" (Step 0 in Figure 5) arrives
authenticator and there is no authentication ongoing, the EAP at the EAP authenticator and there is no authentication ongoing, the
authenticator may understand that a new authentication process is EAP authenticator may understand that a new authentication process is
requested. Consequently, the EAP authenticator will start a new EAP requested. Consequently, the EAP authenticator will start a new EAP
authentication. However, if the EAP peer did not start any authentication. However, if the EAP peer did not start any
authentication and therefore, it did not select any resource for the authentication, it will send a '4.04 Not Found' in the response
EAP authentication. Thus, the EAP peer sends a '4.04 Not Found' in (Figure 5).
the response (Figure 5).
EAP peer EAP authenticator EAP peer EAP authenticator
---------- ---------- ---------- ----------
| *POST /.well-known/coap-eap | | *POST /.well-known/coap-eap |
0) | No-Response | 0)| No-Response |
| Payload("/a/eap/1") | | Payload("/a/eap/1") |
| ------------------------->| | ------------------------->|
| POST /a/eap/1 | | POST /a/eap/1 |
| Payload (EAP Req/Id||CS-C) | | Payload(EAP-Req/Id||CS-C) |
1) |<----------------------------------------| 1)|<----------------------------------------|
| | | |
| 4.04 Not Found | | 4.04 Not Found |
|---------------------------------------->| |---------------------------------------->|
*Old *Old
Figure 5: /.well-known/coap-eap with No Ongoing Authentication Figure 5: /.well-known/coap-eap with No Ongoing Authentication
from the EAP Authenticator from the EAP Authenticator
3.6. Proxy Operation in CoAP-EAP 3.6. Proxy Operation in CoAP-EAP
The CoAP-EAP operation is intended to be compatible with the use of The CoAP-EAP operation is intended to be compatible with the use of
intermediary entities between the EAP peer and the EAP authenticator intermediary entities between the EAP peer and the EAP authenticator
when direct communication is not possible. In this context, CoAP when direct communication is not possible. In this context, CoAP
proxies can be used as enablers of the CoAP-EAP exchange. proxies can be used as enablers of the CoAP-EAP exchange.
This specification is limited to using standard CoAP [RFC7252] as This specification is limited to using standard CoAP [RFC7252] as
well as standardized CoAP options [RFC8613]. It does not specify any well as standardized CoAP options [RFC8613]. It does not specify any
addition in the form of CoAP options. This is expected to ease the addition in the form of CoAP options. This is expected to ease the
integration of CoAP intermediaries in the CoAP-EAP exchange. integration of CoAP intermediaries in the CoAP-EAP exchange.
When using proxies in the CoAP-EAP exchange, it should be considered When using proxies in the CoAP-EAP exchange, it should be considered
that the exchange contains a role-reversal process at the beginning 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 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 client and the EAP authenticator acts as the CoAP server. In the
that, in the remaining exchanges the roles are reversed, being the remaining exchanges, the roles are reversed (i.e., the EAP peer acts
EAP peer, the CoAP server, and the EAP authenticator, the CoAP as the CoAP server, and the EAP authenticator acts as the CoAP
client. When using a proxy in the exchange, for Message 0, the proxy client). When using a proxy in the exchange, for message 0 it will
will act as forward, and as reverse for the rest. Additionally, in act as a forward proxy, and as a reverse proxy for the rest.
the first exchange, the EAP peer, as a CoAP client, sends the URI for Additionally, in the first exchange, the EAP peer, as a CoAP client,
the next CoAP message in the payload of a request. This is not the sends the URI for the next CoAP message in the payload of a request.
typical behavior, as URIs referring to new services/resources appear This is not the typical behavior, as URIs referring to new services/
in Location-Path and/or Location-Query Options in CoAP responses. resources appear in Location-Path and/or Location-Query Options in
Hence, the proxy will have to treat the payload of Message 0 as if it CoAP responses. Hence, the proxy will have to treat the payload of
were a Location-Path Option of a CoAP response. Message 0 as if it were a Location-Path Option of a CoAP response.
4. CoAP-EAP Media Type Format 4. CoAP-EAP Media Type Format
In the CoAP-EAP exchange, the format specified by the "application/ In the CoAP-EAP exchange, the format specified by the "application/
coap-eap" media type will be used. See Section 9.5. coap-eap" media type will be used. See Section 9.5.
In CoAP-EAP, there are two different elements that can be sent over In CoAP-EAP, there are two different elements that can be sent over
the payload. The first one is a relative URI. This payload will be the payload. The first one is a relative URI. This payload will be
present for the first message (0) in Figure 3. present for the first message (0) in Figure 3.
In all the other cases, an EAP message will be followed by the CBOR In all the other cases, an EAP message will be followed by the CBOR
Object specified in Section 5. A visual example of the second case Object specified in Section 5. A visual example of the second case
can be found in Figure 7 (Section 6.1). can be found in Figure 7 (Section 6.1).
5. CBOR Objects in CoAP-EAP 5. CBOR Objects in CoAP-EAP
In the CoAP-EAP exchange, there is information that needs to be In the CoAP-EAP exchange, information needs to be exchanged between
exchanged between the two entities. Examples of this information are the two entities -- for example, the cipher suites that need to be
the cipher suites that need to be negotiated or authorization negotiated, or authorization information (Session-Lifetime). There
information (Session-lifetime). There may also be a need to extend may also be a need to extend the information that has to be exchanged
the information that has to be exchanged in the future. This section in the future. This section specifies the CBOR data structure
specifies the CBOR data structure [RFC8949] to exchange information [RFC8949] to exchange information between the EAP peer and the EAP
between the EAP peer and the EAP authenticator in the CoAP payload. authenticator in the CoAP payload.
Figure 6 shows the specification of the CBOR Object to exchange Figure 6 shows the specification of the CBOR Object to exchange
information in CoAP-EAP. information in CoAP-EAP.
CoAP-EAP_Info = { CoAP-EAP_Info = {
? 1 : [+ int], ; Cipher Suite (CS-C or CS-I) ? 1 : [+ int], ; Cipher Suite (CS-C or CS-I)
? 2 : bstr, ; RID-C ? 2 : bstr, ; RID-C
? 3 : bstr, ; RID-I ? 3 : bstr, ; RID-I
? 4 : uint ; Session-Lifetime ? 4 : uint ; Session-Lifetime
} }
skipping to change at line 672 skipping to change at line 671
Other indexes can be used to carry additional values as needed, like Other indexes can be used to carry additional values as needed, like
specific authorization parameters. specific authorization parameters.
The indexes from 65001 to 65535 are reserved for experimentation. The indexes from 65001 to 65535 are reserved for experimentation.
6. Cipher Suite Negotiation and Key Derivation 6. Cipher Suite Negotiation and Key Derivation
6.1. Cipher Suite Negotiation 6.1. Cipher Suite Negotiation
OSCORE runs after the EAP authentication, using the cipher suite OSCORE runs after the EAP authentication, using the cipher suite
selected in the cipher suite negotiation (Steps 1 and 2). To selected in the cipher suite negotiation (Steps 1 and 2 in Figure 3).
negotiate the cipher suite, CoAP-EAP follows a simple approach: The To negotiate the cipher suite, CoAP-EAP follows a simple approach:
EAP authenticator sends a list, in decreasing order of preference, The EAP authenticator sends a list, in decreasing order of
with the identifiers of the supported cipher suites (Step 1). In the preference, with the identifiers of the supported cipher suites (Step
response to that message (Step 2), the EAP peer sends its choice. 1 in Figure 8). In the response to that message (Step 2 in
Figure 8), the EAP peer sends its choice.
This list is included in the payload after the EAP message through a 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 CBOR array. An example of how the fields are arranged in the CoAP
payload can be seen in Figure 7. An example exchange for the cipher payload can be seen in Figure 7. An example exchange for the cipher
suite negotiation is shown in Figure 8, where it can be appreciated suite negotiation is shown in Figure 8. The EAP request (EAP-
the disposition of both the EAP-Request/Identity and EAP-Response/ Request/Identity) and EAP response (EAP-Response/Identity) are sent;
Identity, followed by the CBOR object defined in Section 5, both messages include the CBOR Object (Section 5) containing the
containing the cipher suite field for the cipher suite negotiation. cipher suite field for the cipher suite negotiation.
+-----+-----------+-------+------++-------------+ +------+------------+--------+------+-----------------+
|Code |Identifier |Length | Data ||cipher suites| | Code | Identifier | Length | Data | cipher suites |
+-----+-----------+-------+------++-------------+ +------+------------+--------+------+-----------------+
EAP packet CBOR array
<---------- EAP Packet ----------> <-- CBOR array -->
Figure 7: Cipher Suites in the CoAP Payload Figure 7: Cipher Suites in the CoAP Payload
EAP peer EAP auth. EAP peer EAP Auth.
(CoAP server) (CoAP client) (CoAP server) (CoAP client)
------------- ------------- ------------- -------------
| | | |
| ... | | ... |
|---------------------------------------->| |---------------------------------------->|
| POST /a/eap/1 | | POST /a/eap/1 |
| Payload (EAP Req/Id, CBORArray[0,1,2]) | | Payload(EAP-Req/Id, CBORArray[0,1,2]) |
1) |<----------------------------------------| 1)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/2] | | 2.01 Created Location-Path [/a/eap/2] |
| Payload (EAP Resp/Id, CBORArray[0]) | | Payload(EAP-Resp/Id, CBORArray[0]) |
2) |---------------------------------------->| 2)|---------------------------------------->|
... ...
Figure 8: Cipher Suite Negotiation Figure 8: Cipher Suite Negotiation
If there is no CBOR array specifying the cipher suites, the default If there is no CBOR array specifying the cipher suites, the default
cipher suites are applied. If the EAP authenticator sends a cipher suites are applied. If the EAP authenticator sends a
restricted list of cipher suites that can be accepted, it MUST restricted list of cipher suites that can be accepted, it MUST
include the default value 0, since it is mandatory to implement. The include the default value 0, since it is mandatory to implement. The
EAP peer will have at least that option available. EAP peer will have at least that option available.
The cipher suite requirements are inherited from those established by The cipher suite requirements are inherited from those established by
OSCORE [RFC8613], which are COSE algorithms [RFC9053]. By default, OSCORE [RFC8613], which are COSE algorithms [RFC9053]. By default,
the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) the HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
algorithm is SHA-256 and the Authenticated Encryption with Associated algorithm is SHA-256 and the Authenticated Encryption with Associated
Data (AEAD) algorithm is AES-CCM-16-64-128 [RFC9053]. ("HMAC" stands Data (AEAD) algorithm is AES-CCM-16-64-128 [RFC9053]. ("HMAC" stands
for "Hashed Message Authentication Code".) Both are mandatory to for "Hashed Message Authentication Code".) Both are mandatory to
implement. The other supported and negotiated cipher suites are as implement. The other supported and negotiated cipher suites are
follows: listed below; these hash algorithms are considered in cases where the
specification includes DTLS support in the future (TLS_SHA256,
TLS_SHA384, TLS_SHA512; see Appendix A):
* 0) AES-CCM-16-64-128, SHA-256 (default) * 0) AES-CCM-16-64-128, SHA-256 (default)
* 1) A128GCM, SHA-256 * 1) A128GCM, SHA-256
* 2) A256GCM, SHA-384 * 2) A256GCM, SHA-384
* 3) ChaCha20/Poly1305, SHA-256 * 3) ChaCha20/Poly1305, SHA-256
* 4) ChaCha20/Poly1305, SHAKE256 * 4) ChaCha20/Poly1305, SHAKE256
This specification uses the HKDF as defined in [RFC5869] to derive This specification uses the HKDF as defined in [RFC5869] to derive
the necessary key material. Since the key derivation process uses the necessary key material. Since the key derivation process uses
the MSK, which is considered fresh key material, the HKDF-Expand the MSK, which is considered fresh key material, the HKDF-Expand
function (shortened here as "KDF") will be used. See Section 8.1 function (shortened here as "KDF") will be used. See Section 8.1
regarding why the use of this function is enough and it is not regarding why the use of this function is enough and it is not
necessary to use KDF-Extract. necessary to use KDF-Extract.
6.2. Deriving the OSCORE Security Context 6.2. Deriving the OSCORE Security Context
The derivation of the OSCORE security context allows securing the The derivation of the OSCORE Security Context allows securing the
communication between the EAP peer and the EAP authenticator once the communication between the EAP peer and the EAP authenticator once the
MSK has been exported, providing confidentiality, integrity, key MSK has been exported, providing confidentiality, integrity, key
confirmation (Steps 7 and 8), and detection of downgrading attacks. 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 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 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 of [RFC8613]). It should be noted that the ID Context is not
provided for the OSCORE Security Context derivation. provided for the OSCORE Security Context derivation.
The Master Secret can be derived by using the chosen cipher suite and The Master Secret can be derived by using the chosen cipher suite and
the KDF as follows: the KDF as follows:
Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length) Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length)
skipping to change at line 813 skipping to change at line 817
* length is the size of the output key material. * length is the size of the output key material.
Since the MSK is used to derive the Master Key, the correct Since the MSK is used to derive the Master Key, the correct
verification of the OSCORE-protected request (Step 7) and response verification of the OSCORE-protected request (Step 7) and response
(Step 8) confirms that the EAP authenticator and the EAP peer have (Step 8) confirms that the EAP authenticator and the EAP peer have
the same Master Secret, achieving key confirmation. the same Master Secret, achieving key confirmation.
To prevent a downgrading attack, the content of the cipher suite To prevent a downgrading attack, the content of the cipher suite
(referred to here as "CS") negotiation is embedded in the Master (referred to here as "CS") negotiation is embedded in the Master
Secret derivation. If an attacker changes the value of the cipher Secret derivation. If an attacker changes the value of the cipher
suite negotiation, the result will be different OSCORE security suite negotiation, the result will be different OSCORE Security
contexts, which in turn will result in failure in Steps 7 and 8. Contexts, which in turn will result in failure in Steps 7 and 8.
The EAP authenticator will use the Recipient ID of the EAP peer (RID- 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 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. use this value as the Recipient ID for its Recipient Context.
The EAP peer will use the Recipient ID of the EAP authenticator (RID- 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 C) as the Sender ID for its OSCORE Sender Context. The EAP
authenticator will use this value as the Recipient ID for its authenticator will use this value as the Recipient ID for its
Recipient Context. Recipient Context.
skipping to change at line 853 skipping to change at line 857
over IPv6 or TCP). over IPv6 or TCP).
Lower-layer security: EAP does not require security services from Lower-layer security: EAP does not require security services from
the lower layers. the lower layers.
Minimum MTU: Lower layers need to provide an EAP MTU size of 1020 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 octets or greater. CoAP assumes an upper bound of 1024 octets for
its payload, which covers the EAP requirements when only the EAP its payload, which covers the EAP requirements when only the EAP
message is sent in the CoAP payload. In the case of Messages 1 message is sent in the CoAP payload. In the case of Messages 1
and 2 in Figure 3, those messages have extra information apart and 2 in Figure 3, those messages have extra information apart
from EAP. Nevertheless, the EAP Req/Id has a fixed length of 5 from EAP. Nevertheless, the EAP-Req/Id has a fixed length of 5
bytes. Message 2, with the EAP Resp/Id, would limit the length of bytes. Message 2, with the EAP-Resp/Id, would limit the length of
the identity being used to the CoAP payload maximum size (1024) - the identity being used to the CoAP payload maximum size (1024) -
len( CS-I || RID-I ) - EAP Response header (5 bytes), which leaves len( CS-I || RID-I ) - EAP Response header (5 bytes), which leaves
enough space for sending even lengthy identities. Nevertheless, enough space for sending even lengthy identities. Nevertheless,
this limitation can be overcome by using CoAP block-wise transfers this limitation can be overcome by using CoAP block-wise transfers
[RFC7959]. Note: When EAP is proxied over a AAA framework, the [RFC7959]. Note: When EAP is proxied over a AAA framework, the
Access-Request packets in RADIUS MUST contain a Framed-MTU Access-Request packets in RADIUS MUST contain a Framed-MTU
attribute with a value of 1024 and, in Diameter, the 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 Attribute-Value Pair (AVP) with a value of 1024. This information
signals the AAA server that it should limit its responses to 1024 signals the AAA server that it should limit its responses to 1024
octets. octets.
Ordering guarantees: EAP relies on lower-layer ordering guarantees Ordering guarantees: EAP relies on lower-layer ordering guarantees
for correct operation. Regarding message ordering, every time a for correct operation. Regarding message ordering, every time a
new message arrives at the authentication service hosted by the new message arrives at the authentication service hosted by the
EAP peer, a new resource is created, and this is indicated in a 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 '2.01 Created' response code along with the name of the new
resource via Location-Path or Location-Query options. This way, resource via Location-Path or Location-Query Options. This way,
the application shows that its state has advanced. the application shows that its state has advanced.
Although [RFC3748] states that "EAP provides its own support for Although [RFC3748] states that "EAP provides its own support for
duplicate elimination and retransmission," EAP is also reliant on duplicate elimination and retransmission," EAP is also reliant on
lower-layer ordering guarantees. In this regard, [RFC3748] talks lower-layer ordering guarantees. In this regard, [RFC3748] talks
about possible duplication and says, "Where the lower layer is about possible duplication and says, "Where the lower layer is
reliable, it will provide the EAP layer with a non-duplicated stream reliable, it will provide the EAP layer with a non-duplicated stream
of packets. However, while it is desirable that lower layers provide of packets. However, while it is desirable that lower layers provide
for non-duplication, this is not a requirement." CoAP provides a for non-duplication, this is not a requirement." CoAP provides a
non-duplicated stream of packets and accomplishes the desirable non- non-duplicated stream of packets and accomplishes the desirable non-
skipping to change at line 901 skipping to change at line 905
comparison with another network-layer-based EAP lower layer, the comparison with another network-layer-based EAP lower layer, the
Protocol for Carrying Authentication for Network Access (PANA) as Protocol for Carrying Authentication for Network Access (PANA) as
defined in [RFC5191]. defined in [RFC5191].
The EAP method being transported will take most of the exchange. The EAP method being transported will take most of the exchange.
However, the impact of the EAP lower layer cannot be ignored, However, the impact of the EAP lower layer cannot be ignored,
especially in very constrained communication technologies such as especially in very constrained communication technologies such as
those with limited capabilities (e.g., as can be found in IoT those with limited capabilities (e.g., as can be found in IoT
networks). networks).
Note: For scenarios involving constrained devices and networks, the Note: To improve efficiency in environments with constrained devices
use of the latest versions of EAP methods (e.g., EAP-AKA' [RFC5448], and networks, the latest versions of EAP methods (e.g., EAP-AKA'
EAP-TLS 1.3 [RFC9190]) is recommended in favor of older versions with [RFC5448], EAP-TLS 1.3 [RFC9190]) are recommended over older
the goal of economizing, or EAP methods more adapted for IoT networks versions. EAP methods more adapted for IoT networks (e.g., EAP-NOOB
(e.g., EAP-NOOB [RFC9140], EAP-EDHOC [EAP-EDHOC], etc.). [RFC9140], EAP-EDHOC [EAP-EDHOC], etc.) are also recommended.
8. Security Considerations 8. Security Considerations
Security aspects to be considered include how authorization is Security aspects to be considered include how authorization is
managed, the use of the MSK as key material, and how trust in the EAP managed, the use of the MSK as key material, and how trust in the EAP
authenticator is established. Additional considerations such as EAP authenticator is established. Additional considerations such as EAP
channel binding as per [RFC6677] are also discussed here. channel binding as per [RFC6677] are also discussed here.
8.1. Use of EAP Methods 8.1. Use of EAP Methods
skipping to change at line 945 skipping to change at line 949
bootstrapping, additional authorization information may be needed to bootstrapping, additional authorization information may be needed to
operate in the security domain. This can be taken care of by the operate in the security domain. This can be taken care of by the
solutions proposed in the Authentication and Authorization for solutions proposed in the Authentication and Authorization for
Constrained Environments (ACE) WG, such as the use of OAuth Constrained Environments (ACE) WG, such as the use of OAuth
[RFC9200], among other solutions, to provide ACE. [RFC9200], among other solutions, to provide ACE.
8.3. Allowing CoAP-EAP Traffic to Perform Authentication 8.3. Allowing CoAP-EAP Traffic to Perform Authentication
Since CoAP is an application protocol, CoAP-EAP assumes certain IP Since CoAP is an application protocol, CoAP-EAP assumes certain IP
connectivity in the link between the EAP peer and the EAP connectivity in the link between the EAP peer and the EAP
authenticator to run. This link MUST authorize exclusively authenticator to run. This link MUST only authorize unprotected IP
unprotected IP traffic to be sent between the EAP peer and the EAP traffic to be sent between the EAP peer and the EAP authenticator
authenticator during the authentication with CoAP-EAP. Once the during the authentication with CoAP-EAP. Once the authentication is
authentication is successful, the key material generated by the EAP successful, the key material generated by the EAP authentication
authentication (MSK) and any other traffic can be authorized if it is (MSK) and any other traffic can be authorized if it is protected. It
protected. It is worth noting that if the EAP authenticator is not is worth noting that if the EAP authenticator is not in the same link
in the same link as the EAP peer and an intermediate entity (i.e., a as the EAP peer and an intermediate entity (e.g., a CoAP proxy) helps
CoAP proxy) helps with this process, this concept also applies to the with this process, this concept also applies to the communication
communication between the EAP peer and the intermediary. between the EAP peer and the intermediary.
Alternatively, the link layer MAY provide support to transport CoAP- Alternatively, the link layer MAY provide support to transport CoAP-
EAP without an IP address by using link-layer frames (e.g., by EAP without an IP address by using link-layer frames (e.g., by
defining a new Key Management Protocol ID per IEEE 802.15.9 defining a new Key Management Protocol ID per IEEE 802.15.9
[IEEE802159]). [IEEE802159]).
8.4. Freshness of the Key Material 8.4. Freshness of the Key Material
In CoAP-EAP, there is no nonce exchange to provide freshness to the In CoAP-EAP, there is no nonce exchange to provide freshness to the
keys derived from the MSK. The MSKs and EMSKs are fresh key material keys derived from the MSK. The MSKs and EMSKs are fresh key material
skipping to change at line 975 skipping to change at line 979
authenticator, there is no need to generate additional key material. authenticator, there is no need to generate additional key material.
If a new MSK is required, a re-authentication can be done by running If a new MSK is required, a re-authentication can be done by running
the process again or using a more lightweight EAP method to derive the process again or using a more lightweight EAP method to derive
additional key material as elaborated in Section 3.3. additional key material as elaborated in Section 3.3.
8.5. Channel-Binding Support 8.5. Channel-Binding Support
According to [RFC6677], channel binding, as related to EAP, is sent According to [RFC6677], channel binding, as related to EAP, is sent
through the EAP method supporting it. through the EAP method supporting it.
To satisfy the requirements of the document, the EAP lower-layer To satisfy the requirements of this document, the EAP lower-layer
identifier (assigned by IANA) needs to be sent, in the EAP Lower- identifier for CoAP-EAP (10, as assigned by IANA; see Section 9.4)
Layer Attribute if RADIUS is used. needs to be sent, in the EAP Lower-Layer Attribute if RADIUS is used.
8.6. Additional Security Considerations 8.6. Additional Security Considerations
In the authentication process, it is possible for an entity to forge In the authentication process, it is possible for an entity to forge
messages to generate denial-of-service (DoS) attacks on any of the messages to generate denial-of-service (DoS) attacks on any of the
entities involved. For instance, an attacker can forge multiple entities involved. For instance, an attacker can forge multiple
initial messages to start an authentication (Step 0) with the EAP initial messages to start an authentication (Step 0 in Figure 3) with
authenticator as if they were sent by different EAP peers. the EAP authenticator as if they were sent by different EAP peers.
Consequently, the EAP authenticator will start an authentication Consequently, the EAP authenticator will start an authentication
process for each message received in Step 0, sending the EAP Request/ process for each message received in Step 0, sending the EAP-Request/
Id (Step 1). Identity (Step 1).
To minimize the effects of this DoS attack, it is RECOMMENDED that To minimize the effects of this DoS attack, it is RECOMMENDED that
the EAP authenticator limit the rate at which it processes incoming the EAP authenticator limit the rate at which it processes incoming
messages in Step 0 to provide robustness against DoS attacks. The messages in Step 0 to provide robustness against DoS attacks. The
details of rate limiting are outside the scope of this specification. details of rate limiting are outside the scope of this specification.
Nevertheless, the rate of these messages is also limited by the Nevertheless, the rate of these messages is also limited by the
bandwidth available between the EAP peer and the EAP authenticator. bandwidth available between the EAP peer and the EAP authenticator.
This bandwidth will be especially limited in constrained links (e.g., This bandwidth will be especially limited in constrained links (e.g.,
Low-Power WANs (LPWANs)). Lastly, it is also RECOMMENDED to reduce Low-Power WANs (LPWANs)). Lastly, it is also RECOMMENDED to reduce
at a minimum the state in the EAP authenticator at least until the at a minimum the state in the EAP authenticator at least until the
EAP Response/Id is received by the EAP authenticator. EAP-Response/Identity is received by the EAP authenticator.
Another security-related concern is how to ensure that the EAP peer Another security-related concern is how to ensure that the EAP peer
joining the security domain can trust the EAP authenticator. This joining the security domain can trust the EAP authenticator. This
issue is elaborated in [RFC5247]. In particular, the EAP peer knows issue is elaborated in [RFC5247]. In particular, the EAP peer knows
it can trust the EAP authenticator because the key that is used to it can trust the EAP authenticator because the key that is used to
establish the security association is derived from the MSK. If the establish the security association is derived from the MSK. If the
EAP authenticator has the MSK, it is because the AAA server of the EAP authenticator has the MSK, it is because the AAA server of the
EAP peer trusted the EAP authenticator. EAP peer trusted the EAP authenticator.
9. IANA Considerations 9. IANA Considerations
9.1. CoAP-EAP Cipher Suites 9.1. CoAP-EAP Cipher Suites
IANA has created a new registry titled "CoAP-EAP Cipher Suites" under IANA has created a new registry titled "CoAP-EAP Cipher Suites" under
a new registry group named "CoAP-EAP Protocol". The registration a new registry group named "CoAP-EAP". The registration procedures
procedures are "Specification Required", "Private Use", and are "Specification Required", "Private Use", and "Standards Action
"Standards Action with Expert Review" (see [RFC8126]), as shown in with Expert Review" (see [RFC8126]), as shown in Table 1.
Table 1.
+===============+=====================================+ +===============+=====================================+
| Range | Registration Procedures | | Range | Registration Procedures |
+===============+=====================================+ +===============+=====================================+
| -65536 to -25 | Specification Required | | -65536 to -25 | Specification Required |
+---------------+-------------------------------------+ +---------------+-------------------------------------+
| -24 to -21 | Private Use | | -24 to -21 | Private Use |
+---------------+-------------------------------------+ +---------------+-------------------------------------+
| -20 to 23 | Standards Action with Expert Review | | -20 to 23 | Standards Action with Expert Review |
+---------------+-------------------------------------+ +---------------+-------------------------------------+
skipping to change at line 1057 skipping to change at line 1060
| 3 | 24, -16 | ChaCha20/Poly1305, SHA-256 | RFC 9820 | | 3 | 24, -16 | ChaCha20/Poly1305, SHA-256 | RFC 9820 |
+-------+------------+-----------------------------+-----------+ +-------+------------+-----------------------------+-----------+
| 4 | 24, -45 | ChaCha20/Poly1305, SHAKE256 | RFC 9820 | | 4 | 24, -45 | ChaCha20/Poly1305, SHAKE256 | RFC 9820 |
+-------+------------+-----------------------------+-----------+ +-------+------------+-----------------------------+-----------+
Table 2: CoAP-EAP Cipher Suites: Initial Registrations Table 2: CoAP-EAP Cipher Suites: Initial Registrations
9.2. CDDL in CoAP-EAP Information Elements 9.2. CDDL in CoAP-EAP Information Elements
IANA has created a new registry titled "CoAP-EAP Information IANA has created a new registry titled "CoAP-EAP Information
Elements" under a new registry group named "CoAP-EAP Protocol". The Elements" under a new registry group named "CoAP-EAP". The
registration procedures are "Standards Action with Expert Review", registration procedures are "Standards Action with Expert Review",
"Private Use", "Specification Required", and "Experimental Use" (see "Private Use", "Specification Required", and "Experimental Use" (see
[RFC8126]), as shown in Table 3. [RFC8126]), as shown in Table 3.
+================+=====================================+ +================+=====================================+
| Range | Registration Procedures | | Range | Registration Procedures |
+================+=====================================+ +================+=====================================+
| 0 to 23 | Standards Action with Expert Review | | 0 to 23 | Standards Action with Expert Review |
+----------------+-------------------------------------+ +----------------+-------------------------------------+
| 24 to 49 | Private Use | | 24 to 49 | Private Use |
skipping to change at line 1433 skipping to change at line 1436
Extensible Authentication Protocol with TLS 1.3", Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022, RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>. <https://www.rfc-editor.org/info/rfc9190>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and [RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>. <https://www.rfc-editor.org/info/rfc9200>.
[THREAD] Thread Group, "Thread Specification 1.3", 2023. [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] [TS133.501]
ETSI, "5G; Security architecture and procedures for 5G ETSI, "5G; Security architecture and procedures for 5G
System", V15.2.0, ETSI TS 133 501, 2018. System", V18.9.0, ETSI TS 133 501, April 2025,
<https://www.etsi.org/deliver/
[ZigbeeIP] Zigbee Alliance, "Zigbee IP Specification (Zigbee Document etsi_ts/133500_133599/133501/18.09.00_60/
095023r34)", 2014. ts_133501v180900p.pdf>.
Appendix A. Flow of Operation (DTLS Establishment) Appendix A. Flow of Operation (DTLS Establishment)
CoAP-EAP makes it possible to derive a Pre-Shared Key (PSK) from the CoAP-EAP makes it possible to derive a Pre-Shared Key (PSK) from the
MSK to allow (D)TLS PSK-based authentication between the EAP peer and 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 the EAP authenticator instead of using OSCORE. In the case of using
(D)TLS to establish a security association, there is a limitation on (D)TLS to establish a security association, there is a limitation on
the use of intermediaries between the EAP peer and the EAP the use of intermediaries between the EAP peer and the EAP
authenticator, as (D)TLS breaks the end-to-end communications when authenticator, as (D)TLS breaks the end-to-end communications when
using intermediaries such as proxies. using intermediaries such as proxies.
skipping to change at line 1463 skipping to change at line 1469
when (D)TLS is used to protect the communication between the EAP peer when (D)TLS is used to protect the communication between the EAP peer
and the EAP authenticator using the keying material exported by the and the EAP authenticator using the keying material exported by the
EAP authentication. The general flow is essentially the same as in EAP authentication. The general flow is essentially the same as in
the case of OSCORE, except that DTLS negotiation is established in the case of OSCORE, except that DTLS negotiation is established in
Step 7. Once DTLS negotiation has finished successfully, the EAP Step 7. Once DTLS negotiation has finished successfully, the EAP
peer is granted access to the domain. Step 7 MUST be interpreted by peer is granted access to the domain. Step 7 MUST be interpreted by
the EAP peer as an alternate success indication, which will end up the EAP peer as an alternate success indication, which will end up
with the MSK and the DTLS_PSK derivation for the (D)TLS with the MSK and the DTLS_PSK derivation for the (D)TLS
authentication based on the PSK. authentication based on the PSK.
EAP peer EAP authenticator EAP peer EAP authenticator
------------- ------------- ------------- -------------
... ...
| 2.01 Created Location-Path [/a/eap/(n)] | | 2.01 Created Location-Path [/a/eap/(n)] |
| Payload (EAP-X Resp) | | Payload(EAP-X-Resp) |
6) |---------------------------------------->| 6)|---------------------------------------->|
| | MSK | | MSK
| (D)TLS 1.3 Client Hello | | | (D)TLS 1.3 Client Hello | |
MSK 7) |<----------------------------------------| V MSK 7)|<----------------------------------------| v
| | | DTLS_PSK | | | DTLS_PSK
V |===============DTLS handshake============| v |============= DTLS handshake ============|
DTLS_PSK | | DTLS_PSK | |
<-(Protected with (D)TLS)-> <-- Protected with (D)TLS -->
Figure 9: CoAP-EAP Flow of Operation with DTLS Figure 9: CoAP-EAP Flow of Operation with DTLS
According to [RFC8446], the provision of the PSK out of band also According to [RFC8446], the provision of the PSK out of band also
requires the provision of the KDF hash algorithm and the PSK requires the provision of the KDF hash algorithm and the PSK
identity. To simplify the design in CoAP-EAP, the KDF hash algorithm 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 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, 2 (Figure 8) if one wants to use DTLS instead of OSCORE. For the
the PSK identity is derived from (RID-C) (RID-I) as defined in same reason, the PSK identity is derived from RID-C || RID-I as
Appendix A.1. defined in Appendix A.1.
Analogous to how the cipher suite is negotiated for OSCORE Analogous to how the cipher suite is negotiated for OSCORE
(Section 6.1), the EAP authenticator sends a list, in decreasing (Section 6.1), the EAP authenticator sends a list, in decreasing
order of preference, with the identifiers of the hash algorithms order of preference, with the identifiers of the hash algorithms
supported (Step 1). In the response, the EAP peer sends its choice. supported (Step 1). In the response, the EAP peer sends its choice.
This list is included in the payload after the EAP message with a This list is included in the payload after the EAP message with a
CBOR array that contains the cipher suites. This CBOR array is CBOR array that contains the cipher suites. This CBOR array is
enclosed as one of the elements of the CBOR Object used for enclosed as one of the elements of the CBOR Object used for
transporting information in CoAP-EAP (see Section 5). An example of transporting information in CoAP-EAP (see Section 5). An example of
how the fields are arranged in the CoAP payload can be seen in how the fields are arranged in the CoAP payload can be seen in
Figure 7. Figure 7.
If there is no CBOR array specifying the cipher suites, the default If there is no CBOR array specifying the cipher suites, the default
cipher suites are applied. If the EAP authenticator sends a cipher suites are applied. If the EAP authenticator sends a
restricted list of cipher suites that can be accepted, it MUST restricted list of cipher suites that can be accepted, it MUST
include the default value 0, since it is mandatory to implement. The include the default value 0, since it is mandatory to implement. The
EAP peer will have at least that option available. EAP peer will have at least that option available.
For DTLS, the negotiated cipher suite is used to determine the hash For DTLS, the negotiated cipher suite is used to determine the hash
function to be used to derive the "DTLS PSK" from the MSK. The function to be used to derive the "DTLS_PSK" from the MSK. The
following hash algorithms are considered: following hash algorithms are considered in cases where the
specification includes DTLS support in the future (TLS_SHA256,
TLS_SHA384, TLS_SHA512):
* 5) TLS_SHA256 * 5) TLS_SHA256
* 6) TLS_SHA384 * 6) TLS_SHA384
* 7) TLS_SHA512 * 7) TLS_SHA512
The inclusion of these values, apart from indicating the hash The inclusion of these values, apart from indicating the hash
algorithm, indicates that the EAP authenticator intends to establish algorithm, indicates that the EAP authenticator intends to establish
an OSCORE security association or a DTLS security association after an OSCORE security association or a DTLS security association after
the authentication is completed. If both options appear in the the authentication is completed. If both options appear in the
cipher suite negotiation, the OSCORE security association will be cipher suite negotiation, the OSCORE security association will be
preferred over DTLS. preferred over DTLS.
A.1. Deriving DTLS PSK and Identity A.1. Deriving DTLS_PSK and Identity
To enable DTLS after an EAP authentication, Identity and the PSK for To enable DTLS after an EAP authentication, Identity and the PSK for
DTLS are defined. Identity in this case is generated by DTLS are defined. Identity in this case is generated by
concatenating the exchanged Sender ID and the Recipient ID. concatenating the exchanged Sender ID and the Recipient ID.
CoAP-EAP PSK Identity = RID-C || RID-I CoAP-EAP PSK Identity = RID-C || RID-I
It is also possible to derive a PSK for DTLS [RFC9147], referred to It is also possible to derive a PSK for DTLS [RFC9147], referred to
here as "DTLS PSK", from the MSK between both the EAP peer and EAP 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 authenticator if required. The length of the DTLS_PSK will depend on
the cipher suite. To have keying material with sufficient length, a the cipher suite. To have keying material with sufficient length, a
key of 32 bytes is derived that can be truncated later if needed: key of 32 bytes is derived that can be truncated later if needed:
DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length) DTLS_PSK = KDF(MSK, "CoAP-EAP DTLS_PSK", length)
where: where:
* The MSK is exported by the EAP method. * The MSK is exported by the EAP method.
* "CoAP-EAP DTLS PSK" is the ASCII code representation of the non- * "CoAP-EAP DTLS_PSK" is the ASCII code representation of the non-
NULL-terminated string (excluding the double quotes around it). NULL-terminated string (excluding the double quotes around it).
* length is the size of the output key material. * length is the size of the output key material.
Appendix B. Using CoAP-EAP for Distributing Key Material for IoT Appendix B. Using CoAP-EAP for Distributing Key Material for IoT
Networks Networks
Similarly to the example in Appendix A.1, where a shared key PSK for Similarly to the example in Appendix A.1, where a PSK for DTLS is
DTLS is derived, it is possible to provide key material to different derived, it is possible to provide key material to different link
link layers after the CoAP-EAP authentication is complete. layers after the CoAP-EAP authentication is complete.
For example, CoAP-EAP could be used to derive the PSK required to run 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 the Constrained Join Protocol (CoJP) for IPv6 over the TSCH mode of
IEEE 802.15.4e (6TiSCH) [RFC9031]. ("TSCH" stands for "Time-Slotted IEEE 802.15.4e (6TiSCH) [RFC9031]. ("TSCH" stands for "Time-Slotted
Channel Hopping".) Channel Hopping".)
Another example would be when a shared Network Key is required by the Another example would be when a shared Network Key is required by the
devices that join a network. An example of this Network Key can be devices that join a network. An example of this Network Key can be
found in Zigbee IP [ZigbeeIP] or the THREAD protocol [THREAD]. After found in the THREAD protocol [THREAD]. After CoAP-EAP execution, a
CoAP-EAP execution, a security association based on OSCORE protects security association based on OSCORE protects any exchange between
any exchange between the EAP peer and the EAP authenticator. This the EAP peer and the EAP authenticator. This security association
security association can be used for distributing the Network Key can be used for distributing the Network Key securely and other
securely and other required parameters. How the Network Key is required parameters. How the Network Key is distributed after a
distributed after a successful CoAP-EAP authentication is outside the successful CoAP-EAP authentication is outside the scope of this
scope of this document. document.
How a particular link-layer technology uses the MSK to derive further How a particular link-layer technology uses the MSK to derive further
key material for protecting the link layer or uses OSCORE protection key material for protecting the link layer or uses OSCORE protection
to distribute key material is outside the scope of this document. to distribute key material is outside the scope of this document.
Appendix C. Example Use Case Scenarios Appendix C. Example Use Case Scenarios
In IoT networks, for an EAP peer to act as a trustworthy entity In IoT networks, for an EAP peer to act as a trustworthy entity
within a security domain, certain key material needs to be shared within a security domain, certain key material needs to be shared
between the EAP peer and the EAP authenticator. between the EAP peer and the EAP authenticator.
skipping to change at line 1659 skipping to change at line 1667
it contacts EAP authenticator C for authorization to access EAP it contacts EAP authenticator C for authorization to access EAP
peer B and obtain all the required information to do that securely peer B and obtain all the required information to do that securely
(e.g., keys, tokens, authorization information, etc.). This phase (e.g., keys, tokens, authorization information, etc.). This phase
does NOT require the usage of CoAP-EAP. The details of this phase does NOT require the usage of CoAP-EAP. The details of this phase
are outside the scope of this document; the ACE framework is used are outside the scope of this document; the ACE framework is used
for this purpose. See [RFC9200]. for this purpose. See [RFC9200].
* In the third phase, EAP peer A can access EAP peer B with the * In the third phase, EAP peer A can access EAP peer B with the
credentials and information obtained from EAP authenticator C credentials and information obtained from EAP authenticator C
during the second phase. This access can be repeated without during the second phase. This access can be repeated without
contacting the EAP authenticator, while the credentials given to A contacting the EAP authenticator, as long as the credentials given
are still valid. The details of this phase are outside the scope to A are still valid. The details of this phase are outside the
of this document. scope of this document.
It is worth noting that the first phase with CoAP-EAP is required to It is worth noting that to join EAP authenticator C's domain, the
join EAP authenticator C's domain. Once it is performed first phase (authentication via CoAP-EAP) is required. Once it is
successfully, the communications are local to EAP authenticator C's performed successfully, the communications are local to EAP
domain and there is no need to perform a new EAP authentication as authenticator C's domain and there is no need to perform a new EAP
long as the key material is still valid. When the keys are about to authentication as long as the key material is still valid. When the
expire, the EAP peer can engage in a re-authentication to renew the keys are about to expire, the EAP peer can engage in a re-
key material, as explained in Section 3.3. authentication to renew the key material, as explained in
Section 3.3.
C.2. Example 2: Multiple Domains with AAA Infrastructures C.2. Example 2: Multiple Domains with AAA Infrastructures
A device (A) of the domain acme.org uses a specific kind of A device (A) of the domain acme.org uses a specific kind of
credential (e.g., AKA) and intends to join the um.es domain. This credential and intends to join the um.es domain. This user does not
user does not belong to this domain, for which it first performs a belong to this domain, for which it first performs a client
client registration using CoAP-EAP. To do this, it interacts with registration using CoAP-EAP. To do this, it interacts with the EAP
the EAP authenticator's domain, which in turn communicates with a AAA authenticator's domain, which in turn communicates with a AAA
infrastructure (acting as a AAA client). Through the local AAA infrastructure (acting as a AAA client). Then, the local AAA server
server communicate with the home AAA server to complete the communicates with the home AAA server to complete the authentication.
authentication and integrate the device as a trustworthy entity into This way, the device can be considered as a trustworthy entity within
EAP authenticator C's domain. In this scenario, the AS, in the role EAP authenticator C's domain. In this scenario, the AS, in the role
of the EAP authenticator, receives the key material from the AAA of the EAP authenticator, receives the key material from the AAA
infrastructure. infrastructure.
C.3. Example 3: Single Domain with a AAA Infrastructure C.3. Example 3: Single Domain with a AAA Infrastructure
In this scenario, a university campus has several faculty buildings, In this scenario, a university campus has several faculty buildings,
where each building has its criteria or policies in place to manage where each building has its criteria or policies in place to manage
EAP peers under an AS. All buildings belong to the same domain EAP peers under an AS. All buildings belong to the same domain
(e.g., um.es). All these buildings are managed with a AAA (e.g., um.es). All these buildings are managed with a AAA
skipping to change at line 1736 skipping to change at line 1745
available until the EAP peer is authenticated, specific support for available until the EAP peer is authenticated, specific support for
this EAP lower layer has to be defined to allow CoAP-EAP messages to 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 be exchanged between the EAP peer and the EAP authenticator. For
example, in IEEE 802.15.4 networks, a new Key Management Protocol 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 (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 802.15.9 [IEEE802159], where it can be assumed that the device has at
least a link-layer IPv6 address. least a link-layer IPv6 address.
When the EAP peer intends to be admitted into the network, it would 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 search for an entity that offers the CoAP-EAP service, be it directly
via the EAP authenticator or through an intermediary (i.e., proxy). via the EAP authenticator or through an intermediary (e.g., proxy).
See Section 3.1. See Section 3.1.
CoAP-EAP will run between the EAP peer and the EAP authenticator or 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 through an intermediary entity such as a proxy, as happens in a mesh
network, where the EAP authenticator could be placed one or more hops network, where the EAP authenticator could be placed one or more hops
away from the EAP peer. In the case that a proxy participates in 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 CoAP-EAP, it will be because it is already a trustworthy entity
within the domain and communicates through a secure channel with the within the domain and communicates through a secure channel with the
EAP authenticator, as illustrated by Figure 10. EAP authenticator, as illustrated by Figure 10.
If the EAP peer cannot connect to the EAP authenticator directly, the 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 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 to perform the authentication (i.e., can connect via an intermediary
entity (proxy) that is already part of the network (already shares entity (e.g., proxy) that is already part of the network (already
key material and communicates through a secure channel with the shares key material and communicates through a secure channel with
authenticator) and can aid in running CoAP-EAP). the authenticator) and can aid in running CoAP-EAP).
When CoAP-EAP is completed and the OSCORE security association is When CoAP-EAP is completed and the OSCORE security association is
established with the EAP authenticator, the EAP peer receives the established with the EAP authenticator, the EAP peer receives the
local configuration parameters for the network (e.g., a network key) local configuration parameters for the network (e.g., a Network Key)
and can configure a global IPv6 address. Moreover, there is no need and can configure a global IPv6 address. Moreover, there is no need
for a CoAP proxy after a successful authentication. for an intermediary entity after a successful authentication.
For removal, if the EAP authenticator decides to remove a particular For removal, if the EAP authenticator decides to remove a particular
EAP peer from the network or the peer itself intends to leave, either 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 the EAP peer or the EAP authenticator can directly send a DELETE
command to explicitly express that the network access state is command to explicitly express that the network access state is
removed, and the device will no longer belong to the network. Thus, removed, and the device will no longer belong to the network. Thus,
any state related to the EAP peer is removed in the EAP any state related to the EAP peer is removed in the EAP
authenticator. Forced removal can be done by sending new specific authenticator. Forced removal can be done by sending new specific
key material to the devices that still belong to the network, key material to the devices that still belong to the network,
excluding the removed device, following a model similar to CoJP for excluding the removed device, following a model similar to CoJP for
6TiSCH [RFC9031] or Zigbee IP [ZigbeeIP]. The specifics on how this 6TiSCH [RFC9031]. The specifics on how this process is to be done
process is to be done are outside the scope of this document. are outside the scope of this document.
+-------+ +--------+ +--------------+ +-------+ +--------+ +--------------+
| EAP | | CoAP | | EAP | | EAP | | CoAP | | EAP |
| peer |<------>| proxy |<------------------------->| authenticator| | peer |<------>| proxy |<------------------------->| authenticator|
+-------+ CoAP +--------+ CoAP +--------------+ +-------+ CoAP +--------+ CoAP +--------------+
OSCORE/DTLS OSCORE/DTLS
<--(security association)--> <-- security association -->
Figure 10: CoAP-EAP Through CoAP Proxy Figure 10: CoAP-EAP Through CoAP Proxy
Given that EAP is also used for network access authentication, this Given that EAP is also used for network access authentication, this
service can be adapted to other technologies -- for instance, to service can be adapted to other technologies -- for instance, to
provide network access control to very constrained technologies provide network access control to very constrained technologies
(e.g., Long Range (LoRa) networks). The authors of [LO-CoAP-EAP] (e.g., Long Range (LoRa) networks). The authors of [LO-CoAP-EAP]
provide a study of a minimal version of CoAP-EAP for LPWANs, with provide a study of a minimal version of CoAP-EAP for LPWANs, with
interesting results. In this specific case, compression as provided interesting results. In this specific case, compression as provided
by Static Context Header Compression (SCHC) for CoAP [RFC8824] can be by Static Context Header Compression (SCHC) for CoAP [RFC8824] can be
 End of changes. 83 change blocks. 
225 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.48.