RFC 9820: Authentication Service Based on the Extensible Authentication Protocol (EAP) for Use with the Constrained Application Protocol (CoAP)

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Readers are expected to be familiar with the terms and concepts described in CoAP [RFC7252], EAP [RFC3748] [RFC5247], and OSCORE [RFC8613].¶

3.1. Discovery

Before the CoAP-EAP exchange takes place, the EAP peer needs to discover the EAP authenticator or the entity that will enable the CoAP-EAP exchange (i.e., an intermediary). The discovery process is outside the scope of this document.¶

The CoAP-EAP application can be accessed through the URI "coap-eap" for the trigger message (see Section 3.2, Step 0). The CoAP-EAP service can be discovered by asking directly about the services offered. This information can also be available in the resource directory [RFC9176].¶

Implementation notes: There are different methods for discovering the IPv6 address of the EAP authenticator or intermediary entity. For example, in a 6LoWPAN network, the Border Router will typically act as the EAP authenticator. Hence, after receiving the Router Advertisement (RA) messages from the Border Router, the EAP peer may engage in the CoAP-EAP exchange.¶

3.2. Flow of Operation (OSCORE Establishment)

Figure 3 shows the general flow of operation for CoAP-EAP to authenticate using EAP and establish an OSCORE Security Context. The flow does not show a specific EAP method. Instead, the chosen EAP method is represented by using a generic name (EAP-X). The flow assumes that the EAP peer knows the EAP authenticator implements the CoAP-EAP service. A CoAP-EAP message has the media type "application/coap-eap". See Section 9.5.¶

The steps for this flow of operation are as follows:¶

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

So, per Figure 3, the URI for the first resource would be "/a/eap/1".¶

3.3. Re-Authentication

When the CoAP-EAP state is close to expiring, the EAP peer may want to start a new authentication process (re-authentication) to renew the state. The main goal is to obtain new and fresh keying material (MSK/EMSK) that, in turn, allows deriving a new OSCORE Security Context, increasing the protection against key leakage. The keying material MUST be renewed before the expiration of the Session-Lifetime. By default, the EAP key management framework [RFC5247] establishes a default value of 8 hours to refresh the keying material. Certain EAP methods such as Nimble Out-of-Band Authentication for EAP (EAP-NOOB) [RFC9140] or EAP-AKA' [RFC5448] provide fast reconnect for quicker re-authentication. The EAP Re-authentication Protocol (ERP) [RFC6696] MAY also be used to avoid the repetition of the entire EAP exchange.¶

The re-authentication message flow will be the same as that shown in Figure 3. Nevertheless, two different CoAP-EAP states will be active during the re-authentication: the current CoAP-EAP state and the new CoAP-EAP state, which will be created once the re-authentication has finished successfully. Once the re-authentication is completed successfully, the current CoAP-EAP state is deleted and replaced by the new CoAP-EAP state. If for any reason the re-authentication fails, the current CoAP-EAP state will be available until it expires, or it will be renewed during a subsequent re-authentication attempt.¶

If the re-authentication fails, it is up to the EAP peer to decide when to start a new re-authentication before the current EAP state expires.¶

3.4. Managing the State of the Service

The EAP peer and the EAP authenticator keep state during the CoAP-EAP negotiation. The CoAP-EAP state includes several important parts:¶

Once created, the EAP authenticator MAY choose to delete the state as 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 mentioned in Section 3.3.¶

There are situations where the current CoAP-EAP state might need to be removed. For instance, due to its expiration or forced removal, the EAP peer has to be expelled from the security domain. Such an exchange is illustrated in Figure 4.¶

If the EAP authenticator deems it necessary to remove the CoAP-EAP state from the EAP peer before it expires, it can send a DELETE command in a request to the EAP peer, referencing the last CoAP-EAP state resource given by the CoAP server, whose identifier will be the last one received (e.g., "/a/eap/(n)" in Figure 3). This message is protected by the OSCORE security association to prevent forgery. Upon reception of this message, the CoAP server sends a response to the EAP authenticator with the code '2.02 Deleted', which is also protected by the OSCORE security association. If a response from the EAP peer does not arrive after EXCHANGE_LIFETIME, the EAP authenticator will remove the state.¶

