rfc9820v2.txt   rfc9820.txt 
skipping to change at line 179 skipping to change at line 179
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
described in CoAP [RFC7252], EAP [RFC3748] [RFC5247], and OSCORE described in CoAP [RFC7252], EAP [RFC3748] [RFC5247], and OSCORE
[RFC8613]. [RFC8613].
2. General Architecture 2. General Architecture
Figure 1 illustrates the architecture defined in this document. In Figure 1 illustrates the architecture defined in this document. In
this architecture, the EAP peer will act as a CoAP server for this this architecture, the EAP peer will act as a CoAP server for this
service and the domain EAP authenticator will act as a CoAP client. service and the domain EAP authenticator will act as a CoAP client.
The rationale behind this decision is that EAP requests will always The rationale behind this decision is that EAP Requests will always
travel from the EAP server to the EAP peer. Accordingly, EAP travel from the EAP server to the EAP peer. Accordingly, EAP
responses will always travel from the EAP peer to the EAP server. Responses will always travel from the EAP peer to the EAP server.
It is worth noting that the EAP authenticator MAY interact with a It is worth noting that the EAP authenticator MAY interact with a
backend AAA infrastructure when EAP pass-through mode is used, which backend AAA infrastructure when EAP pass-through mode is used, which
will place the EAP server in the AAA server that contains the will place the EAP server in the AAA server that contains the
information required to authenticate the EAP peer. information required to authenticate the EAP peer.
The protocol stack is described in Figure 2. CoAP-EAP is an The protocol stack is described in Figure 2. CoAP-EAP is an
application built on top of CoAP. On top of the application, there application built on top of CoAP. On top of the application, there
is an EAP state machine that can run any EAP method. In the case of is an EAP state machine that can run any EAP method. In the case of
this specification, the EAP method MUST support key derivation and this specification, the EAP method MUST support key derivation and
skipping to change at line 300 skipping to change at line 300
step of the authentication, the resource could have the following step of the authentication, the resource could have the following
format as an example "path/eap/counter", where: format as an example "path/eap/counter", where:
* "path" is some local path on the device to make the path unique. * "path" is some local path on the device to make the path unique.
This could be omitted if desired. This could be omitted if desired.
* "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, or EAP-Req/Id) and the Recipient ID of the EAP authenticator (RID-
and MAY contain a CBOR array with a list of proposed cipher suites C) for OSCORE, and MAY contain a CBOR array with a list of
(CS-C) for OSCORE. If the cipher suite list is not included, the proposed cipher suites (CS-C) for OSCORE. If the cipher suite
default cipher suite for OSCORE is used. The details of the list is not included, the default cipher suite for OSCORE is used.
cipher suite negotiation are discussed in Section 6.1. 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 * 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, the CoAP-EAP application an EAP Response (EAP-Response/Identity, or EAP-Resp/Id). Then,
assigns a new resource to the ongoing authentication process the CoAP-EAP application assigns a new resource to the ongoing
(e.g., '/a/eap/2') and deletes the previous one ('/a/eap/1'). authentication process (e.g., "/a/eap/2") and deletes the previous
Finally, the CoAP-EAP application sends a '2.01 Created' response one ("/a/eap/1"). Finally, the CoAP-EAP application sends a '2.01
with the new resource identifier in the Location-Path (and/or Created' response with the new resource identifier in the
Location-Query) Options for the next step. The EAP response, the Location-Path (and/or Location-Query) Options for the next step.
Recipient ID of the EAP peer (RID-I), and the selected cipher The EAP Response, the Recipient ID of the EAP peer (RID-I), and
suite for OSCORE (CS-I) are included in the payload. In this the selected cipher suite for OSCORE (CS-I) are included in the
step, the EAP peer may create an OSCORE Security Context (see payload. In this step, the EAP peer may create an OSCORE Security
Section 6.2). The required MSK will be available once the EAP Context (see Section 6.2). The required MSK will be available
authentication is successful (Step 7). 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 CoAP response to carry the EAP response in The EAP peer will use a CoAP response to carry the EAP Response in
the payload. EAP requests and responses are represented in the payload. EAP Requests and responses are represented in
Figure 3 using the nomenclature "EAP-X-Req" and "EAP-X-Resp", Figure 3 using the nomenclature "EAP-X-Req" and "EAP-X-Resp",
respectively. When a POST message arrives (e.g., '/a/eap/1') respectively. When a POST message arrives (e.g., "/a/eap/1")
carrying an EAP request message, if processed correctly by the EAP carrying an EAP Request message, if processed correctly by the EAP
peer state machine, it returns an EAP Response. Along with each peer state machine, it returns an EAP Response. Along with each
EAP 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., Success message, and some authorization information [RFC5247]
Session-Lifetime) [RFC5247]. The EAP authenticator creates the (e.g., Session-Lifetime). The EAP authenticator creates the
OSCORE Security Context using the MSK and Recipient ID of both OSCORE Security Context using the MSK and Recipient ID of both
entities exchanged in Steps 1 and 2. The establishment of the entities exchanged in Steps 1 and 2. The establishment of the
OSCORE 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") |
|---------------------------------------->| |---------------------------------------->|
skipping to change at line 451 skipping to change at line 452
expires. expires.
3.4. Managing the State of the Service 3.4. Managing the State of the Service
The EAP peer and the EAP authenticator keep state during the CoAP-EAP The EAP peer and the EAP authenticator keep state during the CoAP-EAP
negotiation. The CoAP-EAP state includes several important parts: negotiation. The CoAP-EAP state includes several important parts:
* A reference to an instance of the EAP (peer or authenticator/ * A reference to an instance of the EAP (peer or authenticator/
server) state machine. server) state machine.
* The resource for the next message in the negotiation (e.g., '/a/ * The resource for the next message in the negotiation (e.g., "/a/
eap/2'). eap/2").
* The MSK, which is exported when the EAP authentication is * The MSK, which is exported when the EAP authentication is
successful. CoAP-EAP can access the different variables via the successful. CoAP-EAP can access the different variables via the
EAP state machine (see [RFC4137]). EAP state machine (see [RFC4137]).
* A reference to the OSCORE context. * A reference to the OSCORE context.
Once created, the EAP authenticator MAY choose to delete the state as Once created, the EAP authenticator MAY choose to delete the state as
described in Figure 4. Conversely, the EAP peer may need to renew described in Figure 4. Conversely, the EAP peer may need to renew
the CoAP-EAP state because the key material is close to expiring, as the CoAP-EAP state because the key material is close to expiring, as
skipping to change at line 474 skipping to change at line 475
There are situations where the current CoAP-EAP state might need to There are situations where the current CoAP-EAP state might need to
be removed. For instance, due to its expiration or forced removal, be removed. For instance, due to its expiration or forced removal,
the EAP peer has to be expelled from the security domain. Such an the EAP peer has to be expelled from the security domain. Such an
exchange is illustrated in Figure 4. exchange is illustrated in Figure 4.
If the EAP authenticator deems it necessary to remove the CoAP-EAP If the EAP authenticator deems it necessary to remove the CoAP-EAP
state from the EAP peer before it expires, it can send a DELETE state from the EAP peer before it expires, it can send a DELETE
command in a request to the EAP peer, referencing the last CoAP-EAP command in a request to the EAP peer, referencing the last CoAP-EAP
state resource given by the CoAP server, whose identifier will be the state resource given by the CoAP server, whose identifier will be the
last one received (e.g., '/a/eap/(n)' in Figure 3). This message is last one received (e.g., "/a/eap/(n)" in Figure 3). This message is
protected by the OSCORE security association to prevent forgery. protected by the OSCORE security association to prevent forgery.
Upon reception of this message, the CoAP server sends a response to Upon reception of this message, the CoAP server sends a response to
the EAP authenticator with the code '2.02 Deleted', which is also the EAP authenticator with the code '2.02 Deleted', which is also
protected by the OSCORE security association. If a response from the protected by the OSCORE security association. If a response from the
EAP peer does not arrive after EXCHANGE_LIFETIME, the EAP EAP peer does not arrive after EXCHANGE_LIFETIME, the EAP
authenticator will remove the state. authenticator will remove the state.
EAP peer EAP authenticator EAP peer EAP authenticator
------------- ------------- ------------- -------------
| | | |
skipping to change at line 681 skipping to change at line 682
selected in the cipher suite negotiation (Steps 1 and 2 in Figure 3). selected in the cipher suite negotiation (Steps 1 and 2 in Figure 3).
To negotiate the cipher suite, CoAP-EAP follows a simple approach: To negotiate the cipher suite, CoAP-EAP follows a simple approach:
The EAP authenticator sends a list, in decreasing order of The EAP authenticator sends a list, in decreasing order of
preference, with the identifiers of the supported cipher suites (Step preference, with the identifiers of the supported cipher suites (Step
1 in Figure 8). In the response to that message (Step 2 in 1 in Figure 8). In the response to that message (Step 2 in
Figure 8), the EAP peer sends its choice. 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. The EAP request (EAP- suite negotiation is shown in Figure 8. The EAP Request (EAP-Req/Id)
Request/Identity) and EAP response (EAP-Response/Identity) are sent; and EAP Response (EAP-Resp/Id) are sent; both messages include the
both messages include the CBOR Object (Section 5) containing the CBOR Object (Section 5) containing the cipher suite field for the
cipher suite field for the cipher suite negotiation. 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.
skipping to change at line 991 skipping to change at line 992
needs to be sent, in the EAP Lower-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 in Figure 3) with initial messages to start an authentication (Step 0 in Figure 3) with
the EAP 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-Req/Id
Identity (Step 1). (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/Identity is received by the EAP authenticator. EAP-Resp/Id 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
skipping to change at line 1297 skipping to change at line 1298
[CoAP-EAP] Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP- [CoAP-EAP] Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP-
Based Bootstrapping Service for the Internet of Things", Based Bootstrapping Service for the Internet of Things",
Sensors, vol. 16, no. 3, DOI 10.3390/s16030358, 2016, Sensors, vol. 16, no. 3, DOI 10.3390/s16030358, 2016,
<https://www.mdpi.com/1424-8220/16/3/358>. <https://www.mdpi.com/1424-8220/16/3/358>.
[EAP-EDHOC] [EAP-EDHOC]
Garcia-Carrillo, D., Marin-Lopez, R., Selander, G., Preuß Garcia-Carrillo, D., Marin-Lopez, R., Selander, G., Preuß
Mattsson, J., and F. Lopez-Gomez, "Using the Extensible Mattsson, J., and F. Lopez-Gomez, "Using the Extensible
Authentication Protocol (EAP) with Ephemeral Diffie- Authentication Protocol (EAP) with Ephemeral Diffie-
Hellman over COSE (EDHOC)", Work in Progress, Internet- Hellman over COSE (EDHOC)", Work in Progress, Internet-
Draft, draft-ietf-emu-eap-edhoc-04, 4 June 2025, Draft, draft-ietf-emu-eap-edhoc-05, 30 July 2025,
<https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap- <https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-
edhoc-04>. edhoc-05>.
[EAP-Framework-IoT] [EAP-Framework-IoT]
Sethi, M. and T. Aura, "Secure Network Access Sethi, M. and T. Aura, "Secure Network Access
Authentication for IoT Devices: EAP Framework vs. Authentication for IoT Devices: EAP Framework vs.
Individual Protocols", IEEE Communications Standards Individual Protocols", IEEE Communications Standards
Magazine, vol. 5, no. 3, pp. 34-39, Magazine, vol. 5, no. 3, pp. 34-39,
DOI 10.1109/MCOMSTD.201.2000088, 2021, DOI 10.1109/MCOMSTD.201.2000088, 2021,
<https://ieeexplore.ieee.org/document/9579387>. <https://ieeexplore.ieee.org/document/9579387>.
[IEEE802159] [IEEE802159]
skipping to change at line 1514 skipping to change at line 1515
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 in cases where the following hash algorithms are considered in cases where the
specification includes DTLS support in the future (TLS_SHA256, specification includes DTLS support in the future:
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
 End of changes. 18 change blocks. 
48 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.48.