EAP-based Authentication Service for 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 of 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 (e.g., an intermediary proxy). The discovery process is out of the scope of this document.¶

The CoAP-EAP application can be accessed through the URI "coap-eap" for the trigger message (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 to discover the IPv6 address of the EAP authenticator or intermediary entity. For example, on a 6LoWPAN network, the Border Router will typically act as the EAP authenticator hence, after receiving the Router Advertisement (RA) messages from the Border Router, the EAP peer may engage on the CoAP-EAP exchange. Different protocols can be used to discover the IP of the EAP authenticator. Examples of such protocols are Multicast DNS (mDNS) [RFC6762] or DHCPv6 [RFC8415].¶

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, we represent the chosen EAP method by using a generic name (EAP-X). The flow assumes that the EAP peer knows the EAP authenticator implements the CoAP-EAP service. A CoAP-EAP message has a media type application/coap-eap, See Section 9.5.¶

The steps of the operation are as follows:¶

• Step 0. The EAP peer MUST start the CoAP-EAP process by sending a "POST /.well-known/coap-eap" request (trigger message). This message carries the 'No-Response' [RFC7967] CoAP option to avoid waiting for a response that is not needed. This is the only message where the EAP authenticator acts as a CoAP server and the EAP peer as a CoAP client. The message also includes a URI in the payload of the message to indicate the resource where the EAP authenticator MUST send the next message. The name of the resource is selected by the CoAP server.¶

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

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

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

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

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

• Step 1. The EAP authenticator sends a POST message to the resource indicated in Step 0 (e.g., '/a/eap/1'). The payload in this message contains the first EAP message (EAP Request/Identity), the Recipient ID of the EAP authenticator (RID-C) for OSCORE, and MAY contain a CBOR array with a list of cipher suites (CS) for OSCORE. If the cipher suite list is not included, the default cipher suite for OSCORE is used. The details of the cipher suite negotiation are discussed in Section 6.1.¶

• Step 2. The EAP peer processes the POST message sending the EAP request (EAP-Req/Id) to the EAP peer state machine, which returns an EAP response (EAP Resp/Id). Then, assigns a new resource to the ongoing authentication process (e.g., '/a/eap/2'), and deletes the previous one ('/a/eap/1'). Finally, sends a '2.01 Created' response with the new resource identifier in the Location-Path (and/or Location-Query) options for the next step. The EAP response, the Recipient ID of the EAP peer (RID-I) and the selected cipher suite for OSCORE are included in the payload. In this step, the EAP peer MAY create an OSCORE security context (see Section 6.2). The required Master Session Key (MSK) will be available once the EAP authentication is successful in step 7.¶

• Steps 3-6. From now on, the EAP authenticator and the EAP peer will exchange EAP packets related to the EAP method (EAP-X), transported in the CoAP message payload. The EAP authenticator will use the POST method to send EAP requests to the EAP peer. The EAP peer will use a response to carry the EAP response in the payload. EAP requests and responses are represented in Figure 3 using the nomenclature (EAP-X-Req and EAP-X-Resp, respectively). When a POST message arrives (e.g., '/a/eap/1') carrying an EAP request message, if processed correctly by the EAP peer state machine, returns an EAP Response. Along with each EAP Response, a new resource is created (e.g., '/a/eap/3') for processing the next EAP request and the ongoing resource (e.g., '/a/eap/2') is erased. This way, ordering guarantee is achieved. Finally, an EAP response is sent in the payload of a CoAP response that will also indicate the new resource in the Location-Path (and/or Location-Query) Options. In case there is an error processing a legitimate message, the server will return a (4.00 Bad Request). There is a discussion about error handling in Section 3.5.¶

• Step 7. When the EAP authentication ends with success, the EAP authenticator obtains the Master Session Key (MSK) exported by the EAP method, an EAP Success message, and some authorization information (e.g., session lifetime) [RFC5247]. The EAP authenticator creates the OSCORE security context using the MSK and Recipient ID of both entities exchanged in Steps 1 and 2. The establishment of the OSCORE Security Context is defined in Section 6.2. Then, the EAP authenticator sends the POST message protected with OSCORE for key confirmation including the EAP Success. The EAP authenticator MAY also send a Session Lifetime, in seconds, which is represented with an unsigned integer in a CBOR object (see Section 5). If this Session Lifetime is not sent, the EAP peer assumes a default value of 8 hours, as RECOMMENDED in [RFC5247]. The verification of the received OSCORE-protected POST message using RID-I (Recipient ID of the EAP peer) sent in Step 2 is considered by the EAP peer as an alternate indication of success ([RFC3748]). The EAP peer state machine in the EAP peer interprets the alternate indication of success similarly to the arrival of an EAP Success and returns the MSK, which is used for the OSCORE security context in the EAP peer to process the protected POST message received from the EAP authenticator.¶

• Step 8. If the EAP authentication and the verification of the OSCORE-protected POST in Step 7 is successful, then the EAP peer answers with an OSCORE-protected '2.04 Changed'. From this point on, communication with the last resource (e.g., '/a/eap/(n)') MUST be protected with OSCORE. If allowed by application policy, the same OSCORE security context MAY be used to protect communication to other resources between the same endpoints.¶

       EAP peer                              EAP authenticator
     -------------                            ------------
         |  POST /.well-known/coap-eap             |
       0)|  No-Response                            |
         |  Payload("/a/eap/1")                    |
         |---------------------------------------->|
         |                           POST /a/eap/1 |
         |          Payload(EAP Req/Id||CS||RID-C) |
       1)|<----------------------------------------|
         | 2.01 Created Location-Path [/a/eap/2]   |
         | Payload(EAP Resp/Id||CS||RID-I)         |
       2)|---------------------------------------->|
         |                           POST /a/eap/2 |
         |                     Payload(EAP-X Req)  |
       3)|<----------------------------------------|
         | 2.01 Created Location-Path [/a/eap/3]   |
         | Payload(EAP-X Resp)                     |
       4)|---------------------------------------->|
                            ....
         |                     POST /a/eap/(n-1)   |
         |                     Payload(EAP-X Req)  |
       5)|<----------------------------------------|
         | 2.01 Created Location-Path [/a/eap/(n)] |
         | Payload (EAP-X Resp)                    |
       6)|---------------------------------------->|
         |                                         |  MSK
         |                         POST /a/eap/(n) |   |
         |                                  OSCORE |   V
         | Payload (EAP Success||*Session-Lifetime)| OSCORE
 MSK   7)|<----------------------------------------|  CTX
  |      |                                         |
  V      | 2.04 Changed                            |