3.5. Error Handling

This section elaborates on how different errors are handled: EAP authentication failure (Section 3.5.1), a non-responsive endpoint (Section 3.5.2), and duplicated messages (Section 3.5.3).¶

3.6. Proxy Operation in CoAP-EAP

The CoAP-EAP operation is intended to be compatible with the use of intermediary entities between the EAP peer and the EAP authenticator when direct communication is not possible. In this context, CoAP proxies can be used as enablers of the CoAP-EAP exchange.¶

This specification is limited to using standard CoAP [RFC7252] as well as standardized CoAP options [RFC8613]. It does not specify any addition in the form of CoAP options. This is expected to ease the integration of CoAP intermediaries in the CoAP-EAP exchange.¶

When using proxies in the CoAP-EAP exchange, it should be considered that the exchange contains a role-reversal process at the beginning of the exchange. In the first message, the EAP peer acts as a CoAP client and the EAP authenticator acts as the CoAP server. In the remaining exchanges, the roles are reversed (i.e., the EAP peer acts as the CoAP server, and the EAP authenticator acts as the CoAP client). When using a proxy in the exchange, for message 0 it will act as a forward proxy, and as a reverse proxy for the rest. Additionally, in the first exchange, the EAP peer, as a CoAP client, sends the URI for the next CoAP message in the payload of a request. This is not the typical behavior, as URIs referring to new services/resources appear in Location-Path and/or Location-Query Options in CoAP responses. Hence, the proxy will have to treat the payload of Message 0 as if it were a Location-Path Option of a CoAP response.¶

6.1. Cipher Suite Negotiation

OSCORE runs after the EAP authentication, using the cipher suite selected in the cipher suite negotiation (Steps 1 and 2 in Figure 3). To negotiate the cipher suite, CoAP-EAP follows a simple approach: The EAP authenticator sends a list, in decreasing order of preference, with the identifiers of the supported cipher suites (Step 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 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 suite negotiation is shown in Figure 8. The EAP Request (EAP-Req/Id) and EAP Response (EAP-Resp/Id) are sent; both messages include the CBOR Object (Section 5) containing the cipher suite field for the cipher suite negotiation.¶

If there is no CBOR array specifying the cipher suites, the default cipher suites are applied. If the EAP authenticator sends a restricted list of cipher suites that can be accepted, it MUST include the default value 0, since it is mandatory to implement. The EAP peer will have at least that option available.¶

The cipher suite requirements are inherited from those established by OSCORE [RFC8613], which are COSE algorithms [RFC9053]. By default, the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm is SHA-256 and the Authenticated Encryption with Associated Data (AEAD) algorithm is AES-CCM-16-64-128 [RFC9053]. ("HMAC" stands for "Hashed Message Authentication Code".) Both are mandatory to implement. The other supported and negotiated cipher suites are 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):¶

This specification uses the HKDF as defined in [RFC5869] to derive the necessary key material. Since the key derivation process uses the MSK, which is considered fresh key material, the HKDF-Expand 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 necessary to use KDF-Extract.¶

6.2. Deriving the OSCORE Security Context

The derivation of the OSCORE Security Context allows securing the communication between the EAP peer and the EAP authenticator once the MSK has been exported, providing confidentiality, integrity, key confirmation (Steps 7 and 8 in Figure 3), and detection of downgrading attacks.¶

Once the Master Secret and Master Salt are derived, they can be used to derive the rest of the OSCORE Security Context (see Section 3.2.1 of [RFC8613]). It should be noted that the ID Context is not provided for the OSCORE Security Context derivation.¶

The Master Secret can be derived by using the chosen cipher suite and the KDF as follows:¶

Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length)

where:¶

Similarly to the Master Secret, the Master Salt can be derived as follows:¶

Master Salt = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SALT", length)

where:¶

Since the MSK is used to derive the Master Key, the correct verification of the OSCORE-protected request (Step 7) and response (Step 8) confirms that the EAP authenticator and the EAP peer have the same Master Secret, achieving key confirmation.¶

