Authentication Service Based on the Extensible Authentication Protocol (EAP) for Use with the Constrained Application Protocol (CoAP)
Extracted elements (29)
HATEOAS resource management — creating a new CoAP resource per EAP step and deleting the prior one — was chosen to provide ordering guarantees required by EAP without adding new CoAP options. Each '2.01 Created' response with a new Location-Path signals state advancement, leveraging standard CoAP mechanisms.
Only the HKDF-Expand function (not HKDF-Extract) is used for key derivation because the MSK exported by compliant EAP methods (RFC 4017) is already considered strong and fresh keying material. Using KDF-Extract in addition would be redundant and add unnecessary overhead on constrained devices.
The EAP peer acts as CoAP server and the EAP authenticator acts as CoAP client, reversing the typical IoT roles. This is because EAP Requests always travel from EAP server to EAP peer; mapping EAP Request/Response onto CoAP POST/Response requires the EAP peer to be the CoAP server so it can generate CoAP responses carrying EAP Responses.
CoAP assumes a maximum payload of 1024 octets, which satisfies EAP's minimum MTU requirement of 1020 octets for the common case. For identities or EAP methods exceeding this, CoAP block-wise transfers (RFC 7959) can be used to overcome the limitation.
CoAP proxies can be used between EAP peer and EAP authenticator. The proxy must handle the role-reversal at Step 0 (acting as forward proxy) and Step 1 onwards (acting as reverse proxy). It must also treat the URI in the Step 0 request payload as equivalent to a Location-Path Option in a response, which is non-standard CoAP behavior.
When CoAP-EAP runs over a reliable CoAP transport (Confirmable messages, CoAP over TCP/TLS/WebSockets per RFC 8323), the EAP retransmission timer SHOULD be set to an infinite value so that retransmissions do not occur at the EAP layer, as specified in RFC 3748 for reliable lower layers.
After successful EAP authentication and OSCORE key confirmation (Steps 7–8), all communication with the last CoAP-EAP resource MUST be protected with OSCORE. If application policy allows, the same OSCORE Security Context MAY be used to protect other resources between the same endpoints.
EAP methods used with CoAP-EAP MUST export cryptographic material, specifically an MSK of at least 64 octets and an EMSK of at least 64 octets, as specified in RFC 5247. Methods that do not export keying material cannot be used.
If a trigger message (POST /.well-known/coap-eap) arrives at the EAP authenticator during an ongoing authentication with the same EAP peer, the EAP authenticator MUST silently discard it to prevent duplicate session initiation.
If the EAP authenticator sends a restricted list of cipher suites, it MUST include the default value 0 (AES-CCM-16-64-128, SHA-256), since that cipher suite is mandatory to implement. The keying material MUST also be renewed before Session-Lifetime expiration.
It is RECOMMENDED that the EAP authenticator limit the rate at which it processes incoming trigger messages (Step 0) to mitigate denial-of-service attacks. It is also RECOMMENDED to minimize EAP authenticator state until EAP-Resp/Id is received.
On EAP authentication failure (EAP Failure sent in Step 7), the EAP peer MUST send a '4.01 Unauthorized' response in Step 8. Steps 7 and 8 are unprotected in this case because no MSK is exported and no OSCORE context is established.
The EAP peer MUST start the CoAP-EAP process by sending a POST to /.well-known/coap-eap (the trigger message), carrying the No-Response CoAP option and a URI payload indicating the resource where the EAP authenticator must send the next message.
The link between EAP peer and EAP authenticator MUST only authorize unprotected IP traffic during CoAP-EAP authentication. Once authentication succeeds, traffic MUST be protected using the derived MSK before it is authorized.
When EAP is proxied over a AAA framework, RADIUS Access-Request packets MUST carry a Framed-MTU attribute with a value of 1024; Diameter MUST use the Framed-MTU AVP with value 1024, to signal the AAA server to limit EAP response size.
CoAP-EAP uses HATEOAS for ordering: each EAP exchange step creates a new CoAP resource on the EAP peer (e.g., /a/eap/N), which is indicated via Location-Path or Location-Query Options in the response. The previous resource is deleted once the new one is created, ensuring strict message ordering.
The 8-step CoAP-EAP flow exchanges EAP messages over CoAP POST requests: the EAP peer sends a trigger (Step 0), the authenticator sends EAP-Req/Id with RID-C and optional cipher suites (Step 1), the peer responds with EAP-Resp/Id, RID-I, and selected cipher suite (Step 2), EAP method messages are exchanged (Steps 3–6), and the authenticator sends EAP Success in an OSCORE-protected POST for key confirmation (Step 7), confirmed by an OSCORE-protected 2.04 Changed (Step 8).
The CoAP-EAP state maintained by both endpoints includes: a reference to the EAP state machine instance, the resource URI for the next negotiation step, the exported MSK, and a reference to the OSCORE context. The EAP authenticator MAY delete the state via an OSCORE-protected DELETE command referencing the last resource.
The OSCORE Master Secret and Master Salt are derived as: Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length) and Master Salt = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SALT", length), where CS is the concatenation of the CS-C and CS-I CBOR arrays from the cipher suite negotiation.
IANA created the 'CoAP-EAP Cipher Suites' registry under the 'CoAP-EAP' registry group. Initial entries: 0 = AES-CCM-16-64-128 + SHA-256 (default, mandatory to implement), 1 = A128GCM + SHA-256, 2 = A256GCM + SHA-384, 3 = ChaCha20/Poly1305 + SHA-256, 4 = ChaCha20/Poly1305 + SHAKE256. Registration policies range from Standards Action with Expert Review (−20 to 23) to Specification Required.
IANA created the 'CoAP-EAP Information Elements' registry under the 'CoAP-EAP' group with initial entries: label 1 = Cipher Suite (CBOR Array), label 2 = RID-C (Byte String), label 3 = RID-I (Byte String), label 4 = Session-Lifetime (uint). Ranges 0–23 require Standards Action with Expert Review; 65001–65535 are Experimental Use.
IANA registered the well-known URI suffix 'coap-eap' in the Well-Known URIs registry, and registered 'CoAP-EAP' (value 10) in the EAP Lower Layers registry (RFC 6677). The media type 'application/coap-eap' (binary encoding) was added to the Media Types registry, and CoAP Content-Format ID 269 was assigned.
An attacker can forge multiple trigger messages (Step 0) to cause the EAP authenticator to start parallel EAP authentications, resulting in a DoS attack. Rate limiting of Step 0 processing is RECOMMENDED, and minimizing authenticator state until EAP-Resp/Id arrival further limits the attack surface.
Channel binding for CoAP-EAP requires sending the EAP lower-layer identifier (value 10, assigned by IANA) in the EAP Lower-Layer Attribute when RADIUS is used, per RFC 6677. This prevents cross-protocol binding attacks between CoAP-EAP and other EAP lower layers.
The cipher suite negotiation (CS-C and CS-I) is embedded in the OSCORE Master Secret derivation to prevent downgrading attacks. If an attacker alters the negotiated cipher suite values, the resulting OSCORE Security Contexts will differ between the two parties, causing OSCORE-protected messages in Steps 7 and 8 to fail.
The EAP peer can trust the EAP authenticator because the OSCORE security association key material is derived from the MSK. If the EAP authenticator possesses the MSK, it means the EAP peer's AAA server has already authenticated and trusted it. No additional nonce exchange is needed because the MSK/EMSK are intrinsically fresh per RFC 5247.
The CoAP-EAP state machine at the EAP peer removes state when EXCHANGE_LIFETIME triggers or the EAP peer state machine returns eapFail. At the EAP authenticator, state is removed when EXCHANGE_LIFETIME triggers or, in pass-through mode, the authenticator state machine returns aaaTimeout. During re-authentication, two states coexist; on success the old state is replaced.
In the CoAP-EAP payload (media type application/coap-eap), the trigger message (Step 0) carries only a relative URI. All other messages carry an EAP packet (Code + Identifier + Length + Data fields) immediately followed by the CoAP-EAP_Info CBOR Object for cipher suite negotiation and related parameters.
The CoAP-EAP_Info CBOR map carries four optional fields: label 1 = Cipher Suite (CBOR Array of ints, proposed or selected COSE algorithms); label 2 = RID-C (bstr, Recipient ID of EAP authenticator); label 3 = RID-I (bstr, Recipient ID of EAP peer); label 4 = Session-Lifetime (uint, seconds). Labels 65001–65535 are reserved for experimentation.