OSCORE   | OSCORE                                  |
 CTX   8)|---------------------------------------->|
           (*) Session-Lifetime is optional.

3.3. Reauthentication

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 derive 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 establishes a default value of 8 hours to refresh the keying material. Certain EAP methods such as 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 the one 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 with success. 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 is renewed in another try of re-authentication.¶

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:¶

• A reference to an instance of the EAP (peer or authenticator/server) state machine.¶

• The resource for the next message in the negotiation (e.g., '/a/eap/2')¶

• The MSK is exported when the EAP authentication is successful. CoAP-EAP can access the different variables by the EAP state machine (i.e., [RFC4137]).¶

• A reference to the OSCORE context.¶

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 needs to be expelled from the security domain. This 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.¶

             EAP peer                             EAP authenticator
           -------------                           -------------
                |                                         |
                |                       DELETE /a/eap/(n) |
                |                                  OSCORE |
                |<----------------------------------------|
                |                                         |
                | 2.02 Deleted                            |
                | OSCORE                                  |
                |---------------------------------------->|

3.5. Error handling

This section elaborates on how different errors are handled. From EAP authentication failure, a non-responding endpoint lost messages, or an initial POST message arriving out of place.¶

 EAP peer                              EAP authenticator
 ----------                              ----------
      |  *POST /.well-known/coap-eap            |
   0) |  No-Response                            |
      |  Payload("/a/eap/1")                    |
      |               ------------------------->|
      |                          POST /a/eap/1  |
      |                Payload (EAP Req/Id||CS) |
   1) |<----------------------------------------|
      |                                         |
      | 4.04 Not found                          |
      |---------------------------------------->|
      * Old

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 we need to consider 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 as the CoAP server. After that, in the remaining exchanges the roles are reversed, being the EAP peer, the CoAP server, and the EAP authenticator, the CoAP client. When using a proxy in the exchange, for message 0, the proxy will act as forward, and as reverse for the rest. Additionally, in the first exchange, the EAP peer as a CoAP client, sends the URI for the next CoAP message in the payload of a request. This is not the typical behavior, as URIs referring to new services/resources appear in Location-Path and/or Location-Query Options in CoAP responses. Hence, the proxy will have to treat the payload of message 0, 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). 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 the response to that message (Step 2), the EAP peer sends a response with the choice.¶