To prevent a downgrading attack, the content of the cipher suite (referred to here as "CS") negotiation is embedded in the Master Secret derivation. If an attacker changes the value of the cipher suite negotiation, the result will be different OSCORE Security Contexts, which in turn will result in failure in Steps 7 and 8.¶

The EAP authenticator will use the Recipient ID of the EAP peer (RID-I) as the Sender ID for its OSCORE Sender Context. The EAP peer will use this value as the Recipient ID for its Recipient Context.¶

The EAP peer will use the Recipient ID of the EAP authenticator (RID-C) as the Sender ID for its OSCORE Sender Context. The EAP authenticator will use this value as the Recipient ID for its Recipient Context.¶

7.1. CoAP as the EAP Lower Layer

This section discusses the suitability of CoAP as the EAP lower layer and reviews the requisites imposed by EAP on any protocol transporting EAP. What EAP expects from its lower layers can be found in Section 3.1 of [RFC3748], which is elaborated next:¶

Unreliable transport:

EAP does not assume that lower layers are reliable, but it can benefit from a reliable lower layer. In this sense, CoAP provides a reliability mechanism (e.g., using Confirmable messages).¶

Lower-layer error detection:

EAP relies on lower-layer error detection (e.g., CRC, checksum, Message Integrity Check (MIC), etc.). For simplicity, CoAP-EAP delegates error detection to the lower layers, such as the link layer or transport layer (e.g., UDP over IPv6 or TCP).¶

Lower-layer security:

EAP does not require security services from the lower layers.¶

Minimum MTU:

Lower layers need to provide an EAP MTU size of 1020 octets or greater. CoAP assumes an upper bound of 1024 octets for its payload, which covers the EAP requirements when only the EAP message is sent in the CoAP payload. In the case of Messages 1 and 2 in Figure 3, those messages have extra information apart 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 the identity being used to the CoAP payload maximum size (1024) - len( CS-I || RID-I ) - EAP Response header (5 bytes), which leaves enough space for sending even lengthy identities. Nevertheless, this limitation can be overcome by using CoAP block-wise transfers [RFC7959]. Note: When EAP is proxied over a AAA framework, the Access-Request packets in RADIUS MUST contain a Framed-MTU attribute with a value of 1024 and, in Diameter, the Framed-MTU Attribute-Value Pair (AVP) with a value of 1024. This information signals the AAA server that it should limit its responses to 1024 octets.¶

Ordering guarantees:

EAP relies on lower-layer ordering guarantees for correct operation. Regarding message ordering, every time a new message arrives at the authentication service hosted by the EAP peer, a new resource is created, and this is indicated in a '2.01 Created' response code along with the name of the new resource via Location-Path or Location-Query Options. This way, the application shows that its state has advanced.¶

Although [RFC3748] states that "EAP provides its own support for duplicate elimination and retransmission," EAP is also reliant on lower-layer ordering guarantees. In this regard, [RFC3748] talks about possible duplication and says, "Where the lower layer is reliable, it will provide the EAP layer with a non-duplicated stream of packets. However, while it is desirable that lower layers provide for non-duplication, this is not a requirement." CoAP provides a non-duplicated stream of packets and accomplishes the desirable non-duplication. In addition, [RFC3748] says that when EAP runs over a reliable lower layer "the authenticator retransmission timer SHOULD be set to an infinite value, so that retransmissions do not occur at the EAP layer."¶

7.2. Size of the EAP Lower Layer vs. EAP Method Size

Regarding the impact that an EAP lower layer will have on the number of bytes of the whole authentication exchange, [CoAP-EAP] provides a comparison with another network-layer-based EAP lower layer, the Protocol for Carrying Authentication for Network Access (PANA) as defined in [RFC5191].¶

The EAP method being transported will take most of the exchange. However, the impact of the EAP lower layer cannot be ignored, especially in very constrained communication technologies such as those with limited capabilities (e.g., as can be found in IoT networks).¶