This list is included in the payload after the EAP message through a CBOR as explained previously. An example of how the fields are arranged in the CoAP payload can be seen in Figure 7. An example of the exchange with the cipher suite negotiation is shown in Figure 8, where can be appreciated the disposition of both EAP-Request/Identity and EAP-Response/Identity, followed by the CBOR object defined in Section 5, containing the cipher suite field for the cipher suite negotiation.¶

+-----+-----------+-------+------++-------------+
|Code |Identifier |Length | Data ||cipher suites|
+-----+-----------+-------+------++-------------+
          EAP Packet                CBOR Object

    EAP peer                                 EAP Auth.
 (CoAP server)                             (CoAP client)
 -------------                             -------------
       |                                         |
       |                  ...                    |
       |---------------------------------------->|
       |                          POST /a/eap/1  |
       |  Payload (EAP Req/Id, CBORArray[0,1,2]) |
    1) |<----------------------------------------|
       | 2.01 Created Location-Path [/a/eap/2]   |
       | Payload (EAP Resp/Id, CBORArray[0])     |
    2) |---------------------------------------->|
                          ...

In case there is no CBOR array stating the cipher suites, the default cipher suites are applied. If the EAP authenticator sends a restricted list of cipher suites that are willing to accept, 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 the ones established by OSCORE [RFC8613], which are COSE algorithms [RFC9053]. By default, the HKDF algorithm is SHA-256 and the AEAD algorithm is AES-CCM-16-64-128 [RFC9053]. Both are mandatory to implement. The other supported and negotiated cipher suites are the following:¶

• 0) AES-CCM-16-64-128, SHA-256 (default)¶

• 1) A128GCM, SHA-256¶

• 2) A256GCM, SHA-384¶

• 3) ChaCha20/Poly1305, SHA-256¶

• 4) ChaCha20/Poly1305, SHAKE256¶

This specification uses the (HMAC)-based key derivation function (HKDF) defined in [RFC5869] to derive the necessary key material. Since the key derivation process uses the MSK, which is considered fresh key material, we will use the HKDF-Expand function, which we will shorten here as KDF. Why the use of this funtion is enough, and it is not necessary to use KDF-Extract is explained in Section 8.1.¶

6.2. Deriving the OSCORE Security Context

The derivation of the security context for OSCORE allows securing the communication between the EAP peer and the EAP authenticator once the MSK has been exported, providing confidentiality, integrity, key confirmation (Steps 7 and 8), and downgrading attack detection.¶

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:¶

• The algorithms for OSCORE agreed in the cipher suite negotiation.¶

• The MSK exported by the EAP method. Discussion about the use of the MSK for key derivation is done in Section 8.¶

• CS is the concatenation of the content of the cipher suite negotiation, that is, the list of cipher suites sent by the EAP authenticator (Step 1) to the selected option by the EAP peer (Step 2). If any of the messages did not contain the CBOR array (default algorithms), the null string is used.¶

• "COAP-EAP OSCORE MASTER SECRET" is the ASCII code representation of the non-NULL terminated string (excluding the double quotes around it).¶

• CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated.¶

• length is the size of the output key material.¶

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

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

where:¶

• The algorithms are agreed upon in the cipher suite negotiation.¶

• The MSK is exported by the EAP method. Discussion about the use of the MSK for the key derivation is done in Section 8.¶

• CS is the concatenation of the content of the cipher suite negotiation, in the request and response. If any of the messages did not contain the CBOR array, the null string is used.¶

• "COAP-EAP OSCORE MASTER SALT" is the ASCII code representation of the non-NULL-terminated string (excluding the double quotes around it).¶

• CS and "COAP-EAP OSCORE MASTER SALT" are concatenated.¶

• length is the size of the output key material.¶

Since the MSK is used to derive the Master Key, the correct verification of the OSCORE protected request (Step 7) and response (Step 8) confirms 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 suites negotiation (which we refer to here as CS) is embedded in the Master Secret derivation. If an attacker changes the value of the cipher suite negotiation, the result will be different OSCORE security contexts, which ends up with a 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 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 Recipient ID for its Recipient Context.¶

7.1. CoAP as EAP lower layer

This section discusses the suitability of the CoAP protocol as 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, MIC, etc.). CoAP goes on top of UDP/TCP, which provides a checksum mechanism over its payload.¶

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 in the CoAP payload only the EAP message is sent. 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 || RID-I ) - EAP Response header (5 bytes), which leaves enough space for sending even lengthy identities. Nevertheless, this limitation can be overcome by using CoAP block-wise transfer[RFC7959]. Note: When EAP is proxied over an AAA framework, the Access-Request packets in RADIUS MUST contain a Framed-MTU attribute with the value 1024, and the Framed-MTU AVP to 1024 in DIAMETER This attribute signals the AAA server that it should limit its responses to 1024 octets.¶

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 the [RFC3748] states: "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, there is a comparison with another network layer-based EAP lower layer, PANA [RFC5191], in [coap-eap].¶

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 the ones we can find in IoT, with limited capabilities.¶

Note: For constrained devices and network scenarios, the use of the latest versions of EAP methods (EAP-TLS 1.3 [RFC9190]) is recommended in favor of older versions with the goal of economization.¶

8.1. Use of EAP Methods

This documents limits the use of EAP methods to the ones compliant with [RFC4017] specification, 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 in case AAA infrastructure is deployed.¶

In standalone mode, the authorization information will be in the EAP authenticator. If the pass-through mode is used, authorization data received from the AAA server can be delivered by the AAA protocol (e.g., RADIUS or Diameter). Providing more fine-grained authorization data can be with the transport of 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 ACE WG such as the use of OAuth [RFC9200], among other solutions, to provide Authentication and Authorization for Constrained Environments.¶

8.3. Allowing IP traffic connectivity 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 authorize exclusively unprotected IP traffic to be sent between the EAP peer and the EAP authenticator during the authentication with CoAP-EAP. Once the authentication is successful, the key material generated by the EAP authentication (MSK) and any other traffic can be authorized if it is protected. It is worth noting that if the EAP authenticator is not in the same link as the EAP peer and intermediate entity help with this process (i.e., CoAP proxy) and the same comment applies to the communication between the EAP peer and the intermediary.¶

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 MSK and Extended Master Session Key (EMSK) keys according to the EAP Key Management Framework [RFC5247] are fresh key material. Since only one authentication is established per EAP authenticator, there is no need to generate additional key material. In case 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 the [RFC6677], channel binding related to EAP, is sent through the EAP method supporting it.¶