Note: To improve efficiency in environments with constrained devices and networks, the latest versions of EAP methods (e.g., EAP-AKA' [RFC5448], EAP-TLS 1.3 [RFC9190]) are recommended over older versions. EAP methods more adapted for IoT networks (e.g., EAP-NOOB [RFC9140], EAP-EDHOC [EAP-EDHOC], etc.) are also recommended.¶

8.1. Use of EAP Methods

This document limits the use of EAP methods to those compliant with [RFC4017], yielding strong and fresh session keys such as the MSK. By this assumption, the HKDF-Expand function is used directly, as clarified in [RFC5869].¶

8.2. Authorization

Authorization is part of bootstrapping. It serves to establish whether the EAP peer can join and the set of conditions it must adhere to. The authorization data will be gathered from the organization that is responsible for the EAP peer and sent to the EAP authenticator if a AAA infrastructure is deployed.¶

In standalone mode, the authorization information will be in the EAP authenticator. If pass-through mode is used, authorization data received from the AAA server can be delivered by the AAA protocol (e.g., RADIUS or Diameter). Providing more fine-grained authorization data can be done by transporting the data using the Security Assertion Markup Language (SAML) in RADIUS [RFC7833]. After bootstrapping, additional authorization information may be needed to operate in the security domain. This can be taken care of by the solutions proposed in the Authentication and Authorization for Constrained Environments (ACE) WG, such as the use of OAuth [RFC9200], among other solutions, to provide ACE.¶

8.3. Allowing CoAP-EAP Traffic to Perform Authentication

Since CoAP is an application protocol, CoAP-EAP assumes certain IP connectivity in the link between the EAP peer and the EAP authenticator to run. This link MUST only authorize unprotected IP traffic to be sent between the EAP peer and the EAP authenticator during the authentication with CoAP-EAP. Once the authentication is successful, the key material generated by the EAP authentication (MSK) and any other traffic can be authorized if it is protected. It is worth noting that if the EAP authenticator is not in the same link as the EAP peer and an intermediate entity (e.g., a CoAP proxy) helps with this process, this concept also applies to the communication between the EAP peer and the intermediary.¶

Alternatively, the link layer MAY provide support to transport CoAP-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 [IEEE802159]).¶

8.4. Freshness of the Key Material

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 per [RFC5247]. Since only one authentication is established per EAP authenticator, there is no need to generate additional key material. 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 additional key material as elaborated in Section 3.3.¶

8.5. Channel-Binding Support

According to [RFC6677], channel binding, as related to EAP, is sent through the EAP method supporting it.¶

To satisfy the requirements of this document, the EAP lower-layer identifier for CoAP-EAP (10, as assigned by IANA; see Section 9.4) needs to be sent, in the EAP Lower-Layer Attribute if RADIUS is used.¶

8.6. Additional Security Considerations

In the authentication process, it is possible for an entity to forge messages to generate denial-of-service (DoS) attacks on any of the entities involved. For instance, an attacker can forge multiple initial messages to start an authentication (Step 0 in Figure 3) with the EAP authenticator as if they were sent by different EAP peers. Consequently, the EAP authenticator will start an authentication process for each message received in Step 0, sending the EAP-Req/Id (Step 1).¶

To minimize the effects of this DoS attack, it is RECOMMENDED that the EAP authenticator limit the rate at which it processes incoming messages in Step 0 to provide robustness against DoS attacks. The details of rate limiting are outside the scope of this specification. Nevertheless, the rate of these messages is also limited by the bandwidth available between the EAP peer and the EAP authenticator. This bandwidth will be especially limited in constrained links (e.g., Low-Power WANs (LPWANs)). Lastly, it is also RECOMMENDED to reduce at a minimum the state in the EAP authenticator at least until the EAP-Resp/Id is received by the EAP authenticator.¶

Another security-related concern is how to ensure that the EAP peer joining the security domain can trust the EAP authenticator. This issue is elaborated in [RFC5247]. In particular, the EAP peer knows it can trust the EAP authenticator because the key that is used to establish the security association is derived from the MSK. If the EAP authenticator has the MSK, it is because the AAA server of the EAP peer trusted the EAP authenticator.¶

9.1. CoAP-EAP Cipher Suites

IANA has created a new registry titled "CoAP-EAP Cipher Suites" under a new registry group named "CoAP-EAP". The registration procedures are "Specification Required", "Private Use", and "Standards Action with Expert Review" (see [RFC8126]), as shown in Table 1.¶

The columns of the registry are Value, Algorithms, Description, and Reference, where Value is an integer and the other columns are text strings. The initial registrations are shown in Table 2.¶

9.2. CDDL in CoAP-EAP Information Elements

IANA has created a new registry titled "CoAP-EAP Information Elements" under a new registry group named "CoAP-EAP". The registration procedures are "Standards Action with Expert Review", "Private Use", "Specification Required", and "Experimental Use" (see [RFC8126]), as shown in Table 3.¶

The columns of the registry are Name, Label, CBOR Type, Description, and Reference, where Label is an integer and the other columns are text strings. The initial registrations are shown in Table 4.¶

9.3. The Well-Known URIs Registry

IANA has added the well-known URI "coap-eap" to the "Well-Known URIs" registry under the "Well-Known URIs" registry group defined by [RFC8615].¶

URI Suffix:

coap-eap¶

Reference:

RFC 9820¶

Status:

permanent¶

Change Controller:

IETF¶

9.4. The EAP Lower Layers Registry

IANA has added the identifier "CoAP-EAP" to the "EAP Lower Layers" registry (defined by [RFC6677]) under the "Extensible Authentication Protocol (EAP) Registry".¶

Value:

10¶

Lower Layer:

CoAP-EAP¶

Reference:

RFC 9820¶

9.5. Media Types Registry

IANA has added the media type "application/coap-eap" to the "Media Types" registry. Section 4 defines the format.¶

Type name:

application¶

Subtype name:

coap-eap¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary¶

Security considerations:

See Section 8 of RFC 9820.¶

Interoperability considerations:

N/A¶

Published specification:

RFC 9820¶

Applications that use this media type:

To be identified¶

Fragment identifier considerations:

N/A¶

Additional information:

Magic number(s):

N/A¶

File extension(s):

N/A¶

Macintosh file type code(s):

N/A¶

Person and email address to contact for further information:

ace@ietf.org¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

See the "Authors' Addresses" section of RFC 9820.¶

Change Controller:

IETF¶

9.6. CoAP Content-Formats Registry

IANA has added the media type "application/coap-eap" to the "CoAP Content-Formats" registry under the "Constrained RESTful Environments (CoRE) Parameters" registry group, following the specification in Section 12.3 of [RFC7252].¶

9.7. Resource Type (rt=) Link Target Attribute Values Registry

IANA has added the resource type "core.coap-eap" to the "Resource Type (rt=) Link Target Attribute Values" registry under the "Constrained RESTful Environments (CoRE) Parameters" registry group.¶

9.8. Expert Review Instructions

The IANA registries established in this document apply the "Specification Required", "Private Use", "Standards Action with Expert Review", and "Experimental Use" policies. (See also [RFC8126].) This section provides general guidelines for what experts should focus on, but as they are designated experts for a reason, they should be granted flexibility.¶

10.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC3748]

Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, <https://www.rfc-editor.org/info/rfc3748>.

[RFC5247]

Aboba, B., Simon, D., and P. Eronen, "Extensible Authentication Protocol (EAP) Key Management Framework", RFC 5247, DOI 10.17487/RFC5247, August 2008, <https://www.rfc-editor.org/info/rfc5247>.

[RFC6677]

Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, <https://www.rfc-editor.org/info/rfc6677>.

[RFC7252]

Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.

[RFC7959]

Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8323]

Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.

[RFC8613]

Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>.

[RFC8949]

Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.

10.2. Informative References

[CoAP-EAP]

Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP-Based Bootstrapping Service for the Internet of Things", Sensors, vol. 16, no. 3, DOI 10.3390/s16030358, 2016, <https://www.mdpi.com/1424-8220/16/3/358>.

[EAP-EDHOC]