To satisfy the requirements of the document, we need to send the EAP lower layer identifier (To be assigned by IANA), in the EAP Lower-Layer Attribute if RADIUS is used.¶

8.6. Additional Security Considerations

In the authentication process, there is a possibility of an entity forging 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) with the EAP authenticator as if they were sent by different EAP peers. Consequently, the EAP authenticator will start an authentication process for each message received in Step 0, sending the EAP Request/Id (Step 1).¶

To minimize the effects of this DoS attack, it is RECOMMENDED that the EAP authenticator limits the rate at which it processes incoming messages in Step 0 to provide robustness against denial of service (DoS) attacks. The details of rate limiting are outside the scope of this specification. Nevertheless, the rate of these messages is also limited by the bandwidth available between the EAP peer and the EAP authenticator. This bandwidth will be especially limited in constrained links (e.g., LPWAN). Lastly, it is also RECOMMENDED to reduce at a minimum the state in the EAP authenticator at least until the EAP Response/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 the EAP Key Management Framework [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 the new group name "CoAP-EAP protocol". The registration procedure is "Expert Review". The columns of the registry are Value, Array, and Description, where Value is an integer, and the other columns are text strings. The initial contents of the registry are:¶

• Value: -24¶

• Array: N/A¶

• Description: Reserved for Private Use¶

• Value: -23¶

• Array: N/A¶

• Description: Reserved for Private Use¶

• Value: -22¶

• Array: N/A¶

• Description: Reserved for Private Use¶

• Value: -21¶

• Array: N/A¶

• Description: Reserved for Private Use¶

• Value: 0¶

• Array: 10, -16¶

• Description: AES-CCM-16-64-128, SHA-256¶

• Value: 1¶

• Array: 1, -16¶

• Description: A128GCM, SHA-256¶

• Value: 2¶

• Array: 3, -43¶

• Description: A256GCM, SHA-384¶

• Value: 3¶

• Array: 24, -16¶

• Description: ChaCha20/Poly1305, SHA-256¶

• Value: 4¶

• Array: 24, -45¶

• Description: ChaCha20/Poly1305, SHAKE256¶

9.2. CoAP-EAP Information elements

IANA has created a new registry titled "CoAP-EAP Information element" under the new group name "CoAP-EAP protocol". The registration procedure is "Expert Review". The columns of the registry are Value, Name, and Description, where Value is an integer, and the other columns are text strings. The initial contents of the registry are:¶

• Value: 1¶

• Name: cipher suite¶

• Description: List of the proposed or selected COSE algorithms for OSCORE¶

• Value: 2¶

• Name: RID-C¶

• Description: It contains the Recipient ID of the EAP peer¶

• Value: 3¶

• Name: RID-I¶

• Description: It contains the Recipient ID of the EAP authenticator¶

• Value: 4¶

• Name: Session-Lifetime¶

• Description: Contains the time the session is valid in seconds¶

• Values: 65000 to 65535¶

• Name: Reserved¶

• Description: Reserved for experimentation¶

9.3. The Well-Known URI Registry

IANA has added the well-known URI "coap-eap" to the "Well-Known URIs" registry under the group name "Well-Known URIs" defined by [RFC8615]. The registration procedure is "Specification Required".¶

• URI suffix: coap-eap¶

• Change controller: IETF¶

• Specification document(s): [[this document]]¶

• Related information: None¶

• Status: permanent¶

9.4. The EAP lower layer identifier registry

IANA has added the identifier of CoAP-EAP to the registry "EAP Lower Layer" under the Extensible Authentication Protocol (EAP) Registry defined by [RFC6677]. The registration procedure is "Expert Review".¶

• Value: TBD.¶

• Lower Layer: CoAP-EAP¶

• Specification document(s): [[this document]]¶

9.5. Media Types Registry

IANA has added the media types "application/coap-eap" to the "Media Types" registry. The registration procedure is "Expert Review". 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 this document.¶

• Interoperability considerations: N/A¶

• Published specification: [[this document]]¶

• 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: See "Authors' Addresses" section.¶

• Intended usage: COMMON¶

• Restrictions on usage: N/A¶

• Author: See "Authors' Addresses" section.¶

• Change Controller: IESG¶

9.6. CoAP Content-Formats Registry

IANA has added the media types "application/coap-eap" to the "CoAP Content-Formats" registry under the group name "Constrained RESTful Environments (CoRE) Parameters" following the specification in Section 12.3 of [RFC7252]. The registration procedure is "IETF Review".¶

+-----------------------+----------+------+-------------------+
| Media Type            | Encoding | ID   | Reference         |
+-----------------------+----------+------+-------------------+
| application/coap-eap  | -        | TBD  | [[this document]] |
+-----------------------+----------+------+-------------------+

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 group name "Constrained RESTful Environments (CoRE) Parameters".¶

• Value: "core.coap-eap"¶

• Description: CoAP-EAP resource.¶

• Reference: [[this document]]¶

A.1. Deriving DTLS PSK and identity

To enable DTLS after an EAP authentication, we define the Identity and the PSK for DTLS. The 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 pre-shared key 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 later truncated if needed:¶

               DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length).