Garcia-Carrillo, D., Marin-Lopez, R., Selander, G., Preuß Mattsson, J., and F. Lopez-Gomez, "Using the Extensible Authentication Protocol (EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC)", Work in Progress, Internet-Draft, draft-ietf-emu-eap-edhoc-05, 30 July 2025, <https://datatracker.ietf.org/doc/html/draft-ietf-emu-eap-edhoc-05>.

[EAP-Framework-IoT]

Sethi, M. and T. Aura, "Secure Network Access Authentication for IoT Devices: EAP Framework vs. Individual Protocols", IEEE Communications Standards Magazine, vol. 5, no. 3, pp. 34-39, DOI 10.1109/MCOMSTD.201.2000088, 2021, <https://ieeexplore.ieee.org/document/9579387>.

[IEEE802159]

IEEE, "IEEE Standard for Transport of Key Management Protocol (KMP) Datagrams", IEEE Std 802.15.9-2021, DOI 10.1109/IEEESTD.2022.9690134, January 2022, <https://doi.org/10.1109/IEEESTD.2022.9690134>.

[LO-CoAP-EAP]

Garcia-Carrillo, D., Marin-Lopez, R., Kandasamy, A., and A. Pelov, "A CoAP-Based Network Access Authentication Service for Low-Power Wide Area Networks: LO-CoAP-EAP", Sensors, vol. 17, no. 11, DOI 10.3390/s17112646, 2017, <https://www.mdpi.com/1424-8220/17/11/2646>.

[RFC4017]

Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March 2005, <https://www.rfc-editor.org/info/rfc4017>.

[RFC4137]

Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, "State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator", RFC 4137, DOI 10.17487/RFC4137, August 2005, <https://www.rfc-editor.org/info/rfc4137>.

[RFC4186]

Haverinen, H., Ed. and J. Salowey, Ed., "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, DOI 10.17487/RFC4186, January 2006, <https://www.rfc-editor.org/info/rfc4186>.

[RFC4764]

Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A Pre-Shared Key Extensible Authentication Protocol (EAP) Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, <https://www.rfc-editor.org/info/rfc4764>.

[RFC5191]

Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, May 2008, <https://www.rfc-editor.org/info/rfc5191>.

[RFC5433]

Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, DOI 10.17487/RFC5433, February 2009, <https://www.rfc-editor.org/info/rfc5433>.

[RFC5448]

Arkko, J., Lehtovirta, V., and P. Eronen, "Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')", RFC 5448, DOI 10.17487/RFC5448, May 2009, <https://www.rfc-editor.org/info/rfc5448>.

[RFC5869]

Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, DOI 10.17487/RFC5869, May 2010, <https://www.rfc-editor.org/info/rfc5869>.

[RFC6696]

Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., "EAP Extensions for the EAP Re-authentication Protocol (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012, <https://www.rfc-editor.org/info/rfc6696>.

[RFC7833]

Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and Confirmation Methods for the Security Assertion Markup Language (SAML)", RFC 7833, DOI 10.17487/RFC7833, May 2016, <https://www.rfc-editor.org/info/rfc7833>.

[RFC7967]

Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. Bose, "Constrained Application Protocol (CoAP) Option for No Server Response", RFC 7967, DOI 10.17487/RFC7967, August 2016, <https://www.rfc-editor.org/info/rfc7967>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8615]

Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.

[RFC8824]

Minaburo, A., Toutain, L., and R. Andreasen, "Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)", RFC 8824, DOI 10.17487/RFC8824, June 2021, <https://www.rfc-editor.org/info/rfc8824>.

[RFC9031]

Vučinić, M., Ed., Simon, J., Pister, K., and M. Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", RFC 9031, DOI 10.17487/RFC9031, May 2021, <https://www.rfc-editor.org/info/rfc9031>.

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, <https://www.rfc-editor.org/info/rfc9053>.

[RFC9140]

Aura, T., Sethi, M., and A. Peltonen, "Nimble Out-of-Band Authentication for EAP (EAP-NOOB)", RFC 9140, DOI 10.17487/RFC9140, December 2021, <https://www.rfc-editor.org/info/rfc9140>.