where:¶

• MSK is exported by the EAP method.¶

• "CoAP-EAP DTLS PSK" is the ASCII code representation of the non-NULL terminated string (excluding the double quotes around it).¶

• length is the size of the output key material.¶

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

In 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. In this instance, the EAP authenticator and the Authorization Server (AS) of ACE can be co-located.¶

Next, we exemplify how CoAP-EAP can be used to perform Client registration in a general way, 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. Let's start with EAP peer A. In the first phase, EAP peer A does not yet belong to EAP authenticator C's domain. Then, it communicates with C and authenticates with CoAP-EAP, which, optionally, communicates with the AAA server to complete the authentication process. If the authentication is successful, a fresh MSK is shared between C and EAP peer A. This key material allows EAP peer A to establish a security association with the C. Some authorization information may be also provided in this step. In case EAP is used in standalone mode, the AS itself having information about the devices can be the entity providing said authorization information.¶

If authentication and authorization are correct, EAP peer A has been enrolled in the EAP authenticator C's domain for some time. In particular, [RFC5247] recommends 8 hours, though the entity providing the authorization information can establish this lifetime. In the same manner, B needs to perform the same process with CoAP-EAP to be part of EAP authenticator C's domain.¶

In the second phase, when EAP peer A wants to talk with EAP peer B, it contacts EAP authenticator C for authorization to access EAP peer B and obtain all the required information to do that securely (e.g., keys, tokens, authorization information, etc.). This phase does NOT require the usage of CoAP-EAP. The details of this phase are out of the scope of this document, and the ACE framework is used for this purpose [RFC9200].¶

In the third phase, EAP peer A can access EAP peer B with the credentials and information obtained from EAP authenticator C in the second phase. This access can be repeated without contacting the EAP authenticator, while the credentials given to A are still valid. The details of this phase are out of the scope of this document.¶

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

C.2. Example 2: Multi-domain with AAA infrastructures

We assume we have a device (A) of the domain acme.org, which uses a specific kind of credential (e.g., AKA) and intends to join the um.es domain. This user does not belong to this domain, for which first it performs a client registration using CoAP-EAP. For this, it interacts with the EAP authenticator's domain, which in turn communicates with an AAA infrastructure (acting as AAA client). Through the local AAA server communicate with the home AAA server to complete the authentication and integrate the device as a trustworthy entity into the domain of EAP authenticator C. In this scenario, the AS under the role of the EAP authenticator receives the key material from the AAA infrastructure¶

C.3. Example 3: Single domain with AAA infrastructure

As a University Campus, we have several Faculty buildings and each one 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 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 AAA infrastructure

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

C.5. Other use cases