[RFC9147]

Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

[RFC9176]

Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and P. van der Stok, "Constrained RESTful Environments (CoRE) Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April 2022, <https://www.rfc-editor.org/info/rfc9176>.

[RFC9190]

Preuß Mattsson, J. and M. Sethi, "EAP-TLS 1.3: Using the Extensible Authentication Protocol with TLS 1.3", RFC 9190, DOI 10.17487/RFC9190, February 2022, <https://www.rfc-editor.org/info/rfc9190>.

[RFC9200]

Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and H. Tschofenig, "Authentication and Authorization for Constrained Environments Using the OAuth 2.0 Framework (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, <https://www.rfc-editor.org/info/rfc9200>.

[THREAD]

Kumar, S. and E. Dijk, "Thread 1.4 Features White Paper", September 2024, <https://www.threadgroup.org/Portals/0/Documents/Thread_1.4_Features_White_Paper_September_2024.pdf>.

[TS133.501]

ETSI, "5G; Security architecture and procedures for 5G System", V18.9.0, ETSI TS 133 501, April 2025, <https://www.etsi.org/deliver/etsi_ts/133500_133599/133501/18.09.00_60/ts_133501v180900p.pdf>.

A.1. Deriving DTLS_PSK and Identity

To enable DTLS after an EAP authentication, Identity and the PSK for DTLS are defined. Identity in this case is generated by concatenating the exchanged Sender ID and the Recipient ID.¶

                CoAP-EAP PSK Identity = RID-C || RID-I

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 authenticator if required. The length of the DTLS_PSK will depend on the cipher suite. To have keying material with sufficient length, a key of 32 bytes is derived that can be truncated later if needed:¶

                DTLS_PSK = KDF(MSK, "CoAP-EAP DTLS_PSK", length)

where:¶

C.1. Example 1: CoAP-EAP Using ACE

When using ACE, the process of client registration and provisioning of credentials to the client is not specified. The process of client registration and provisioning can be achieved using CoAP-EAP. Once the process of authentication with EAP is completed, the fresh key material is shared between the EAP peer and the EAP authenticator. With ACE, the EAP authenticator and the Authorization Server (AS) can be co-located.¶

Next, a general way to exemplify how client registration can be performed using CoAP-EAP is presented, to allow two EAP peers (A and B) to communicate and interact after a successful client registration.¶

EAP peer A wants to communicate with EAP peer B (e.g., to activate a light switch). The overall process is divided into three phases.¶

It is worth noting that to join EAP authenticator C's domain, the first phase (authentication via CoAP-EAP) is required. Once it is performed successfully, the communications are local to EAP authenticator C's domain and there is no need to perform a new EAP authentication as long as the key material is still valid. When the keys are about to expire, the EAP peer can engage in a re-authentication to renew the key material, as explained in Section 3.3.¶

C.2. Example 2: Multiple Domains with AAA Infrastructures

A device (A) of the domain acme.org uses a specific kind of credential and intends to join the um.es domain. This user does not belong to this domain, for which it first performs a client registration using CoAP-EAP. To do this, it interacts with the EAP authenticator's domain, which in turn communicates with a AAA infrastructure (acting as a AAA client). Then, the local AAA server communicates with the home AAA server to complete the authentication. 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 of the EAP authenticator, receives the key material from the AAA infrastructure.¶

C.3. Example 3: Single Domain with a AAA Infrastructure

In this scenario, a university campus has several faculty buildings, where each building has its criteria or policies in place to manage EAP peers under an AS. All buildings belong to the same domain (e.g., um.es). All these buildings are managed with a AAA infrastructure. A new device (A) with credentials from the domain (e.g., um.es) will be able to perform the device registration with an EAP authenticator (C) of any building if they are managed by the same general domain.¶

C.4. Example 4: Single Domain Without a AAA Infrastructure

In another case, without a AAA infrastructure, with an EAP authenticator that has co-located the EAP server, and using EAP standalone mode, all the devices can be managed within the same domain locally. Client registration of an EAP peer (A) with a Controller (C) can also be performed in the same manner.¶

C.5. Other Use Cases