rfc9820.original   rfc9820.txt 
ACE Working Group R. Marin-Lopez Internet Engineering Task Force (IETF) R. Marin-Lopez
Internet-Draft University of Murcia Request for Comments: 9820 University of Murcia
Intended status: Standards Track D. Garcia-Carrillo Category: Standards Track D. Garcia-Carrillo
Expires: 23 August 2025 University of Oviedo ISSN: 2070-1721 University of Oviedo
19 February 2025 September 2025
EAP-based Authentication Service for CoAP Authentication Service Based on the Extensible Authentication Protocol
draft-ietf-ace-wg-coap-eap-15 (EAP) for Use with the Constrained Application Protocol (CoAP)
Abstract Abstract
This document specifies an authentication service that uses the This document specifies an authentication service that uses the
Extensible Authentication Protocol (EAP) transported employing Constrained Application Protocol (CoAP) as a transport method to
Constrained Application Protocol (CoAP) messages. As such, it carry the Extensible Authentication Protocol (EAP). As such, it
defines an EAP lower layer based on CoAP called CoAP-EAP. One of the defines an EAP lower layer based on CoAP called "CoAP-EAP". One of
main goals is to authenticate a CoAP-enabled IoT device (EAP peer) the main goals is to authenticate a CoAP-enabled Internet of Things
that intends to join a security domain managed by a Controller (EAP (IoT) device (EAP peer) that intends to join a security domain
authenticator). Secondly, it allows deriving key material to protect managed by a Controller (EAP authenticator). Secondly, it allows
CoAP messages exchanged between them based on Object Security for deriving key material to protect CoAP messages exchanged between them
Constrained RESTful Environments (OSCORE), enabling the establishment based on Object Security for Constrained RESTful Environments
of a security association between them. (OSCORE), enabling the establishment of a security association
between them.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 23 August 2025. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9820.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language
2. General Architecture . . . . . . . . . . . . . . . . . . . . 4 2. General Architecture
3. CoAP-EAP Operation . . . . . . . . . . . . . . . . . . . . . 5 3. CoAP-EAP Operation
3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Discovery
3.2. Flow of operation (OSCORE establishment) . . . . . . . . 6 3.2. Flow of Operation (OSCORE Establishment)
3.3. Reauthentication . . . . . . . . . . . . . . . . . . . . 9 3.3. Re-Authentication
3.4. Managing the State of the Service . . . . . . . . . . . . 10 3.4. Managing the State of the Service
3.5. Error handling . . . . . . . . . . . . . . . . . . . . . 11 3.5. Error Handling
3.5.1. EAP authentication failure . . . . . . . . . . . . . 11 3.5.1. EAP Authentication Failure
3.5.2. Non-responsive endpoint . . . . . . . . . . . . . . . 12 3.5.2. Non-Responsive Endpoint
3.5.3. Duplicated message with /.well-known/coap-eap . . . . 12 3.5.3. Duplicated Message with /.well-known/coap-eap
3.6. Proxy operation in CoAP-EAP . . . . . . . . . . . . . . . 13 3.6. Proxy Operation in CoAP-EAP
4. CoAP-EAP Media type format . . . . . . . . . . . . . . . . . 14 4. CoAP-EAP Media Type Format
5. CBOR Objects in CoAP-EAP . . . . . . . . . . . . . . . . . . 14 5. CBOR Objects in CoAP-EAP
6. Cipher suite negotiation and key derivation . . . . . . . . . 15 6. Cipher Suite Negotiation and Key Derivation
6.1. Cipher suite negotiation . . . . . . . . . . . . . . . . 15 6.1. Cipher Suite Negotiation
6.2. Deriving the OSCORE Security Context . . . . . . . . . . 17 6.2. Deriving the OSCORE Security Context
7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Discussion
7.1. CoAP as EAP lower layer . . . . . . . . . . . . . . . . . 18 7.1. CoAP as the EAP Lower Layer
7.2. Size of the EAP lower layer vs EAP method size . . . . . 20 7.2. Size of the EAP Lower Layer vs. EAP Method Size
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations
8.1. Use of EAP Methods . . . . . . . . . . . . . . . . . . . 20 8.1. Use of EAP Methods
8.2. Authorization . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Authorization
8.3. Allowing CoAP-EAP traffic to perform authentication . . . 21 8.3. Allowing CoAP-EAP Traffic to Perform Authentication
8.4. Freshness of the key material . . . . . . . . . . . . . . 21 8.4. Freshness of the Key Material
8.5. Channel Binding support . . . . . . . . . . . . . . . . . 22 8.5. Channel-Binding Support
8.6. Additional Security Considerations . . . . . . . . . . . 22 8.6. Additional Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 9. IANA Considerations
9.1. CoAP-EAP Cipher Suites . . . . . . . . . . . . . . . . . 23 9.1. CoAP-EAP Cipher Suites
9.2. CDDL in CoAP-EAP Information elements . . . . . . . . . . 24 9.2. CDDL in CoAP-EAP Information Elements
9.3. The Well-Known URI Registry . . . . . . . . . . . . . . . 25 9.3. The Well-Known URIs Registry
9.4. The EAP lower layer identifier registry . . . . . . . . . 26 9.4. The EAP Lower Layers Registry
9.5. Media Types Registry . . . . . . . . . . . . . . . . . . 26 9.5. Media Types Registry
9.6. CoAP Content-Formats Registry . . . . . . . . . . . . . . 27 9.6. CoAP Content-Formats Registry
9.7. Resource Type (rt=) Link Target Attribute Values 9.7. Resource Type (rt=) Link Target Attribute Values Registry
Registry . . . . . . . . . . . . . . . . . . . . . . . . 27 9.8. Expert Review Instructions
9.8. Expert Review Instructions . . . . . . . . . . . . . . . 27 10. References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Normative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 28 10.2. Informative References
10.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Flow of Operation (DTLS Establishment)
Appendix A. Flow of operation (DTLS establishment) . . . . . . . 32 A.1. Deriving DTLS_PSK and Identity
A.1. Deriving DTLS PSK and identity . . . . . . . . . . . . . 34 Appendix B. Using CoAP-EAP for Distributing Key Material for IoT
Appendix B. Using CoAP-EAP for distributing key material for IoT Networks
networks . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Example Use Case Scenarios
Appendix C. Examples of Use Case Scenario . . . . . . . . . . . 35 C.1. Example 1: CoAP-EAP Using ACE
C.1. Example 1: CoAP-EAP in ACE . . . . . . . . . . . . . . . 36 C.2. Example 2: Multiple Domains with AAA Infrastructures
C.2. Example 2: Multi-domain with AAA infrastructures . . . . 37 C.3. Example 3: Single Domain with a AAA Infrastructure
C.3. Example 3: Single domain with AAA infrastructure . . . . 38 C.4. Example 4: Single Domain Without a AAA Infrastructure
C.4. Example 4: Single domain without AAA infrastructure . . . 38 C.5. Other Use Cases
C.5. Other use cases . . . . . . . . . . . . . . . . . . . . . 38 C.5.1. CoAP-EAP for Network Access Authentication
C.5.1. CoAP-EAP for network access authentication . . . . . 38 C.5.2. CoAP-EAP for Service Authentication
C.5.2. CoAP-EAP for service authentication . . . . . . . . . 40 Acknowledgments
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction 1. Introduction
This document specifies an authentication service (application) that This document specifies an authentication service (application) that
uses the Extensible Authentication Protocol (EAP) [RFC3748] and is uses the Extensible Authentication Protocol (EAP) [RFC3748] and is
built on top of the Constrained Application Protocol (CoAP)[RFC7252] built on top of the Constrained Application Protocol (CoAP)
called CoAP-EAP. CoAP-EAP is an application that allows [RFC7252]; it is called "CoAP-EAP". CoAP-EAP is an application that
authenticating two CoAP endpoints by using EAP and establishing an allows authenticating two CoAP endpoints by using EAP and
Object Security for Constrained RESTful Environments (OSCORE) establishing an Object Security for Constrained RESTful Environments
security association between them. More specifically, this document (OSCORE) security association between them. More specifically, this
specifies how CoAP can be used as a constrained, link-layer document specifies how CoAP can be used as a constrained, link-layer-
independent, reliable EAP lower layer [RFC3748] to transport EAP independent, reliable EAP lower layer [RFC3748] to transport EAP
messages between a CoAP server (acting as EAP peer) and a CoAP client messages between a CoAP server (acting as an EAP peer) and a CoAP
(acting as EAP authenticator) using CoAP messages. The CoAP client client (acting as an EAP authenticator) using CoAP messages. The
has the option of contacting a backend AAA infrastructure to complete CoAP client has the option of contacting a backend Authentication,
the EAP negotiation, as described in the EAP specification [RFC3748]. Authorization, and Accounting (AAA) infrastructure to complete the
EAP negotiation, as described in the EAP specification [RFC3748].
The EAP methods that can be transported with CoAP-EAP MUST export In the case of this specification, the EAP methods that can be
cryptographic material [RFC5247] for this specification. Examples of transported with CoAP-EAP MUST export cryptographic material
such methods are EAP-GPSK [RFC5433], EAP-SIM [RFC4186], EAP-AKA' [RFC5247]. Examples of such methods are the EAP Generalized Pre-
[RFC5448], EAP-TLS 1.3 [RFC9190], EAP-EDHOC [I-D.ietf-emu-eap-edhoc], Shared Key (EAP-GPSK) [RFC5433], the EAP Method for Global System for
etc. In general, any EAP method designed in EMU Working Group that Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)
exports the Master Session Key (MSK) can be used with CoAP-EAP. The [RFC4186], the EAP Method for 3rd Generation Authentication and Key
Master Session Key (MSK) is used as the basis for further Agreement (EAP-AKA') [RFC5448], EAP-TLS 1.3 [RFC9190], EAP with
cryptographic derivations. This way, CoAP messages are protected Ephemeral Diffie-Hellman over CBOR Object Signing and Encryption
after authentication. After CoAP-EAP's operation, an OSCORE security (EAP-EDHOC) [EAP-EDHOC], etc. ("CBOR" stands for "Concise Binary
association is established between the endpoints of the service. Object Representation".) In general, any EAP method designed in the
Using the keying material from the authentication, other security EAP Method Update (EMU) Working Group that exports the Master Session
associations could be generated. Appendix A shows how to establish a Key (MSK) can be used with CoAP-EAP. The MSK is used as the basis
(D)TLS security association using the keying material from the EAP for further cryptographic derivations. This way, CoAP messages are
authentication. protected after authentication. After the CoAP-EAP operation, an
OSCORE security association is established between the endpoints of
the service. Using the keying material from the authentication,
other security associations could be generated. Appendix A shows how
to establish a (D)TLS security association using the keying material
from the EAP authentication.
One of the main applications of CoAP-EAP is Internet of Things (IoT) One of the main applications of CoAP-EAP involves Internet of Things
networks, where we can find very constrained links (e.g., limited (IoT) networks, where we can find very constrained links (e.g.,
bandwidth) and devices with limited capabilities. In these IoT limited bandwidth) and devices with limited capabilities. In these
scenarios, we identify the IoT device as the entity that wants to be IoT scenarios, we identify the IoT device as the entity that wants to
authenticated by using EAP to join a domain that is managed by a be authenticated by using EAP to join a domain that is managed by a
Controller. The IoT device is in these cases the EAP peer and the Controller. In these cases, the IoT device is the EAP peer and the
Controller, the entity steering the authentication, the EAP Controller is the entity steering the authentication (i.e., the EAP
authenticator. From now on, the IoT device is referred to as the EAP authenticator); from now on, the IoT device will be referred to as
peer and the Controller as the EAP authenticator. In these cases, the EAP peer and the Controller will be referred to as the EAP
EAP methods with fewer exchanges, shorter messages, and cryptographic authenticator. In these cases, EAP methods with fewer exchanges,
algorithms suitable for constrained devices are preferable. The shorter messages, and cryptographic algorithms suitable for
benefits of the EAP framework in IoT are highlighted in constrained devices are preferable. The benefits of the EAP
[EAP-framework-IoT]. framework in IoT networks are highlighted in [EAP-Framework-IoT].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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 Extensible Authentication Protocol (EAP) peer this architecture, the EAP peer will act as a CoAP server for this
will act as a CoAP server for this service, and the domain EAP service and the domain EAP authenticator will act as a CoAP client.
authenticator as a CoAP client. The rationale behind this decision The rationale behind this decision is that EAP Requests will always
is that EAP requests direction is always from the EAP server to the travel from the EAP server to the EAP peer. Accordingly, EAP
EAP peer. Accordingly, EAP responses direction is always from the Responses will always travel from the EAP peer to the EAP server.
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. For this is an EAP state machine that can run any EAP method. In the case of
specification, the EAP method MUST support key derivation and export, this specification, the EAP method MUST support key derivation and
as specified in [RFC5247], a Master Session Key (MSK) of at least 64 export as specified in [RFC5247]: an MSK of at least 64 octets and an
octets, and an Extended Master Session Key (EMSK) of at least 64 Extended Master Session Key (EMSK) of at least 64 octets. CoAP-EAP
octets. CoAP-EAP also relies on CoAP reliability mechanisms in CoAP also relies on CoAP reliability mechanisms to transport EAP: CoAP
to transport EAP: CoAP over UDP with Confirmable messages ([RFC7252]) over UDP with Confirmable messages [RFC7252] or CoAP over TCP, TLS,
or CoAP over TCP, TLS, or WebSockets [RFC8323]. or WebSockets [RFC8323].
+--------+ +--------------+ +----------+ +--------+ +--------------+ +----------+
| EAP | | EAP | | AAA/ | | EAP | | EAP | | AAA/ |
| peer |<------>| authenticator|<----------->|EAP Server| | peer |<------>| authenticator|<----------->|EAP server|
+--------+ CoAP +--------------+ AAA +----------+ +--------+ CoAP +--------------+ AAA +----------+
(Optional) (optional)
<----(SCOPE OF THIS DOCUMENT)----> <---- SCOPE OF THIS DOCUMENT ---->
Figure 1: CoAP-EAP Architecture Figure 1: CoAP-EAP Architecture
+-------------------------------+ +-----------------------------------+
| EAP State Machine | | EAP State Machine |
+-------------------------------+ +-----------------------------------+
| Application(CoAP-EAP) | <-- This Document | Application (CoAP-EAP) | <-- This Document
+-------------------------------+ +-----------------------------------+
| Request/Responses/Signaling | RFC 7252 / RFC 8323 | Requests / Responses / Signaling | RFC 7252 / RFC 8323
+-------------------------------+ +-----------------------------------+
| Message / Message Framing | RFC 7252 / RFC 8323 | Message / Message Framing | RFC 7252 / RFC 8323
+-------------------------------+ +-----------------------------------+
|Unreliable / Reliable Transport| RFC 7252 / RFC 8323 | Unreliable / Reliable Transport | RFC 7252 / RFC 8323
+-------------------------------+ +-----------------------------------+
Figure 2: CoAP-EAP Stack Figure 2: CoAP-EAP Stack
3. CoAP-EAP Operation 3. CoAP-EAP Operation
Because CoAP-EAP uses reliable delivery defined in CoAP ([RFC7252], Because CoAP-EAP uses reliable delivery as defined in CoAP [RFC7252]
[RFC8323]), EAP retransmission time is set to infinite as mentioned [RFC8323], EAP retransmission time is set to an infinite value, as
in [RFC3748]. To keep the ordering guarantee, CoAP-EAP uses mentioned in [RFC3748]. To maintain ordering guarantees, CoAP-EAP
Hypermedia as the Engine of Application State (HATEOAS). Each step uses Hypermedia as the Engine of Application State (HATEOAS). Each
during the EAP authentication accesses a new resource in the CoAP step during the EAP authentication accesses a new resource in the
server (EAP peer). The previous resource is removed once the new CoAP server (EAP peer). The previous resource is removed once the
resource is created, indicating the resource that will process the new resource is created, indicating the resource that will process
next step of the EAP authentication. the next step of the EAP authentication.
One of the benefits of using EAP is that we can choose from a large One of the benefits of using EAP is that we can choose from a large
variety of authentication methods. variety of authentication methods.
In CoAP-EAP, the EAP peer will only have one authentication session In CoAP-EAP, the EAP peer will only have one authentication session
with a specific EAP authenticator, and it will not process any other with a specific EAP authenticator, and it will not process any other
EAP authentication in parallel (with the same EAP authenticator). EAP authentication in parallel (with the same EAP authenticator).
That is, a single ongoing EAP authentication is permitted for the That is, a single ongoing EAP authentication is permitted for the
same EAP peer and the same EAP authenticator. It may be worth noting same EAP peer and the same EAP authenticator. It may be worth noting
that the EAP authenticator may have parallel EAP sessions with that the EAP authenticator may have parallel EAP sessions with
multiple EAP peers. multiple EAP peers.
To access the authentication service, this document defines the well- To access the authentication service, this document defines the well-
known URI "coap-eap" (to be assigned by IANA). The /.well-known/ known URI "coap-eap" (see Section 9.3). The /.well-known/coap-eap
coap-eap URI is used with "coap", "coap+tcp" or "coap+ws". URI is used with "coap", "coap+tcp", or "coap+ws".
3.1. Discovery 3.1. Discovery
Before the CoAP-EAP exchange takes place, the EAP peer needs to Before the CoAP-EAP exchange takes place, the EAP peer needs to
discover the EAP authenticator or the entity that will enable the discover the EAP authenticator or the entity that will enable the
CoAP-EAP exchange (e.g., an intermediary proxy). The discovery CoAP-EAP exchange (i.e., an intermediary). The discovery process is
process is out of the scope of this document. outside the scope of this document.
The CoAP-EAP application can be accessed through the URI "coap-eap" The CoAP-EAP application can be accessed through the URI "coap-eap"
for the trigger message (see Section 3.2, Step 0). The CoAP-EAP for the trigger message (see Section 3.2, Step 0). The CoAP-EAP
service can be discovered by asking directly about the services service can be discovered by asking directly about the services
offered. This information can also be available in the resource offered. This information can also be available in the resource
directory [RFC9176]. directory [RFC9176].
Implementation Notes: There are different methods to discover the Implementation notes: There are different methods for discovering the
IPv6 address of the EAP authenticator or intermediary entity. For IPv6 address of the EAP authenticator or intermediary entity. For
example, on a 6LoWPAN network, the Border Router will typically act example, in a 6LoWPAN network, the Border Router will typically act
as the EAP authenticator hence, after receiving the Router as the EAP authenticator. Hence, after receiving the Router
Advertisement (RA) messages from the Border Router, the EAP peer may Advertisement (RA) messages from the Border Router, the EAP peer may
engage on the CoAP-EAP exchange. engage in the CoAP-EAP exchange.
3.2. Flow of operation (OSCORE establishment) 3.2. Flow of Operation (OSCORE Establishment)
Figure 3 shows the general flow of operation for CoAP-EAP to Figure 3 shows the general flow of operation for CoAP-EAP to
authenticate using EAP and establish an OSCORE security context. The authenticate using EAP and establish an OSCORE Security Context. The
flow does not show a specific EAP method. Instead, the chosen EAP flow does not show a specific EAP method. Instead, the chosen EAP
method is represented by using a generic name (EAP-X). The flow method is represented by using a generic name (EAP-X). The flow
assumes that the EAP peer knows the EAP authenticator implements the assumes that the EAP peer knows the EAP authenticator implements the
CoAP-EAP service. A CoAP-EAP message has a media type application/ CoAP-EAP service. A CoAP-EAP message has the media type
coap-eap, See Section 9.5. "application/coap-eap". See Section 9.5.
The steps of the operation are as follows: The steps for this flow of operation are as follows:
* Step 0. The EAP peer MUST start the CoAP-EAP process by sending a * Step 0. The EAP peer MUST start the CoAP-EAP process by sending a
"POST /.well-known/coap-eap" request (trigger message). This "POST /.well-known/coap-eap" request (trigger message). This
message carries the 'No-Response' [RFC7967] CoAP option to avoid message carries the 'No-Response' CoAP option [RFC7967] to avoid
waiting for a response that is not needed. This is the only waiting for a response that is not needed. This is the only
message where the EAP authenticator acts as a CoAP server and the 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 EAP peer acts as a CoAP client. The message also includes a URI
payload of the message to indicate the resource where the EAP in the payload of the message to indicate the resource where the
authenticator MUST send the next message. The name of the EAP authenticator MUST send the next message. The name of the
resource is selected by the CoAP server. resource is selected by the CoAP server.
Implementation notes: When generating the URI for a resource of a Implementation notes: When generating the URI for a resource during a
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 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' which is an incrementing unique number for every new EAP * "counter" is an incrementing unique number for every new EAP
request. Request.
So, in Figure 3 for example, the URI for the first resource would be So, per Figure 3, the URI for the first resource would be "/a/eap/1".
“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/ this message contains the first EAP message (EAP-Request/Identity,
Identity), the Recipient ID of the EAP authenticator (RID-C) for or EAP-Req/Id) and the Recipient ID of the EAP authenticator (RID-
OSCORE, and MAY contain a CBOR array with a list of proposed C) for OSCORE, and MAY contain a CBOR array with a list of
cipher suites (CS-C) for OSCORE. If the cipher suite list is not proposed cipher suites (CS-C) for OSCORE. If the cipher suite
included, the default cipher suite for OSCORE is used. The list is not included, the default cipher suite for OSCORE is used.
details of the cipher suite negotiation are discussed in The details of the cipher suite negotiation are discussed in
Section 6.1. Section 6.1.
* Step 2. The EAP peer processes the POST message sending the EAP * Step 2. The EAP peer processes the POST message sending the EAP
request (EAP-Req/Id) to the EAP peer state machine, which returns Request (EAP-Req/Id) to the EAP peer state machine, which returns
an EAP response (EAP Resp/Id). Then, assigns a new resource to an EAP Response (EAP-Response/Identity, or EAP-Resp/Id). Then,
the ongoing authentication process (e.g., '/a/eap/2'), and deletes the CoAP-EAP application assigns a new resource to the ongoing
the previous one ('/a/eap/1'). Finally, sends a '2.01 Created' authentication process (e.g., "/a/eap/2") and deletes the previous
response with the new resource identifier in the Location-Path one ("/a/eap/1"). Finally, the CoAP-EAP application sends a '2.01
(and/or Location-Query) options for the next step. The EAP Created' response with the new resource identifier in the
response, the Recipient ID of the EAP peer (RID-I) and the Location-Path (and/or Location-Query) Options for the next step.
selected cipher suite for OSCORE (CS-I) are included in the The EAP Response, the Recipient ID of the EAP peer (RID-I), and
payload. In this step, the EAP peer may create an OSCORE security the selected cipher suite for OSCORE (CS-I) are included in the
context (see Section 6.2). The required Master Session Key (MSK) payload. In this step, the EAP peer may create an OSCORE Security
will be available once the EAP authentication is successful in Context (see Section 6.2). The required MSK will be available
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 response to carry the EAP response in the The EAP peer will use a CoAP response to carry the EAP Response in
payload. EAP requests and responses are represented in Figure 3 the payload. EAP Requests and responses are represented in
using the nomenclature (EAP-X-Req and EAP-X-Resp, respectively). Figure 3 using the nomenclature "EAP-X-Req" and "EAP-X-Resp",
When a POST message arrives (e.g., '/a/eap/1') carrying an EAP respectively. When a POST message arrives (e.g., "/a/eap/1")
request message, if processed correctly by the EAP peer state carrying an EAP Request message, if processed correctly by the EAP
machine, returns an EAP Response. Along with each EAP Response, a peer state machine, it returns an EAP Response. Along with each
new resource is created (e.g., '/a/eap/3') for processing the next EAP Response, a new resource is created (e.g., "/a/eap/3") for
EAP request and the ongoing resource (e.g., '/a/eap/2') is erased. processing the next EAP Request and the ongoing resource (e.g.,
This way, ordering guarantee is achieved. Finally, an EAP "/a/eap/2") is erased. This way, ordering guarantees are
response is sent in the payload of a CoAP response that will also achieved. Finally, an EAP Response is sent in the payload of a
indicate the new resource in the Location-Path (and/or Location- CoAP response that will also indicate the new resource in the
Query) Options. In case there is an error processing a legitimate Location-Path (and/or Location-Query) Options. If an error occurs
message, the server will return a (4.00 Bad Request). There is a while processing a legitimate message, the server will return a
discussion about error handling 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 Master Session Key (MSK) exported by the authenticator obtains the MSK exported by the EAP method, an EAP
EAP method, an EAP Success message, and some authorization Success message, and some authorization information [RFC5247]
information (e.g., session lifetime) [RFC5247]. The EAP (e.g., Session-Lifetime). The EAP authenticator creates the
authenticator creates the OSCORE security context using the MSK OSCORE Security Context using the MSK and Recipient ID of both
and Recipient ID of both entities exchanged in Steps 1 and 2. The entities exchanged in Steps 1 and 2. The establishment of the
establishment of the OSCORE Security Context is defined in OSCORE Security Context is defined in Section 6.2. Then, the EAP
Section 6.2. Then, the EAP authenticator sends the POST message authenticator sends the POST message protected with OSCORE for key
protected with OSCORE for key confirmation including the EAP confirmation, including the EAP Success. The EAP authenticator
Success. The EAP authenticator MAY also send a Session Lifetime, MAY also send a Session-Lifetime, in seconds, which is represented
in seconds, which is represented with an unsigned integer in a by an unsigned integer in a CBOR Object (see Section 5). If this
CBOR object (see Section 5). If this Session Lifetime is not Session-Lifetime is not sent, the EAP peer assumes a default value
sent, the EAP peer assumes a default value of 8 hours, as of 8 hours, as RECOMMENDED in [RFC5247]. The reception of the
RECOMMENDED in [RFC5247]. The reception of the OSCORE-protected OSCORE-protected POST message is considered by the EAP peer as an
POST message is considered by the EAP peer as an alternate alternate indication of success [RFC3748]. The EAP peer state
indication of success ([RFC3748]). The EAP peer state machine in machine in the EAP peer interprets the alternate indication of
the EAP peer interprets the alternate indication of success success (similarly to the arrival of an EAP Success) and returns
(similarly to the arrival of an EAP Success) and returns the MSK, the MSK, which is used to create the OSCORE Security Context in
which is used to create the OSCORE security context in the EAP the EAP peer to process the protected POST message received from
peer to process the protected POST message received from the EAP the EAP authenticator.
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 in Step 7 is successful, then the EAP peer OSCORE-protected POST (Step 7) are successful, then the EAP peer
answers with an OSCORE-protected '2.04 Changed'. From this point answers with an OSCORE-protected '2.04 Changed'. From this point
on, communication with the last resource (e.g., '/a/eap/(n)') MUST on, communication with the last resource (e.g., "/a/eap/(n)") MUST
be protected with OSCORE. If allowed by application policy, the be protected with OSCORE. If allowed by application policy, the
same OSCORE security context MAY be used to protect communication same OSCORE Security Context MAY be used to protect communication
to other resources between the same endpoints. to other resources between the same endpoints.
EAP peer EAP authenticator EAP peer EAP authenticator
------------- ------------ ------------- ------------
| POST /.well-known/coap-eap | | POST /.well-known/coap-eap |
0)| No-Response | 0)| No-Response |
| Payload("/a/eap/1") | | Payload("/a/eap/1") |
|---------------------------------------->| |---------------------------------------->|
| POST /a/eap/1 | | POST /a/eap/1 |
| Payload(EAP Req/Id||CS-C||RID-C) | | Payload(EAP-Req/Id||CS-C||RID-C) |
1)|<----------------------------------------| 1)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/2] | | 2.01 Created Location-Path [/a/eap/2] |
| Payload(EAP Resp/Id||CS-I||RID-I) | | Payload(EAP-Resp/Id||CS-I||RID-I) |
2)|---------------------------------------->| 2)|---------------------------------------->|
| POST /a/eap/2 | | POST /a/eap/2 |
| Payload(EAP-X Req) | | Payload(EAP-X-Req) |
3)|<----------------------------------------| 3)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/3] | | 2.01 Created Location-Path [/a/eap/3] |
| Payload(EAP-X Resp) | | Payload(EAP-X-Resp) |
4)|---------------------------------------->| 4)|---------------------------------------->|
.... ....
| POST /a/eap/(n-1) | | POST /a/eap/(n-1) |
| Payload(EAP-X Req) | | Payload(EAP-X-Req) |
5)|<----------------------------------------| 5)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/(n)] | | 2.01 Created Location-Path [/a/eap/(n)] |
| Payload (EAP-X Resp) | | Payload(EAP-X-Resp) |
6)|---------------------------------------->| 6)|---------------------------------------->|
| | MSK | | MSK
| POST /a/eap/(n) | | | POST /a/eap/(n) | |
| OSCORE | | | OSCORE | v
| Payload(EAP Success||*Session-Lifetime)| OSCORE | Payload(EAP Success||*Session-Lifetime)| OSCORE
MSK 7)|<----------------------------------------| CTX MSK 7)|<----------------------------------------| CTX
| | | | | |
| | 2.04 Changed | v | 2.04 Changed |
OSCORE | OSCORE | OSCORE | OSCORE |
CTX 8)|---------------------------------------->| CTX 8)|---------------------------------------->|
*Session-Lifetime is optional *Session-Lifetime is optional
Figure 3: CoAP-EAP flow of operation with OSCORE Figure 3: CoAP-EAP Flow of Operation with OSCORE
3.3. Reauthentication 3.3. Re-Authentication
When the CoAP-EAP state is close to expiring, the EAP peer may want When the CoAP-EAP state is close to expiring, the EAP peer may want
to start a new authentication process (re-authentication) to renew to start a new authentication process (re-authentication) to renew
the state. The main goal is to obtain new and fresh keying material the state. The main goal is to obtain new and fresh keying material
(MSK/EMSK) that, in turn, allows deriving a new OSCORE security (MSK/EMSK) that, in turn, allows deriving a new OSCORE Security
context, increasing the protection against key leakage. The keying Context, increasing the protection against key leakage. The keying
material MUST be renewed before the expiration of the Session- material MUST be renewed before the expiration of the Session-
Lifetime. By default, the EAP Key Management Framework establishes a Lifetime. By default, the EAP key management framework [RFC5247]
default value of 8 hours to refresh the keying material. Certain EAP establishes a default value of 8 hours to refresh the keying
methods such as EAP-NOOB [RFC9140] or EAP-AKA' [RFC5448] provide fast material. Certain EAP methods such as Nimble Out-of-Band
reconnect for quicker re-authentication. The EAP re-authentication Authentication for EAP (EAP-NOOB) [RFC9140] or EAP-AKA' [RFC5448]
protocol (ERP) [RFC6696] MAY also be used to avoid the repetition of provide fast reconnect for quicker re-authentication. The EAP Re-
the entire EAP exchange. 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 The re-authentication message flow will be the same as that shown in
in Figure 3. Nevertheless, two different CoAP-EAP states will be Figure 3. Nevertheless, two different CoAP-EAP states will be active
active during the re-authentication: the current CoAP-EAP state and during the re-authentication: the current CoAP-EAP state and the new
the new CoAP-EAP state, which will be created once the re- CoAP-EAP state, which will be created once the re-authentication has
authentication has finished successfully. Once the re-authentication finished successfully. Once the re-authentication is completed
is completed successfully, the current CoAP-EAP state is deleted and successfully, the current CoAP-EAP state is deleted and replaced by
replaced by the new CoAP-EAP state. If, for any reason, the re- the new CoAP-EAP state. If for any reason the re-authentication
authentication fails, the current CoAP-EAP state will be available fails, the current CoAP-EAP state will be available until it expires,
until it expires, or it is renewed in another try of re- or it will be renewed during a subsequent re-authentication attempt.
authentication.
If the re-authentication fails, it is up to the EAP peer to decide 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 when to start a new re-authentication before the current EAP state
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 is exported when the EAP authentication is successful. * The MSK, which is exported when the EAP authentication is
CoAP-EAP can access the different variables by the EAP state successful. CoAP-EAP can access the different variables via the
machine (i.e., [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
mentioned in Section 3.3. mentioned in Section 3.3.
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. This 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
------------- ------------- ------------- -------------
| | | |
| DELETE /a/eap/(n) | | DELETE /a/eap/(n) |
| OSCORE | | OSCORE |
|<--------------------------------------| |<--------------------------------------|
| | | |
| 2.02 Deleted | | 2.02 Deleted |
| OSCORE | | OSCORE |
|-------------------------------------->| |-------------------------------------->|
Figure 4: Deleting state Figure 4: Deleting State
3.5. Error handling 3.5. Error Handling
This section elaborates on how different errors are handled. From This section elaborates on how different errors are handled: EAP
EAP authentication failure, a non-responsive endpoint lost messages, authentication failure (Section 3.5.1), a non-responsive endpoint
or an initial POST message arriving out of place. (Section 3.5.2), and duplicated messages (Section 3.5.3).
3.5.1. EAP authentication failure 3.5.1. EAP Authentication Failure
The EAP authentication may fail in different situations (e.g., wrong The EAP authentication may fail in different situations (e.g., wrong
credentials). The result is that the EAP authenticator will send an credentials). The result is that the EAP authenticator will send an
EAP Failure message because of the EAP authentication (Step 7 in EAP Failure message because of a failed EAP authentication (Step 7 in
Figure 3). In this case, the EAP peer MUST send a response '4.01 Figure 3). In this case, the EAP peer MUST send a response '4.01
Unauthorized' in Step 8. Therefore, Step 7 and Step 8 are not Unauthorized' in Step 8. Therefore, Steps 7 and 8 are not protected
protected in this case because no Master Session Key (MSK) is in this case because no MSK is exported and the OSCORE Security
exported and the OSCORE security context is not yet generated. Context is not yet generated.
If the EAP authentication fails during the re-authentication and the If the EAP authentication fails during the re-authentication and the
EAP authenticator sends an EAP failure, the current CoAP-EAP state EAP authenticator sends an EAP Failure, the current CoAP-EAP state
will be still usable until it expires. will still be usable until it expires.
3.5.2. Non-responsive endpoint 3.5.2. Non-Responsive Endpoint
If, for any reason, one of the entities becomes non-responsive, the If for any reason one of the entities becomes non-responsive, the
CoAP-EAP state SHOULD be removed after a stipulated amount of time. CoAP-EAP state SHOULD be removed after a stipulated amount of time.
The amount of time can be adjusted according to the policies The amount of time can be adjusted according to the policies
established by the application or use case where CoAP-EAP is used. established by the application or use case where CoAP-EAP is used.
As a default value, the CoAP EXCHANGE_LIFETIME parameter, as defined As a default value, the CoAP EXCHANGE_LIFETIME parameter, as defined
in CoAP[RFC7252] will be used. in CoAP [RFC7252], will be used.
The removal of the CoAP-EAP state in the EAP authenticator assumes The removal of the CoAP-EAP state in the EAP authenticator assumes
that the EAP peer will need to authenticate again. that the EAP peer will need to authenticate again.
According to CoAP, EXCHANGE_LIFETIME considers the time it takes According to CoAP, EXCHANGE_LIFETIME considers the time it takes
until a client stops expecting a response to a request. A timer is until a client stops expecting a response to a request. A timer is
reset every time a message is sent. By default, CoAP-EAP adopts the reset every time a message is sent. By default, CoAP-EAP adopts the
value of EXCHANGE_LIFETIME as a timer in the EAP peer and value of EXCHANGE_LIFETIME as a timer in the EAP peer and
Authenticator to remove the CoAP-EAP state if the authentication authenticator to remove the CoAP-EAP state if the authentication
process has not progressed in that time, in consequence, it has not process has not progressed to completion during that time.
been completed.
The EAP peer will remove the CoAP-EAP state either if the The EAP peer will remove the CoAP-EAP state if either the
EXCHANGE_LIFETIME is triggered, or the EAP peer state machine returns EXCHANGE_LIFETIME is triggered or the EAP peer state machine returns
an eapFail. an eapFail.
The EAP authenticator will remove the CoAP-EAP state either if the The EAP authenticator will remove the CoAP-EAP state if either the
EXCHANGE_LIFETIME is triggered, or, when the EAP authenticator is EXCHANGE_LIFETIME is triggered or, when the EAP authenticator is
acting in pass-through mode (i.e., the EAP authentication is operating in pass-through mode (i.e., the EAP authentication is
performed against a AAA server), the EAP authenticator state machine performed against a AAA server), the EAP authenticator state machine
returns an aaaTimemout. returns "aaaTimeout" [RFC4137].
3.5.3. Duplicated message with /.well-known/coap-eap 3.5.3. Duplicated Message with /.well-known/coap-eap
The reception of the trigger message in Step 0 containing the URI The reception of the trigger message (Step 0 in Figure 3) containing
/coap-eap needs some additional considerations, as the resource is the URI /coap-eap needs some additional considerations, as the
always available in the EAP authenticator. resource is always available in the EAP authenticator.
If a trigger message (Step 0) arrives at the EAP authenticator during If a trigger message arrives at the EAP authenticator during an
an ongoing authentication with the same EAP peer, the EAP ongoing authentication with the same EAP peer, the EAP authenticator
authenticator MUST silently discard this trigger message. MUST silently discard this trigger message.
If an old "POST /.well-known/coap-eap" (Step 0) arrives at the EAP If an old "POST /.well-known/coap-eap" (Step 0 in Figure 5) arrives
authenticator and there is no authentication ongoing, the EAP at the EAP authenticator and there is no authentication ongoing, the
authenticator may understand that a new authentication process is EAP authenticator may understand that a new authentication process is
requested. Consequently, the EAP authenticator will start a new EAP requested. Consequently, the EAP authenticator will start a new EAP
authentication. However, if the EAP peer did not start any authentication. However, if the EAP peer did not start any
authentication and therefore, it did not select any resource for the authentication, it will send a '4.04 Not Found' in the response
EAP authentication. Thus, the EAP peer sends a '4.04 Not found' in (Figure 5).
the response (Figure 5).
EAP peer EAP authenticator EAP peer EAP authenticator
---------- ---------- ---------- ----------
| *POST /.well-known/coap-eap | | *POST /.well-known/coap-eap |
0) | No-Response | 0)| No-Response |
| Payload("/a/eap/1") | | Payload("/a/eap/1") |
| ------------------------->| | ------------------------->|
| POST /a/eap/1 | | POST /a/eap/1 |
| Payload (EAP Req/Id||CS-C) | | Payload(EAP-Req/Id||CS-C) |
1) |<----------------------------------------| 1)|<----------------------------------------|
| | | |
| 4.04 Not found | | 4.04 Not Found |
|---------------------------------------->| |---------------------------------------->|
*Old *Old
Figure 5: /.well-known/coap-eap with no ongoing authentication Figure 5: /.well-known/coap-eap with No Ongoing Authentication
from the EAP authenticator from the EAP Authenticator
3.6. Proxy operation in CoAP-EAP 3.6. Proxy Operation in CoAP-EAP
The CoAP-EAP operation is intended to be compatible with the use of The CoAP-EAP operation is intended to be compatible with the use of
intermediary entities between the EAP peer and the EAP authenticator intermediary entities between the EAP peer and the EAP authenticator
when direct communication is not possible. In this context, CoAP when direct communication is not possible. In this context, CoAP
proxies can be used as enablers of the CoAP-EAP exchange. proxies can be used as enablers of the CoAP-EAP exchange.
This specification is limited to using standard CoAP [RFC7252] as This specification is limited to using standard CoAP [RFC7252] as
well as standardized CoAP options [RFC8613]. It does not specify any well as standardized CoAP options [RFC8613]. It does not specify any
addition in the form of CoAP options. This is expected to ease the addition in the form of CoAP options. This is expected to ease the
integration of CoAP intermediaries in the CoAP-EAP exchange. integration of CoAP intermediaries in the CoAP-EAP exchange.
When using proxies in the CoAP-EAP, it should be considered that the When using proxies in the CoAP-EAP exchange, it should be considered
exchange contains a role-reversal process at the beginning of the that the exchange contains a role-reversal process at the beginning
exchange. In the first message, the EAP peer acts as a CoAP client of the exchange. In the first message, the EAP peer acts as a CoAP
and the EAP authenticator as the CoAP server. After that, in the client and the EAP authenticator acts as the CoAP server. In the
remaining exchanges the roles are reversed, being the EAP peer, the remaining exchanges, the roles are reversed (i.e., the EAP peer acts
CoAP server, and the EAP authenticator, the CoAP client. When using as the CoAP server, and the EAP authenticator acts as the CoAP
a proxy in the exchange, for message 0, the proxy will act as client). When using a proxy in the exchange, for message 0 it will
forward, and as reverse for the rest. Additionally, in the first act as a forward proxy, and as a reverse proxy for the rest.
exchange, the EAP peer, as a CoAP client, sends the URI for the next Additionally, in the first exchange, the EAP peer, as a CoAP client,
CoAP message in the payload of a request. This is not the typical sends the URI for the next CoAP message in the payload of a request.
behavior, as URIs referring to new services/resources appear in This is not the typical behavior, as URIs referring to new services/
Location-Path and/or Location-Query Options in CoAP responses. resources appear in Location-Path and/or Location-Query Options in
Hence, the proxy will have to treat the payload of message 0, as if CoAP responses. Hence, the proxy will have to treat the payload of
it were a Location-Path Option of a CoAP response. Message 0 as if it were a Location-Path Option of a CoAP response.
4. CoAP-EAP Media type format 4. CoAP-EAP Media Type Format
In the CoAP-EAP exchange, the following format will be used. This is In the CoAP-EAP exchange, the format specified by the "application/
the format is specified by application/coap-eap media type, see coap-eap" media type will be used. See Section 9.5.
Section 9.5.
In CoAP-EAP there are two different elements that can be sent over In CoAP-EAP, there are two different elements that can be sent over
the payload. The first one is a relative URI. This payload will be the payload. The first one is a relative URI. This payload will be
present for the first message (0) in Figure 3. present for the first message (0) in Figure 3.
In all the other cases, an EAP message will be followed by the CBOR In all the other cases, an EAP message will be followed by the CBOR
Object specified in Section 5. A visual example of the second case Object specified in Section 5. A visual example of the second case
can be found in Figure 7. can be found in Figure 7 (Section 6.1).
5. CBOR Objects in CoAP-EAP 5. CBOR Objects in CoAP-EAP
In the CoAP-EAP exchange, there is information that needs to be In the CoAP-EAP exchange, information needs to be exchanged between
exchanged between the two entities. Examples of this information are the two entities -- for example, the cipher suites that need to be
the cipher suites that need to be negotiated or authorization negotiated, or authorization information (Session-Lifetime). There
information (Session-lifetime). There may also be a need to extend may also be a need to extend the information that has to be exchanged
the information that has to be exchanged in the future. This section in the future. This section specifies the CBOR data structure
specifies the CBOR [RFC8949] data structure to exchange information [RFC8949] to exchange information between the EAP peer and the EAP
between the EAP peer and the EAP authenticator in the CoAP payload. authenticator in the CoAP payload.
Figure 6 shows the specification of the CBOR Object to exchange Figure 6 shows the specification of the CBOR Object to exchange
information in CoAP-EAP information in CoAP-EAP.
CoAP-EAP_Info = { CoAP-EAP_Info = {
? 1 : [+ int], ; Cipher Suite (CS-C or CS-I) ? 1 : [+ int], ; Cipher Suite (CS-C or CS-I)
? 2 : bstr, ; RID-C ? 2 : bstr, ; RID-C
? 3 : bstr, ; RID-I ? 3 : bstr, ; RID-I
? 4 : uint ; Session-Lifetime ? 4 : uint ; Session-Lifetime
} }
Figure 6: CBOR data structure for CoAP-EAP Figure 6: CBOR Data Structure for CoAP-EAP
The parameters contain the following information: The parameters contain the following information:
1. Cipher Suite: Is an array with the list of proposed, or selected, 1. Cipher Suite: An array with the list of proposed, or selected,
COSE algorithms for OSCORE. If the field is carried over a CBOR Object Signing and Encryption (COSE) algorithms for OSCORE.
request, the meaning is the proposed cipher suite, if it is If the field is carried over a request, a proposed cipher suite
carried over a response, corresponds to the agreed-upon cipher is indicated; if it is carried over a response, it corresponds to
suite. the agreed-upon cipher suite.
2. RID-I: Is the Recipient ID of the EAP peer. The EAP 2. RID-C: The Recipient ID of the EAP authenticator. The EAP peer
authenticator uses this value as a Sender ID for its OSCORE uses this value as the Sender ID for its OSCORE Sender Context.
Sender Context. The EAP peer uses this value as Recipient ID for The EAP authenticator uses this value as the Recipient ID for its
its Recipient Context. Recipient Context.
3. RID-C: Is the Recipient ID of the EAP authenticator. The EAP 3. RID-I: The Recipient ID of the EAP peer. The EAP authenticator
peer uses this value as a Sender ID for its OSCORE Sender uses this value as the Sender ID for its OSCORE Sender Context.
Context. The EAP authenticator uses this value as Recipient ID The EAP peer uses this value as the Recipient ID for its
for its Recipient Context. Recipient Context.
4. Session-Lifetime: Is time the session is valid, in seconds. 4. Session-Lifetime: The time that the session is valid, in seconds.
Other indexes can be used to carry additional values as needed, like Other indexes can be used to carry additional values as needed, like
specific authorization parameters. specific authorization parameters.
The indexes from 65001 to 65535 are reserved for experimentation. The indexes from 65001 to 65535 are reserved for experimentation.
6. Cipher suite negotiation and key derivation 6. Cipher Suite Negotiation and Key Derivation
6.1. Cipher suite negotiation 6.1. Cipher Suite Negotiation
OSCORE runs after the EAP authentication, using the cipher suite OSCORE runs after the EAP authentication, using the cipher suite
selected in the cipher suite negotiation (Steps 1 and 2). To selected in the cipher suite negotiation (Steps 1 and 2 in Figure 3).
negotiate the cipher suite, CoAP-EAP follows a simple approach: the To negotiate the cipher suite, CoAP-EAP follows a simple approach:
EAP authenticator sends a list, in decreasing order of preference, The EAP authenticator sends a list, in decreasing order of
with the identifiers of the supported cipher suites (Step 1). In the preference, with the identifiers of the supported cipher suites (Step
response to that message (Step 2), the EAP peer sends a response with 1 in Figure 8). In the response to that message (Step 2 in
the 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 of the exchange with the payload can be seen in Figure 7. An example exchange for the cipher
cipher suite negotiation is shown in Figure 8, where it can be suite negotiation is shown in Figure 8. The EAP Request (EAP-Req/Id)
appreciated the disposition of both EAP-Request/Identity and EAP- and EAP Response (EAP-Resp/Id) are sent; both messages include the
Response/Identity, followed by the CBOR object defined in Section 5, CBOR Object (Section 5) containing the cipher suite field for the
containing 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
Figure 7: cipher suites are in the CoAP payload <---------- EAP Packet ----------> <-- CBOR array -->
EAP peer EAP Auth. Figure 7: Cipher Suites in the CoAP Payload
EAP peer EAP Auth.
(CoAP server) (CoAP client) (CoAP server) (CoAP client)
------------- ------------- ------------- -------------
| | | |
| ... | | ... |
|---------------------------------------->| |---------------------------------------->|
| POST /a/eap/1 | | POST /a/eap/1 |
| Payload (EAP Req/Id, CBORArray[0,1,2]) | | Payload(EAP-Req/Id, CBORArray[0,1,2]) |
1) |<----------------------------------------| 1)|<----------------------------------------|
| 2.01 Created Location-Path [/a/eap/2] | | 2.01 Created Location-Path [/a/eap/2] |
| Payload (EAP Resp/Id, CBORArray[0]) | | Payload(EAP-Resp/Id, CBORArray[0]) |
2) |---------------------------------------->| 2)|---------------------------------------->|
... ...
Figure 8: cipher suite negotiation Figure 8: Cipher Suite Negotiation
In case there is no CBOR array stating 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 are willing to accept, it MUST restricted list of cipher suites that can be accepted, it MUST
include the default value 0 since it is mandatory to implement. The include the default value 0, since it is mandatory to implement. The
EAP peer will have at least that option available. EAP peer will have at least that option available.
The cipher suite requirements are inherited from the ones established The cipher suite requirements are inherited from those established by
by OSCORE [RFC8613], which are COSE algorithms [RFC9053]. By OSCORE [RFC8613], which are COSE algorithms [RFC9053]. By default,
default, the HMAC-based Extract-and-Expand Key Derivation Function the HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
(HKDF) algorithm is SHA-256 and the AEAD algorithm is AES-CCM- algorithm is SHA-256 and the Authenticated Encryption with Associated
16-64-128 [RFC9053]. Both are mandatory to implement. The other Data (AEAD) algorithm is AES-CCM-16-64-128 [RFC9053]. ("HMAC" stands
supported and negotiated cipher suites are the following: 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):
* 0) AES-CCM-16-64-128, SHA-256 (default) * 0) AES-CCM-16-64-128, SHA-256 (default)
* 1) A128GCM, SHA-256 * 1) A128GCM, SHA-256
* 2) A256GCM, SHA-384 * 2) A256GCM, SHA-384
* 3) ChaCha20/Poly1305, SHA-256 * 3) ChaCha20/Poly1305, SHA-256
* 4) ChaCha20/Poly1305, SHAKE256 * 4) ChaCha20/Poly1305, SHAKE256
This specification uses the HKDF defined in [RFC5869] to derive the This specification uses the HKDF as defined in [RFC5869] to derive
necessary key material. Since the key derivation process uses the the necessary key material. Since the key derivation process uses
Master Session Key (MSK), which is considered fresh key material, the the MSK, which is considered fresh key material, the HKDF-Expand
HKDF-Expand function will be used (shortened here as KDF). Why the function (shortened here as "KDF") will be used. See Section 8.1
use of this function is enough, and it is not necessary to use KDF- regarding why the use of this function is enough and it is not
Extract is explained in Section 8.1. necessary to use KDF-Extract.
6.2. Deriving the OSCORE Security Context 6.2. Deriving the OSCORE Security Context
The derivation of the security context for OSCORE allows securing the The derivation of the OSCORE Security Context allows securing the
communication between the EAP peer and the EAP authenticator once the communication between the EAP peer and the EAP authenticator once the
MSK has been exported, providing confidentiality, integrity, key MSK has been exported, providing confidentiality, integrity, key
confirmation (Steps 7 and 8), and downgrading attack detection. confirmation (Steps 7 and 8 in Figure 3), and detection of
downgrading attacks.
Once Master Secret and Master Salt are derived, they can be used to Once the Master Secret and Master Salt are derived, they can be used
derive the rest of the OSCORE Security Context (see Section 3.2.1 of to derive the rest of the OSCORE Security Context (see Section 3.2.1
[RFC8613]). It should be noted that ID Context is not provided for of [RFC8613]). It should be noted that the ID Context is not
the OSCORE Security Context derivation. provided for the OSCORE Security Context derivation.
The Master Secret can be derived by using the chosen cipher suite and The Master Secret can be derived by using the chosen cipher suite and
the KDF as follows: the KDF as follows:
Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length) Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", length)
where: where:
* The MSK exported by the EAP method. Discussion about the use of * The MSK is exported by the EAP method. The use of the MSK for key
the MSK for key derivation is done in Section 8. derivation is discussed in Section 8.
* CS is the concatenation of the content of the cipher suite * CS is the concatenation of the content of the cipher suite
negotiation, that is, the concatenation of two CBOR arrays CS-C negotiation -- that is, the concatenation of two CBOR arrays CS-C
and CS-I (with CBOR ints as elements), as defined in Section 5. and CS-I (with CBOR ints as elements), as defined in Section 5.
If CS-C or CS-I were not sent, (i.e., default algorithms are used) If neither CS-C nor CS-I was sent (i.e., default algorithms are
the value used to generate CS will be the same as if the default used), the value used to generate CS will be the same as if the
algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR default algorithms were explicitly sent in CS-C or CS-I (i.e., a
array with the cipher suite 0). CBOR array with the cipher suite value of 0).
* "COAP-EAP OSCORE MASTER SECRET" is the ASCII code representation * "COAP-EAP OSCORE MASTER SECRET" is the ASCII code representation
of the non-NULL terminated string (excluding the double quotes of the non-NULL-terminated string (excluding the double quotes
around it). around it).
* CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated. * CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated.
* length is the size of the output key material. * length is the size of the output key material.
The Master Salt, similarly to the Master Secret, can be derived as Similarly to the Master Secret, the Master Salt can be derived as
follows: follows:
Master Salt = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SALT", length) Master Salt = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SALT", length)
where: where:
* The MSK is exported by the EAP method. Discussion about the use * The MSK is exported by the EAP method. The use of the MSK for key
of the MSK for the key derivation is done in Section 8. derivation is discussed in Section 8.
* CS is the concatenation of the content of the cipher suite * CS is the concatenation of the content of the cipher suite
negotiation, that is, the concatenation of two CBOR arrays CS-C negotiation -- that is, the concatenation of two CBOR arrays CS-C
and CS-I (with CBOR ints as elements), as defined in Section 5. and CS-I (with CBOR ints as elements), as defined in Section 5.
If CS-C or CS-I were not sent, (i.e., default algorithms are used) If neither CS-C nor CS-I was sent (i.e., default algorithms are
the value used to generate CS will be the same as if the default used), the value used to generate CS will be the same as if the
algorithms were explicitly sent in CS-C or CS-I (i.e., a CBOR default algorithms were explicitly sent in CS-C or CS-I (i.e., a
array with the cipher suite 0). CBOR array with the cipher suite value of 0).
* "COAP-EAP OSCORE MASTER SALT" is the ASCII code representation of * "COAP-EAP OSCORE MASTER SALT" is the ASCII code representation of
the non-NULL-terminated string (excluding the double quotes around the non-NULL-terminated string (excluding the double quotes around
it). it).
* CS and "COAP-EAP OSCORE MASTER SALT" are concatenated. * CS and "COAP-EAP OSCORE MASTER SALT" are concatenated.
* length is the size of the output key material. * length is the size of the output key material.
Since the MSK is used to derive the Master Key, the correct Since the MSK is used to derive the Master Key, the correct
verification of the OSCORE protected request (Step 7) and response verification of the OSCORE-protected request (Step 7) and response
(Step 8) confirms the EAP authenticator and the EAP peer have the (Step 8) confirms that the EAP authenticator and the EAP peer have
same Master Secret, achieving key confirmation. the same Master Secret, achieving key confirmation.
To prevent a downgrading attack, the content of the cipher suite To prevent a downgrading attack, the content of the cipher suite
negotiation (which is referred to here as CS) is embedded in the (referred to here as "CS") negotiation is embedded in the Master
Master Secret derivation. If an attacker changes the value of the Secret derivation. If an attacker changes the value of the cipher
cipher suite negotiation, the result will be different OSCORE suite negotiation, the result will be different OSCORE Security
security contexts, which ends up with a failure in Steps 7 and 8. Contexts, which in turn will result in failure in Steps 7 and 8.
The EAP authenticator will use the Recipient ID of the EAP peer (RID- The EAP authenticator will use the Recipient ID of the EAP peer (RID-
I) as the Sender ID for its OSCORE Sender Context. The EAP peer will I) as the Sender ID for its OSCORE Sender Context. The EAP peer will
use this value as Recipient ID for its Recipient Context. use this value as the Recipient ID for its Recipient Context.
The EAP peer will use the Recipient ID of the EAP authenticator (RID- The EAP peer will use the Recipient ID of the EAP authenticator (RID-
C) as the Sender ID for its OSCORE Sender Context. The EAP C) as the Sender ID for its OSCORE Sender Context. The EAP
authenticator will use this value as Recipient ID for its Recipient authenticator will use this value as the Recipient ID for its
Context. Recipient Context.
7. Discussion 7. Discussion
7.1. CoAP as EAP lower layer 7.1. CoAP as the EAP Lower Layer
This section discusses the suitability of the CoAP protocol as EAP This section discusses the suitability of CoAP as the EAP lower layer
lower layer and reviews the requisites imposed by EAP on any protocol and reviews the requisites imposed by EAP on any protocol
transporting EAP. What EAP expects from its lower layers can be transporting EAP. What EAP expects from its lower layers can be
found in Section 3.1 of [RFC3748], which is elaborated next: found in Section 3.1 of [RFC3748], which is elaborated next:
Unreliable transport. EAP does not assume that lower layers are Unreliable transport: EAP does not assume that lower layers are
reliable, but it can benefit from a reliable lower layer. In this reliable, but it can benefit from a reliable lower layer. In this
sense, CoAP provides a reliability mechanism (e.g., using Confirmable sense, CoAP provides a reliability mechanism (e.g., using
messages). Confirmable messages).
Lower layer error detection. EAP relies on lower layer error Lower-layer error detection: EAP relies on lower-layer error
detection (e.g., CRC, checksum, MIC, etc.). For simplicity, CoAP-EAP detection (e.g., CRC, checksum, Message Integrity Check (MIC),
delegates error detection to the lower layers, such as the link layer etc.). For simplicity, CoAP-EAP delegates error detection to the
or transport layer (e.g., UDP over IPv6 or TCP). 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 Lower-layer security: EAP does not require security services from
the lower layers. the lower layers.
Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 Minimum MTU: Lower layers need to provide an EAP MTU size of 1020
octets or greater. CoAP assumes an upper bound of 1024 octets for octets or greater. CoAP assumes an upper bound of 1024 octets for
its payload, which covers the EAP requirements when in the CoAP its payload, which covers the EAP requirements when only the EAP
payload only the EAP message is sent. In the case of Messages 1 and message is sent in the CoAP payload. In the case of Messages 1
2 in Figure 3, those messages have extra information apart from EAP. and 2 in Figure 3, those messages have extra information apart
Nevertheless, the EAP Req/Id has a fixed length of 5 bytes. Message from EAP. Nevertheless, the EAP-Req/Id has a fixed length of 5
2 with the EAP Resp/Id, would limit the length of the identity being bytes. Message 2, with the EAP-Resp/Id, would limit the length of
used to the CoAP payload maximum size (1024) - len( CS-I || RID-I ) - the identity being used to the CoAP payload maximum size (1024) -
EAP Response header (5 bytes), which leaves enough space for sending len( CS-I || RID-I ) - EAP Response header (5 bytes), which leaves
even lengthy identities. Nevertheless, this limitation can be enough space for sending even lengthy identities. Nevertheless,
overcome by using CoAP block-wise transfer[RFC7959]. Note: When EAP this limitation can be overcome by using CoAP block-wise transfers
is proxied over an AAA framework, the Access-Request packets in [RFC7959]. Note: When EAP is proxied over a AAA framework, the
RADIUS MUST contain a Framed-MTU attribute with the value 1024, and Access-Request packets in RADIUS MUST contain a Framed-MTU
the Framed-MTU AVP to 1024 in DIAMETER This attribute signals the AAA attribute with a value of 1024 and, in Diameter, the Framed-MTU
server that it should limit its responses to 1024 octets. 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 Ordering guarantees: EAP relies on lower-layer ordering guarantees
for correct operation. Regarding message ordering, every time a new for correct operation. Regarding message ordering, every time a
message arrives at the authentication service hosted by the EAP peer, new message arrives at the authentication service hosted by the
a new resource is created, and this is indicated in a "2.01 Created" EAP peer, a new resource is created, and this is indicated in a
response code along with the name of the new resource via Location- '2.01 Created' response code along with the name of the new
Path or Location-Query options. This way, the application shows that resource via Location-Path or Location-Query Options. This way,
its state has advanced. the application shows that its state has advanced.
Although the [RFC3748] states: "EAP provides its own support for Although [RFC3748] states that "EAP provides its own support for
duplicate elimination and retransmission", EAP is also reliant on duplicate elimination and retransmission," EAP is also reliant on
lower layer ordering guarantees. In this regard, [RFC3748] talks lower-layer ordering guarantees. In this regard, [RFC3748] talks
about possible duplication and says: "Where the lower layer is about possible duplication and says, "Where the lower layer is
reliable, it will provide the EAP layer with a non-duplicated stream reliable, it will provide the EAP layer with a non-duplicated stream
of packets. However, while it is desirable that lower layers provide of packets. However, while it is desirable that lower layers provide
for non-duplication, this is not a requirement". CoAP provides a for non-duplication, this is not a requirement." CoAP provides a
non-duplicated stream of packets and accomplishes the desirable non- non-duplicated stream of packets and accomplishes the desirable non-
duplication. In addition, [RFC3748] says that when EAP runs over a duplication. In addition, [RFC3748] says that when EAP runs over a
reliable lower layer "the authenticator retransmission timer SHOULD reliable lower layer "the authenticator retransmission timer SHOULD
be set to an infinite value, so that retransmissions do not occur at be set to an infinite value, so that retransmissions do not occur at
the EAP layer." the EAP layer."
7.2. Size of the EAP lower layer vs EAP method size 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 Regarding the impact that an EAP lower layer will have on the number
of bytes of the whole authentication exchange, there is a comparison of bytes of the whole authentication exchange, [CoAP-EAP] provides a
with another network layer-based EAP lower layer, PANA [RFC5191], in comparison with another network-layer-based EAP lower layer, the
[coap-eap]. Protocol for Carrying Authentication for Network Access (PANA) as
defined in [RFC5191].
The EAP method being transported will take most of the exchange, The EAP method being transported will take most of the exchange.
however, the impact of the EAP lower layer cannot be ignored, However, the impact of the EAP lower layer cannot be ignored,
especially in very constrained communication technologies, such as especially in very constrained communication technologies such as
the ones found in IoT, with limited capabilities. those with limited capabilities (e.g., as can be found in IoT
networks).
Note: For constrained devices and network scenarios, the use of the Note: To improve efficiency in environments with constrained devices
latest versions of EAP methods (e.g., EAP-AKA' [RFC5448], EAP-TLS 1.3 and networks, the latest versions of EAP methods (e.g., EAP-AKA'
[RFC9190]) is recommended in favor of older versions with the goal of [RFC5448], EAP-TLS 1.3 [RFC9190]) are recommended over older
economization, or EAP methods more adapted for IoT (e.g., EAP-NOOB versions. EAP methods more adapted for IoT networks (e.g., EAP-NOOB
[RFC9140], EAP-EDHOC [I-D.ietf-emu-eap-edhoc], etc.). [RFC9140], EAP-EDHOC [EAP-EDHOC], etc.) are also recommended.
8. Security Considerations 8. Security Considerations
There are some security aspects to be considered, such as how Security aspects to be considered include how authorization is
authorization is managed, the use of Master Session Key (MSK) as key managed, the use of the MSK as key material, and how trust in the EAP
material, and how trust in the EAP authenticator is established. authenticator is established. Additional considerations such as EAP
Additional considerations such as EAP channel binding as per channel binding as per [RFC6677] are also discussed here.
[RFC6677] are also discussed here.
8.1. Use of EAP Methods 8.1. Use of EAP Methods
This document limits the use of EAP methods to the ones compliant This document limits the use of EAP methods to those compliant with
with [RFC4017] specification, yielding strong and fresh session keys [RFC4017], yielding strong and fresh session keys such as the MSK.
such as the MSK. By this assumption, the HKDF-Expand function is By this assumption, the HKDF-Expand function is used directly, as
used directly, as clarified in [RFC5869]. clarified in [RFC5869].
8.2. Authorization 8.2. Authorization
Authorization is part of bootstrapping. It serves to establish Authorization is part of bootstrapping. It serves to establish
whether the EAP peer can join and the set of conditions it must whether the EAP peer can join and the set of conditions it must
adhere to. The authorization data will be gathered from the adhere to. The authorization data will be gathered from the
organization that is responsible for the EAP peer and sent to the EAP organization that is responsible for the EAP peer and sent to the EAP
authenticator in case AAA infrastructure is deployed. authenticator if a AAA infrastructure is deployed.
In standalone mode, the authorization information will be in the EAP In standalone mode, the authorization information will be in the EAP
authenticator. If the pass-through mode is used, authorization data authenticator. If pass-through mode is used, authorization data
received from the AAA server can be delivered by the AAA protocol received from the AAA server can be delivered by the AAA protocol
(e.g., RADIUS or Diameter). Providing more fine-grained (e.g., RADIUS or Diameter). Providing more fine-grained
authorization data can be with the transport of SAML in RADIUS authorization data can be done by transporting the data using the
[RFC7833]. After bootstrapping, additional authorization information Security Assertion Markup Language (SAML) in RADIUS [RFC7833]. After
may be needed to operate in the security domain. This can be taken bootstrapping, additional authorization information may be needed to
care of by the solutions proposed in the ACE WG, such as the use of operate in the security domain. This can be taken care of by the
OAuth [RFC9200], among other solutions, to provide Authentication and solutions proposed in the Authentication and Authorization for
Authorization for Constrained Environments. 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 8.3. Allowing CoAP-EAP Traffic to Perform Authentication
Since CoAP is an application protocol, CoAP-EAP assumes certain IP Since CoAP is an application protocol, CoAP-EAP assumes certain IP
connectivity in the link between the EAP peer and the EAP connectivity in the link between the EAP peer and the EAP
authenticator to run. This link MUST authorize exclusively authenticator to run. This link MUST only authorize unprotected IP
unprotected IP traffic to be sent between the EAP peer and the EAP traffic to be sent between the EAP peer and the EAP authenticator
authenticator during the authentication with CoAP-EAP. Once the during the authentication with CoAP-EAP. Once the authentication is
authentication is successful, the key material generated by the EAP successful, the key material generated by the EAP authentication
authentication (MSK) and any other traffic can be authorized if it is (MSK) and any other traffic can be authorized if it is protected. It
protected. It is worth noting that if the EAP authenticator is not is worth noting that if the EAP authenticator is not in the same link
in the same link as the EAP peer and an intermediate entity helps as the EAP peer and an intermediate entity (e.g., a CoAP proxy) helps
with this process (i.e., CoAP proxy) and the same comment applies to with this process, this concept also applies to the communication
the communication between the EAP peer and the intermediary. between the EAP peer and the intermediary.
Alternatively, the link-layer MAY provide support to transport CoAP- Alternatively, the link layer MAY provide support to transport CoAP-
EAP without an IP address by using link-layer frames (e.g. by EAP without an IP address by using link-layer frames (e.g., by
defining a new Key Management Protocol ID in IEEE 802.15.9 defining a new Key Management Protocol ID per IEEE 802.15.9
[ieee802159]). [IEEE802159]).
8.4. Freshness of the key material 8.4. Freshness of the Key Material
In CoAP-EAP there is no nonce exchange to provide freshness to the In CoAP-EAP, there is no nonce exchange to provide freshness to the
keys derived from the MSK. The MSK and Extended Master Session Key keys derived from the MSK. The MSKs and EMSKs are fresh key material
(EMSK) keys according to the EAP Key Management Framework [RFC5247] per [RFC5247]. Since only one authentication is established per EAP
are fresh key material. Since only one authentication is established authenticator, there is no need to generate additional key material.
per EAP authenticator, there is no need to generate additional key If a new MSK is required, a re-authentication can be done by running
material. In case a new MSK is required, a re-authentication can be the process again or using a more lightweight EAP method to derive
done, by running the process again or using a more lightweight EAP additional key material as elaborated in Section 3.3.
method to derive additional key material as elaborated in
Section 3.3.
8.5. Channel Binding support 8.5. Channel-Binding Support
According to the [RFC6677], channel binding, related to EAP, is sent According to [RFC6677], channel binding, as related to EAP, is sent
through the EAP method supporting it. through the EAP method supporting it.
To satisfy the requirements of the document, the EAP lower layer To satisfy the requirements of this document, the EAP lower-layer
identifier (To be assigned by IANA) needs to be sent, in the EAP identifier for CoAP-EAP (10, as assigned by IANA; see Section 9.4)
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, there is a possibility of an entity In the authentication process, it is possible for an entity to forge
forging messages to generate denial of service (DoS) attacks on any messages to generate denial-of-service (DoS) attacks on any of the
of the entities involved. For instance, an attacker can forge entities involved. For instance, an attacker can forge multiple
multiple initial messages to start an authentication (Step 0) 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
Id (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 limits 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 denial of service messages in Step 0 to provide robustness against DoS attacks. The
(DoS) attacks. The details of rate limiting are outside the scope of details of rate limiting are outside the scope of this specification.
this specification. Nevertheless, the rate of these messages is also Nevertheless, the rate of these messages is also limited by the
limited by the bandwidth available between the EAP peer and the EAP bandwidth available between the EAP peer and the EAP authenticator.
authenticator. This bandwidth will be especially limited in This bandwidth will be especially limited in constrained links (e.g.,
constrained links (e.g., LPWAN). Lastly, it is also RECOMMENDED to Low-Power WANs (LPWANs)). Lastly, it is also RECOMMENDED to reduce
reduce at a minimum the state in the EAP authenticator at least until at a minimum the state in the EAP authenticator at least until the
the EAP Response/Id 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 the EAP Key Management Framework [RFC5247]. issue is elaborated in [RFC5247]. In particular, the EAP peer knows
In particular, the EAP peer knows it can trust the EAP authenticator it can trust the EAP authenticator because the key that is used to
because the key that is used to establish the security association is establish the security association is derived from the MSK. If the
derived from the MSK. If the EAP authenticator has the MSK, it is EAP authenticator has the MSK, it is because the AAA server of the
because the AAA Server of the EAP peer trusted the EAP authenticator. EAP peer trusted the EAP authenticator.
9. IANA Considerations 9. IANA Considerations
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding the registration of values related to
CoAP-EAP.
9.1. CoAP-EAP Cipher Suites 9.1. CoAP-EAP Cipher Suites
IANA has created a new registry titled "CoAP-EAP Cipher Suites" under IANA has created a new registry titled "CoAP-EAP Cipher Suites" under
the new group name "CoAP-EAP protocol". The registration procedures a new registry group named "CoAP-EAP". The registration procedures
are "Specification Required", "Private Use", "Standards Action with are "Specification Required", "Private Use", and "Standards Action
Expert Review" and "Specification Required" following the indications with Expert Review" (see [RFC8126]), as shown in Table 1.
in Table 1.
+===============+=====================================+ +===============+=====================================+
| Range | Registration Procedures | | Range | Registration Procedures |
+===============+=====================================+ +===============+=====================================+
| -65536 to -25 | Specification Required | | -65536 to -25 | Specification Required |
+---------------+-------------------------------------+ +---------------+-------------------------------------+
| -24 to -21 | Private Use | | -24 to -21 | Private Use |
+---------------+-------------------------------------+ +---------------+-------------------------------------+
| -20 to 23 | Standards Action with Expert Review | | -20 to 23 | Standards Action with Expert Review |
+---------------+-------------------------------------+ +---------------+-------------------------------------+
| 24 to 65535 | Specification Required | | 24 to 65535 | Specification Required |
+---------------+-------------------------------------+ +---------------+-------------------------------------+
Table 1: CoAP-EAP Cipher Suites Registration Procedures Table 1: Registration Procedures for CoAP-EAP
Cipher Suites
The columns of the registry are Value, Algorithms, Description and The columns of the registry are Value, Algorithms, Description, and
Reference, where Value is an integer, and the other columns are text Reference, where Value is an integer and the other columns are text
strings. The initial contents of the registry are shown in Table 2. strings. The initial registrations are shown in Table 2.
+=======+============+============================+============+ +=======+============+=============================+===========+
| Value | Algorithms | Description | Reference | | Value | Algorithms | Description | Reference |
+=======+============+============================+============+ +=======+============+=============================+===========+
| 0 | 10, -16 | AES-CCM-16-64-128, SHA-256 | [[this | | 0 | 10, -16 | AES-CCM-16-64-128, SHA-256 | RFC 9820 |
| | | | document]] | +-------+------------+-----------------------------+-----------+
+-------+------------+----------------------------+------------+ | 1 | 1, -16 | A128GCM, SHA-256 | RFC 9820 |
| 1 | 1, -16 | A128GCM, SHA-256 | [[this | +-------+------------+-----------------------------+-----------+
| | | | document]] | | 2 | 3, -43 | A256GCM, SHA-384 | RFC 9820 |
+-------+------------+----------------------------+------------+ +-------+------------+-----------------------------+-----------+
| 2 | 3, -43 | A256GCM, SHA-384 | [[this | | 3 | 24, -16 | ChaCha20/Poly1305, SHA-256 | RFC 9820 |
| | | | document]] | +-------+------------+-----------------------------+-----------+
+-------+------------+----------------------------+------------+ | 4 | 24, -45 | ChaCha20/Poly1305, SHAKE256 | RFC 9820 |
| 3 | 24, -16 | ChaCha20/Poly1305, SHA-256 | [[this | +-------+------------+-----------------------------+-----------+
| | | | document]] |
+-------+------------+----------------------------+------------+
| 4 | 24, -45 | ChaCha20/Poly1305, | [[this |
| | | SHAKE256 | document]] |
+-------+------------+----------------------------+------------+
Table 2: CoAP-EAP Cipher Suites initial values Table 2: CoAP-EAP Cipher Suites: Initial Registrations
9.2. CDDL in CoAP-EAP Information elements 9.2. CDDL in CoAP-EAP Information Elements
IANA has created a new registry titled "CoAP-EAP Information element" IANA has created a new registry titled "CoAP-EAP Information
under the new group name "CoAP-EAP protocol". The registration Elements" under a new registry group named "CoAP-EAP". The
procedure are "Specification Required", "Private Use", "Standards registration procedures are "Standards Action with Expert Review",
Action with Expert Review" and "Specification Required" following the "Private Use", "Specification Required", and "Experimental Use" (see
indications in Table 3. [RFC8126]), as shown in Table 3.
+================+=====================================+ +================+=====================================+
| Range | Registration Procedures | | Range | Registration Procedures |
+================+=====================================+ +================+=====================================+
| 0 to 23 | Standards Action with Expert Review | | 0 to 23 | Standards Action with Expert Review |
+----------------+-------------------------------------+ +----------------+-------------------------------------+
| 24 to 49 | Private Use | | 24 to 49 | Private Use |
+----------------+-------------------------------------+ +----------------+-------------------------------------+
| 50 to 65000 | Specification Required | | 50 to 65000 | Specification Required |
+----------------+-------------------------------------+ +----------------+-------------------------------------+
| 65001 to 65535 | Experimental Use | | 65001 to 65535 | Experimental Use |
+----------------+-------------------------------------+ +----------------+-------------------------------------+
Table 3: CoAP-EAP Information Elements Registration Table 3: Registration Procedures for CoAP-EAP
Procedures Information Elements
The columns of the registry are Name, Label, CBOR Type, Description The columns of the registry are Name, Label, CBOR Type, Description,
and Reference, where Value is an integer, and the other columns are and Reference, where Label is an integer and the other columns are
text strings. The initial contents of the registry are described in text strings. The initial registrations are shown in Table 4.
Table 4.
+==================+=======+========+===============+============+ +==================+=======+========+===============+===========+
| Name | Label | CBOR | Description | Reference | | Name | Label | CBOR | Description | Reference |
| | | Type | | | | | | Type | | |
+==================+=======+========+===============+============+ +==================+=======+========+===============+===========+
| Cipher Suite | 1 | CBOR | List of the | [[this | | Cipher Suite | 1 | CBOR | List of the | RFC 9820 |
| | | Array | proposed or | document]] | | | | Array | proposed or | |
| | | | selected COSE | | | | | | selected COSE | |
| | | | algorithms | | | | | | algorithms | |
| | | | for OSCORE | | | | | | for OSCORE | |
+------------------+-------+--------+---------------+------------+ +------------------+-------+--------+---------------+-----------+
| RID-C | 2 | Byte | It contains | [[this | | RID-C | 2 | Byte | Contains the | RFC 9820 |
| | | String | the Recipient | document]] | | | | String | Recipient ID | |
| | | | ID of the EAP | | | | | | of the EAP | |
| | | | authenticator | | | | | | authenticator | |
+------------------+-------+--------+---------------+------------+ +------------------+-------+--------+---------------+-----------+
| RID-I | 3 | Byte | It contains | [[this | | RID-I | 3 | Byte | Contains the | RFC 9820 |
| | | String | the Recipient | document]] | | | | String | Recipient ID | |
| | | | ID of the EAP | | | | | | of the EAP | |
| | | | peer | | | | | | peer | |
+------------------+-------+--------+---------------+------------+ +------------------+-------+--------+---------------+-----------+
| Session-Lifetime | 4 | uint | Contains the | [[this | | Session-Lifetime | 4 | uint | Contains the | RFC 9820 |
| | | | time the | document]] | | | | | time that the | |
| | | | session is | | | | | | session is | |
| | | | valid in | | | | | | valid, in | |
| | | | seconds | | | | | | seconds | |
+------------------+-------+--------+---------------+------------+ +------------------+-------+--------+---------------+-----------+
Table 4: CoAP-EAP Information Elements initial content Table 4: CoAP-EAP Information Elements: Initial Registrations
9.3. The Well-Known URI Registry 9.3. The Well-Known URIs Registry
IANA has added the well-known URI "coap-eap" to the "Well-Known URIs" 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]. registry under the "Well-Known URIs" registry group defined by
[RFC8615].
* 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 URI Suffix: coap-eap
Layer" under the Extensible Authentication Protocol (EAP) Registry Reference: RFC 9820
defined by [RFC6677]. Status: permanent
Change Controller: IETF
* Value: TBD. 9.4. The EAP Lower Layers Registry
* Lower Layer: CoAP-EAP IANA has added the identifier "CoAP-EAP" to the "EAP Lower Layers"
registry (defined by [RFC6677]) under the "Extensible Authentication
Protocol (EAP) Registry".
* Specification document(s): [[this document]] Value: 10
Lower Layer: CoAP-EAP
Reference: RFC 9820
9.5. Media Types Registry 9.5. Media Types Registry
IANA has added the media types "application/coap-eap" to the "Media IANA has added the media type "application/coap-eap" to the "Media
Types" registry. Section 4 defines the format. Types" registry. Section 4 defines the format.
* Type name: application Type name: application
* Subtype name: coap-eap
* Required parameters: N/A
* Optional parameters: N/A Subtype name: coap-eap
* Encoding considerations: binary Required parameters: N/A
* Security considerations: See Section 8 of [[this document]]. Optional parameters: N/A
* Interoperability considerations: N/A Encoding considerations: binary
* Published specification: [[this document]] Security considerations: See Section 8 of RFC 9820.
* Applications that use this media type: To be identified Interoperability considerations: N/A
* Fragment identifier considerations: N/A Published specification: RFC 9820
* Additional information: Applications that use this media type: To be identified
- Magic number(s): N/A Fragment identifier considerations: N/A
- File extension(s): N/A Additional information:
- Macintosh file type code(s): N/A 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: Person and email address to contact for further information:
ace@ietf.org ace@ietf.org
* Intended usage: COMMON Intended usage: COMMON
* Restrictions on usage: N/A Restrictions on usage: N/A
* Author: See "Authors' Addresses" section of [[this document]]. Author: See the "Authors' Addresses" section of RFC 9820.
* Change Controller: IETF Change Controller: IETF
9.6. CoAP Content-Formats Registry 9.6. CoAP Content-Formats Registry
IANA has added the media types "application/coap-eap" to the "CoAP IANA has added the media type "application/coap-eap" to the "CoAP
Content-Formats" registry under the group name "Constrained RESTful Content-Formats" registry under the "Constrained RESTful Environments
Environments (CoRE) Parameters" following the specification in (CoRE) Parameters" registry group, following the specification in
Section 12.3 of [RFC7252]. Section 12.3 of [RFC7252].
+======================+==================+=====+===================+ +======================+==================+=====+===========+
| Media Type | Content Encoding | ID | Reference | | Media Type | Content Encoding | ID | Reference |
+======================+==================+=====+===================+ +======================+==================+=====+===========+
| application/coap-eap | - | TBD | [[this | | application/coap-eap | - | 269 | RFC 9820 |
| | | | document]] | +----------------------+------------------+-----+-----------+
+----------------------+------------------+-----+-------------------+
Table 5: CoAP Content-Formats Registry Table 5: CoAP Content-Formats Registry
9.7. Resource Type (rt=) Link Target Attribute Values Registry 9.7. Resource Type (rt=) Link Target Attribute Values Registry
IANA has added the resource type "core.coap-eap" to the "Resource IANA has added the resource type "core.coap-eap" to the "Resource
Type (rt=) Link Target Attribute Values" registry under the group Type (rt=) Link Target Attribute Values" registry under the
name "Constrained RESTful Environments (CoRE) Parameters". "Constrained RESTful Environments (CoRE) Parameters" registry group.
* Value: "core.coap-eap"
- Description: CoAP-EAP resource. +===============+===================+===========+
| Value | Description | Reference |
+===============+===================+===========+
| core.coap-eap | CoAP-EAP resource | RFC 9820 |
+---------------+-------------------+-----------+
- Reference: [[this document]] Table 6: Resource Type (rt=) Link Target
Attribute Values Registry
9.8. Expert Review Instructions 9.8. Expert Review Instructions
The IANA registries established in this document are defined as The IANA registries established in this document apply the
"Specification Required", "Private Use", "Standards Action with "Specification Required", "Private Use", "Standards Action with
Expert Review", "Experimental Use" and "Specification Required". Expert Review", and "Experimental Use" policies. (See also
This section provides general guidelines for what experts should [RFC8126].) This section provides general guidelines for what
focus on, but as they are designated experts for a reason, they experts should focus on, but as they are designated experts for a
should be granted flexibility. reason, they should be granted flexibility.
* When defining the use of CoAP-EAP Information Elements: Experts * When defining the use of CoAP-EAP Information Elements (IEs),
are expected to evaluate how the values are defined, their scope, experts are expected to evaluate how the values are defined, their
and whether they align with CoAP-EAP's functionality and scope, and whether they align with CoAP-EAP's functionality and
constraints. They are expected to assess if the values are clear, constraints. They are expected to assess whether the values are
well-structured, and follow CoAP and CoAP-EAP conventions, such as clear, well structured, and follow CoAP and CoAP-EAP conventions,
concise encoding for constrained environments. They should ensure such as concise encoding for constrained environments. They
these IEs can seamlessly integrate with existing CoAP should ensure that these IEs can seamlessly integrate with
implementations and extensions. It is also expected that they existing CoAP implementations and extensions. Experts are also
verify if IE values are protected from unauthorized modification expected to verify that IE values are protected from unauthorized
or misuse during transmission. modification or misuse during transmission.
* When adding new cipher suites: Experts must ensure that algorithm * When adding new cipher suites, experts must ensure that algorithm
values are sourced from the appropriate registry when required. values are sourced from the appropriate registry when required.
They should also consider seeking input from relevant IETF working They should also consider seeking input from relevant IETF working
groups regarding the accuracy of registered parameters. groups regarding the accuracy of registered parameters.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 29, line 27 skipping to change at line 1288
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>. <https://www.rfc-editor.org/info/rfc8613>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949, Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020, DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>. <https://www.rfc-editor.org/info/rfc8949>.
10.2. Informative References 10.2. Informative References
[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",
2016, <https://www.mdpi.com/1424-8220/16/3/358>. Sensors, vol. 16, no. 3, DOI 10.3390/s16030358, 2016,
<https://www.mdpi.com/1424-8220/16/3/358>.
[EAP-framework-IoT]
Sethi, M., "Secure Network Access Authentication for IoT
Devices: EAP Framework vs. Individual Protocols", 2021,
<https://ieeexplore.ieee.org/document/9579387>.
[I-D.ietf-emu-eap-edhoc] [EAP-EDHOC]
Garcia-Carrillo, D., Marin-Lopez, R., Selander, G., and J. Garcia-Carrillo, D., Marin-Lopez, R., Selander, G., Preuß
P. Mattsson, "Using the Extensible Authentication Protocol Mattsson, J., and F. Lopez-Gomez, "Using the Extensible
(EAP) with Ephemeral Diffie-Hellman over COSE (EDHOC)", Authentication Protocol (EAP) with Ephemeral Diffie-
Work in Progress, Internet-Draft, draft-ietf-emu-eap- Hellman over COSE (EDHOC)", Work in Progress, Internet-
edhoc-02, 21 October 2024, 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-02>. edhoc-05>.
[ieee802159] [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 IEEE, "IEEE Standard for Transport of Key Management
Protocol (KMP) Datagrams", 2021. 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] [LO-CoAP-EAP]
Garcia-Carrillo, D., Marin-Lopez, R., Kandasamy, A., and Garcia-Carrillo, D., Marin-Lopez, R., Kandasamy, A., and
A. Pelov, "A CoAP-Based Network Access Authentication A. Pelov, "A CoAP-Based Network Access Authentication
Service for Low-Power Wide Area Networks: LO-CoAP-EAP", Service for Low-Power Wide Area Networks: LO-CoAP-EAP",
2017, <https://www.mdpi.com/1424-8220/17/11/2646>. 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 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible
Authentication Protocol (EAP) Method Requirements for Authentication Protocol (EAP) Method Requirements for
Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March Wireless LANs", RFC 4017, DOI 10.17487/RFC4017, March
2005, <https://www.rfc-editor.org/info/rfc4017>. 2005, <https://www.rfc-editor.org/info/rfc4017>.
[RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba,
"State Machines for Extensible Authentication Protocol "State Machines for Extensible Authentication Protocol
(EAP) Peer and Authenticator", RFC 4137, (EAP) Peer and Authenticator", RFC 4137,
DOI 10.17487/RFC4137, August 2005, DOI 10.17487/RFC4137, August 2005,
skipping to change at page 31, line 22 skipping to change at line 1383
Format, and Confirmation Methods for the Security Format, and Confirmation Methods for the Security
Assertion Markup Language (SAML)", RFC 7833, Assertion Markup Language (SAML)", RFC 7833,
DOI 10.17487/RFC7833, May 2016, DOI 10.17487/RFC7833, May 2016,
<https://www.rfc-editor.org/info/rfc7833>. <https://www.rfc-editor.org/info/rfc7833>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967, No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/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 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>. <https://www.rfc-editor.org/info/rfc8615>.
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained Context Header Compression (SCHC) for the Constrained
skipping to change at page 32, line 26 skipping to change at line 1437
Extensible Authentication Protocol with TLS 1.3", Extensible Authentication Protocol with TLS 1.3",
RFC 9190, DOI 10.17487/RFC9190, February 2022, RFC 9190, DOI 10.17487/RFC9190, February 2022,
<https://www.rfc-editor.org/info/rfc9190>. <https://www.rfc-editor.org/info/rfc9190>.
[RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and [RFC9200] Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments Using the OAuth 2.0 Framework Constrained Environments Using the OAuth 2.0 Framework
(ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022, (ACE-OAuth)", RFC 9200, DOI 10.17487/RFC9200, August 2022,
<https://www.rfc-editor.org/info/rfc9200>. <https://www.rfc-editor.org/info/rfc9200>.
[THREAD] Thread Group, "Thread specification 1.3", 2023. [THREAD] Kumar, S. and E. Dijk, "Thread 1.4 Features White Paper",
September 2024,
<https://www.threadgroup.org/Portals/0/Documents/
Thread_1.4_Features_White_Paper_September_2024.pdf>.
[TS133.501] [TS133.501]
ETSI, "5G; Security architecture and procedures for 5G ETSI, "5G; Security architecture and procedures for 5G
System - TS 133 501 V15.2.0 (2018-10)", 2018. 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>.
[ZigbeeIP] Zigbee Alliance, "ZigBee IP Specification (Zigbee Document Appendix A. Flow of Operation (DTLS Establishment)
095023r34)", 2014.
Appendix A. Flow of operation (DTLS establishment) CoAP-EAP makes it possible to derive a Pre-Shared Key (PSK) from the
MSK to allow (D)TLS PSK-based authentication between the EAP peer and
the EAP authenticator instead of using OSCORE. In the case of using
(D)TLS to establish a security association, there is a limitation on
the use of intermediaries between the EAP peer and the EAP
authenticator, as (D)TLS breaks the end-to-end communications when
using intermediaries such as proxies.
CoAP-EAP makes it possible to derive a PSK from the MSK to allow Figure 9 shows the last steps of the flow of operation for CoAP-EAP
(D)TLS PSK-based authentication between the EAP peer and the EAP when (D)TLS is used to protect the communication between the EAP peer
authenticator instead of using OSCORE. In the case of using (D)TLS and the EAP authenticator using the keying material exported by the
to establish a security association, there is a limitation on the use EAP authentication. The general flow is essentially the same as in
of intermediaries between the EAP peer and the EAP authenticator, as the case of OSCORE, except that DTLS negotiation is established in
(D)TLS breaks the end-to-end communications when using intermediaries Step 7. Once DTLS negotiation has finished successfully, the EAP
such as proxies. peer is granted access to the domain. Step 7 MUST be interpreted by
the EAP peer as an alternate success indication, which will end up
with the MSK and the DTLS_PSK derivation for the (D)TLS
authentication based on the PSK.
EAP peer EAP authenticator EAP peer EAP authenticator
------------- ------------- ------------- -------------
... ...
| 2.01 Created Location-Path [/a/eap/(n)] | | 2.01 Created Location-Path [/a/eap/(n)] |
| Payload (EAP-X Resp) | | Payload(EAP-X-Resp) |
6) |---------------------------------------->| 6)|---------------------------------------->|
| | MSK | | MSK
| (D)TLS 1.3 Client Hello | | | (D)TLS 1.3 Client Hello | |
MSK 7) |<----------------------------------------| V MSK 7)|<----------------------------------------| v
| | | DTLS_PSK | | | DTLS_PSK
V |===============DTLS hanshake=============| v |============= DTLS handshake ============|
DTLS_PSK | | DTLS_PSK | |
<-(Protected with (D)TLS)-> <-- Protected with (D)TLS -->
Figure 9: CoAP-EAP flow of operation with DTLS
Figure 9 shows the last steps of the operation for CoAP-EAP when Figure 9: CoAP-EAP Flow of Operation with DTLS
(D)TLS is used to protect the communication between the EAP peer and
the EAP authenticator using the keying material exported by the EAP
authentication. The general flow is essentially the same as in the
case of OSCORE, except that DTLS negotiation is established in Step
7). Once DTLS negotiation has finished successfully, the EAP peer is
granted access to the domain. Step 7 MUST be interpreted by the EAP
peer as an alternate success indication, which will end up with the
MSK and the DTLS_PSK derivation for the (D)TLS authentication based
on PSK.
According to [RFC8446] the provision of the PSK out-of-band also According to [RFC8446], the provision of the PSK out of band also
requires the provision of the KDF hash algorithm and the PSK requires the provision of the KDF hash algorithm and the PSK
identity. To simplify the design in CoAP-EAP, the KDF hash algorithm identity. To simplify the design in CoAP-EAP, the KDF hash algorithm
can be included in the list of cipher suites exchanged in Step 1 and can be included in the list of cipher suites exchanged in Steps 1 and
Step 2 if DTLS wants to be used instead of OSCORE. For the same 2 (Figure 8) if one wants to use DTLS instead of OSCORE. For the
reason, the PSK identity is derived from (RID-C) (RID-I) as defined same reason, the PSK identity is derived from RID-C || RID-I as
in Appendix A.1. defined in Appendix A.1.
Analogous to how the cipher suite is negotiated for OSCORE Analogous to how the cipher suite is negotiated for OSCORE
Section 6.1, the EAP authenticator sends a list, in decreasing order (Section 6.1), the EAP authenticator sends a list, in decreasing
of preference, with the identifiers of the hash algorithms supported order of preference, with the identifiers of the hash algorithms
(Step 1). In the response, the EAP peer sends the choice. supported (Step 1). In the response, the EAP peer sends its choice.
This list is included in the payload after the EAP message with a This list is included in the payload after the EAP message with a
CBOR array that contains the cipher suites. This CBOR array is CBOR array that contains the cipher suites. This CBOR array is
enclosed as one of the elements of the CBOR Object used for enclosed as one of the elements of the CBOR Object used for
transporting information in CoAP-EAP (See Section 5). An example of transporting information in CoAP-EAP (see Section 5). An example of
how the fields are arranged in the CoAP payload can be seen in how the fields are arranged in the CoAP payload can be seen in
Figure 7. Figure 7.
In case there is no CBOR array stating 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 is willing to accept, 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: function to be used to derive the "DTLS_PSK" from the MSK. The
following hash algorithms are considered in cases where the
The hash algorithms considered are the following: specification includes DTLS support in the future:
* 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 if the EAP authenticator intends to establish an algorithm, indicates that the EAP authenticator intends to establish
OSCORE security association or a DTLS security association after the an OSCORE security association or a DTLS security association after
authentication is completed. If both options appear in the cipher the authentication is completed. If both options appear in the
suite negotiation, the OSCORE security association will be preferred cipher suite negotiation, the OSCORE security association will be
over DTLS. preferred over DTLS.
A.1. Deriving DTLS PSK and identity A.1. Deriving DTLS_PSK and Identity
To enable DTLS after an EAP authentication, the Identity and the PSK To enable DTLS after an EAP authentication, Identity and the PSK for
for DTLS is defined. The Identity in this case is generated by DTLS are defined. Identity in this case is generated by
concatenating the exchanged Sender ID and the Recipient ID. concatenating the exchanged Sender ID and the Recipient ID.
CoAP-EAP PSK Identity = RID-C || RID-I CoAP-EAP PSK Identity = RID-C || RID-I
It is also possible to derive a pre-shared key for DTLS [RFC9147], It is also possible to derive a PSK for DTLS [RFC9147], referred to
referred to here as "DTLS PSK", from the MSK between both the EAP here as "DTLS_PSK", from the MSK between both the EAP peer and EAP
peer and EAP authenticator if required. The length of the DTLS PSK authenticator if required. The length of the DTLS_PSK will depend on
will depend on the cipher suite. To have keying material with the cipher suite. To have keying material with sufficient length, a
sufficient length, a key of 32 bytes is derived that can be later key of 32 bytes is derived that can be truncated later if needed:
truncated if needed:
DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length). DTLS_PSK = KDF(MSK, "CoAP-EAP DTLS_PSK", length)
where: where:
* MSK is exported by the EAP method. * The MSK is exported by the EAP method.
* "CoAP-EAP DTLS PSK" is the ASCII code representation of the non- * "CoAP-EAP DTLS_PSK" is the ASCII code representation of the non-
NULL terminated string (excluding the double quotes around it). NULL-terminated string (excluding the double quotes around it).
* length is the size of the output key material. * length is the size of the output key material.
Appendix B. Using CoAP-EAP for distributing key material for IoT Appendix B. Using CoAP-EAP for Distributing Key Material for IoT
networks Networks
Similarly, to the example of Appendix A.1, where a shared key PSK for Similarly to the example in Appendix A.1, where a PSK for DTLS is
DTLS is derived, it is possible to provide key material to different derived, it is possible to provide key material to different link
link-layers after the CoAP-EAP authentication is complete. layers after the CoAP-EAP authentication is complete.
One example is that CoAP-EAP could be used to derive the required PSK For example, CoAP-EAP could be used to derive the PSK required to run
required to run the 6TiSCH Constrained Join Protocol (CoJP) the Constrained Join Protocol (CoJP) for IPv6 over the TSCH mode of
[RFC9031]. IEEE 802.15.4e (6TiSCH) [RFC9031]. ("TSCH" stands for "Time-Slotted
Channel Hopping".)
Another example is when a shared Network Key is required by the Another example would be when a shared Network Key is required by the
devices that join a network. An example of this Network Key can be devices that join a network. An example of this Network Key can be
found in ZigBee IP [ZigbeeIP] or THREAD protocol [THREAD]. After found in the THREAD protocol [THREAD]. After CoAP-EAP execution, a
CoAP-EAP execution, a security association based on OSCORE protects security association based on OSCORE protects any exchange between
any exchange between the EAP peer and the EAP authenticator. This the EAP peer and the EAP authenticator. This security association
security association can be used for distributing the Network Key can be used for distributing the Network Key securely and other
securely and other required parameters. How the Network Key is required parameters. How the Network Key is distributed after a
distributed after a successful CoAP-EAP authentication is out of the successful CoAP-EAP authentication is outside the scope of this
scope of this document. document.
How a particular link-layer technology uses the MSK to derive further How a particular link-layer technology uses the MSK to derive further
key material for protecting the link-layer or use the OSCORE key material for protecting the link layer or uses OSCORE protection
protection to distribute key material is out of the scope of this to distribute key material is outside the scope of this document.
document.
Appendix C. Examples of Use Case Scenario Appendix C. Example Use Case Scenarios
In IoT, for an EAP peer to act as a trustworthy entity within a In IoT networks, for an EAP peer to act as a trustworthy entity
security domain, certain key material needs to be shared between the within a security domain, certain key material needs to be shared
EAP peer and the EAP authenticator. between the EAP peer and the EAP authenticator.
Next, examples of different use case scenarios will be elaborated on, Next, examples of different use case scenarios will be elaborated on
about the usage of CoAP-EAP. as related to the usage of CoAP-EAP.
Generally, four entities are involved: Generally, four entities are involved:
* 2 EAP peers (A and B), which are EAP peers. They are the EAP * Two EAP peers (A and B).
peers.
* 1 EAP authenticator (C). The EAP authenticator manages a domain * One EAP authenticator (C). The EAP authenticator manages a domain
where EAP peers can be deployed. In IoT, it can be considered a where EAP peers can be deployed. In IoT networks, it can be
more powerful machine than the EAP peers. considered a more powerful machine than the EAP peers.
* 1 AAA server (AAA) - Optional. The AAA is an Authentication, * One AAA server. Optional. The AAA server is not constrained.
Authorization, and Accounting Server, which is not constrained. Here, the EAP authenticator is operating in pass-through mode.
Here, the EAP authenticator acts as an EAP authenticator in pass-
through mode.
Generally, any EAP peer wanting to join the domain managed by the EAP Generally, any EAP peer wanting to join the domain managed by the EAP
authenticator MUST perform a CoAP-EAP authentication with the EAP authenticator MUST perform a CoAP-EAP authentication with the EAP
authenticator (C). This authentication MAY involve an external AAA authenticator (C). This authentication MAY involve an external AAA
server. This means that A and B, once deployed, will run CoAP-EAP server. This means that the EAP peers (A and B), once deployed, will
once, as a bootstrapping phase, to establish a security association run CoAP-EAP once, as a bootstrapping phase, to establish a security
with C. Moreover, any other entity, which wants to join and association with C. Moreover, any other entity that wants to join
establish communications with EAP peers under C's domain must also do and establish communications with EAP peers under C's domain must
the same. also do the same.
By using EAP, the flexibility of having different types of By using EAP, the flexibility of having different types of
credentials can be achieved. For instance, if a device that is not credentials can be achieved. For instance, if a device that is not
battery-dependent and not very constrained is available, a heavier battery dependent and not very constrained is available, a heavier
authentication method could be used. With varied EAP peers and authentication method could be used. With varied EAP peers and
networks, more lightweight authentication methods might need to be networks, authentication methods that are more lightweight (e.g.,
used (e.g., EAP-NOOB[RFC9140], EAP-AKA'[RFC5448], EAP-PSK[RFC4764], EAP-NOOB [RFC9140], EAP-AKA' [RFC5448], EAP-PSK [RFC4764], EAP-EDHOC
EAP-EDHOC[I-D.ietf-emu-eap-edhoc], etc.) being able to adapt to [EAP-EDHOC], etc.) and are able to adapt to different types of
different types of devices according to organization policies or devices according to organization policies or device capabilities
devices capabilities. might need to be used.
C.1. Example 1: CoAP-EAP in ACE C.1. Example 1: CoAP-EAP Using ACE
In ACE, the process of client registration and provisioning of When using ACE, the process of client registration and provisioning
credentials to the client is not specified. The process of Client of credentials to the client is not specified. The process of client
registration and provisioning can be achieved using CoAP-EAP. Once registration and provisioning can be achieved using CoAP-EAP. Once
the process of authentication with EAP is completed, the fresh key the process of authentication with EAP is completed, the fresh key
material is shared between the EAP peer and the EAP authenticator. material is shared between the EAP peer and the EAP authenticator.
In this instance, the EAP authenticator and the Authorization Server With ACE, the EAP authenticator and the Authorization Server (AS) can
(AS) of ACE can be co-located. be co-located.
Next, a general way to exemplify how Client registration can be Next, a general way to exemplify how client registration can be
performed using CoAP-EAP is presented, to allow two EAP peers (A and performed using CoAP-EAP is presented, to allow two EAP peers (A and
B) to communicate and interact after a successful client B) to communicate and interact after a successful client
registration. registration.
EAP peer A wants to communicate with EAP peer B (e.g., to activate a 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. 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 also be 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 * In the first phase, EAP peer A does not yet belong to EAP
enrolled in the EAP authenticator C's domain for some time. In authenticator C's domain. Then, it communicates with C and
particular, [RFC5247] recommends 8 hours, though the entity providing authenticates with CoAP-EAP, which, optionally, communicates with
the authorization information can establish this lifetime. In the the AAA server to complete the authentication process. If the
same manner, B needs to perform the same process with CoAP-EAP to be authentication is successful, a fresh MSK is shared between C and
part of EAP authenticator C's domain. EAP peer A. This key material allows EAP peer A to establish a
security association with C. Some authorization information may
also be provided in this step. If EAP is used in standalone mode,
the AS itself, having information about the devices, can be the
entity providing said authorization information.
In the second phase, when EAP peer A wants to talk to EAP peer B, it If authentication and authorization are correct, EAP peer A is
contacts EAP authenticator C for authorization to access EAP peer B enrolled in EAP authenticator C's domain for some period of time.
and obtain all the required information to do that securely (e.g., In particular, [RFC5247] recommends 8 hours, though the entity
keys, tokens, authorization information, etc.). This phase does NOT providing the authorization information can establish this
require the usage of CoAP-EAP. The details of this phase are out of lifetime. In the same manner, B needs to perform the same process
the scope of this document, and the ACE framework is used for this with CoAP-EAP to be part of EAP authenticator C's domain.
purpose [RFC9200].
In the third phase, EAP peer A can access EAP peer B with the * In the second phase, when EAP peer A wants to talk to EAP peer B,
credentials and information obtained from EAP authenticator C in the it contacts EAP authenticator C for authorization to access EAP
second phase. This access can be repeated without contacting the EAP peer B and obtain all the required information to do that securely
authenticator, while the credentials given to A are still valid. The (e.g., keys, tokens, authorization information, etc.). This phase
details of this phase are out of the scope of this document. does NOT require the usage of CoAP-EAP. The details of this phase
are outside the scope of this document; the ACE framework is used
for this purpose. See [RFC9200].
It is worth noting that the first phase with CoAP-EAP is required to * In the third phase, EAP peer A can access EAP peer B with the
join the EAP authenticator C's domain. Once it is performed credentials and information obtained from EAP authenticator C
successfully, the communications are local to the EAP authenticator during the second phase. This access can be repeated without
C's domain and there is no need to perform a new EAP authentication contacting the EAP authenticator, as long as the credentials given
as long as the key material is still valid. When the keys are about to A are still valid. The details of this phase are outside the
to expire, the EAP peer can engage in a re-authentication as scope of this document.
explained in Section 3.3, to renew the key material.
C.2. Example 2: Multi-domain with AAA infrastructures 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.
A device (A) of the domain acme.org, which uses a specific kind of C.2. Example 2: Multiple Domains with AAA Infrastructures
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 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.
As a University Campus, with several Faculty buildings and each one C.3. Example 3: Single Domain with a AAA Infrastructure
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 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 In another case, without a AAA infrastructure, with an EAP
authenticator that has co-located the EAP server, and using EAP authenticator that has co-located the EAP server, and using EAP
standalone mode, all the devices can be managed within the same standalone mode, all the devices can be managed within the same
domain locally. Client registration of an EAP peer (A) with domain locally. Client registration of an EAP peer (A) with a
Controller (C) can also be performed in the same manner. Controller (C) can also be performed in the same manner.
C.5. Other use cases C.5. Other Use Cases
C.5.1. CoAP-EAP for network access authentication C.5.1. CoAP-EAP for Network Access Authentication
One of the first steps for an EAP peer is to perform the One of the first steps for an EAP peer is to perform the
authentication to gain access to the network. To do so, the device authentication to gain access to the network. To do so, the device
first must be authenticated and granted authorization to gain access must first be authenticated and granted authorization to gain access
to the network. Additionally, security parameters such as to the network. Additionally, security parameters such as
credentials can be derived from the authentication process, allowing credentials can be derived from the authentication process, allowing
the trustworthy operation of the EAP peer in a particular network by the trustworthy operation of the EAP peer in a particular network by
joining the security domain. By using EAP, this can be achieved with joining the security domain. By using EAP, this can be achieved with
flexibility and scalability, because of the different EAP methods flexibility and scalability, because of the different EAP methods
available and the ability to rely on AAA infrastructures if needed to available and the ability to rely on AAA infrastructures if needed to
support multi-domain scenarios, which is a key feature when the EAP support multi-domain scenarios, which is a key feature when the EAP
peers deployed under the same security domain belong, for example, to peers deployed under the same security domain belong, for example, to
different organizations. different organizations.
In the process of joining a network, there are two cases: 1) the node The following two cases apply to the process of joining a network:
does not have an IPv6 address; 2) the node does have an IPv6 address 1) the node has an IPv6 address (e.g., link-local IPv6 or IPv6 global
(e.g., link-local IPv6 or IPv6 global address). address) and 2) the node does not have an IPv6 address.
In networks where the device is placed, and no IP support is In networks where the device is in place but no IP support is
available until the EAP peer is authenticated, specific support for available until the EAP peer is authenticated, specific support for
this EAP lower layer has to be defined to allow CoAP-EAP messages to this EAP lower layer has to be defined to allow CoAP-EAP messages to
be exchanged between the EAP peer and the EAP authenticator. For be exchanged between the EAP peer and the EAP authenticator. For
example, in IEEE 802.15.4 networks, a new KMP ID can be defined to example, in IEEE 802.15.4 networks, a new Key Management Protocol
add such support in the case of IEEE 802.15.9 [ieee802159]. Where (KMP) ID can be defined to add such support in the case of IEEE
can be assumed that the device has at least a link-layer IPv6 802.15.9 [IEEE802159], where it can be assumed that the device has at
address. least a link-layer IPv6 address.
When the EAP peer intends to be admitted into the network, it would When the EAP peer intends to be admitted into the network, it would
search for an entity that offers the CoAP-EAP service, be it the EAP search for an entity that offers the CoAP-EAP service, be it directly
authenticator directly, or through the intermediary (i.e., proxy). via the EAP authenticator or through an intermediary (e.g., proxy).
See Section 3.1. See Section 3.1.
CoAP-EAP will run between the EAP peer and the EAP authenticator or CoAP-EAP will run between the EAP peer and the EAP authenticator or
through an intermediary entity such as a proxy, as happens in a mesh through an intermediary entity such as a proxy, as happens in a mesh
network, where the EAP authenticator could be placed to 1 or more network, where the EAP authenticator could be placed one or more hops
hops from the EAP peer. In the case a proxy participates in CoAP- away from the EAP peer. In the case that a proxy participates in
EAP, it will be because it is already a trustworthy entity within the CoAP-EAP, it will be because it is already a trustworthy entity
domain, which communicates through a secure channel with the EAP within the domain and communicates through a secure channel with the
authenticator, as illustrated by Figure 10. EAP authenticator, as illustrated by Figure 10.
Thus, the EAP peer follows the same process described in If the EAP peer cannot connect to the EAP authenticator directly, the
Appendix C.5.1 to perform the authentication. As mentioned, either EAP peer can follow the same process as that described in Section 3.6
with a direct link to the EAP authenticator, or through an to perform the authentication (i.e., can connect via an intermediary
intermediary entity (proxy) that is already part of the network entity (e.g., proxy) that is already part of the network (already
(already shares key material and communicates through a secure shares key material and communicates through a secure channel with
channel with the authenticator) and can aid in running CoAP-EAP. the authenticator) and can aid in running CoAP-EAP).
When CoAP-EAP is completed, and the OSCORE security association is When CoAP-EAP is completed and the OSCORE security association is
established with the EAP authenticator, the EAP peer receives the established with the EAP authenticator, the EAP peer receives the
local configuration parameters for the network (e.g. a network key) local configuration parameters for the network (e.g., a Network Key)
and can configure a global IPv6 address. Moreover, there is no need and can configure a global IPv6 address. Moreover, there is no need
of a CoAP proxy after a successful authentication. for an intermediary entity after a successful authentication.
For removal, if the EAP authenticator decides to remove a particular For removal, if the EAP authenticator decides to remove a particular
EAP peer from the network or the peer itself intends to leave, either EAP peer from the network or the peer itself intends to leave, either
EAP peer or EAP authenticator can directly send a DELETE command to the EAP peer or the EAP authenticator can directly send a DELETE
explicitly express that the network access state is removed, and the command to explicitly express that the network access state is
device will no longer belong to the network. Thus, any state related removed, and the device will no longer belong to the network. Thus,
to the EAP peer is removed in the EAP authenticator. Forced removal any state related to the EAP peer is removed in the EAP
can be done by sending new specific key material to the devices that authenticator. Forced removal can be done by sending new specific
still belong to the network, excluding the removed device, following key material to the devices that still belong to the network,
a similar model as 6TiSCH Join Protocol [RFC9031] or Zigbee excluding the removed device, following a model similar to CoJP for
IP[ZigbeeIP]. The specifics on how this process is to be done, is 6TiSCH [RFC9031]. The specifics on how this process is to be done
out of the scope of this document. are outside the scope of this document.
+-------+ +--------+ +--------------+ +-------+ +--------+ +--------------+
| EAP | | CoAP | | EAP | | EAP | | CoAP | | EAP |
| peer |<------>| Proxy |<------------------------->| authenticator| | peer |<------>| proxy |<------------------------->| authenticator|
+-------+ CoAP +--------+ CoAP +--------------+ +-------+ CoAP +--------+ CoAP +--------------+
OSCORE/DTLS OSCORE/DTLS
<--(Security Association)--> <-- security association -->
Figure 10: CoAP-EAP through CoAP proxy Figure 10: CoAP-EAP Through CoAP Proxy
Given that EAP is also used for network access authentication, this Given that EAP is also used for network access authentication, this
service can be adapted to other technologies. For instance, to service can be adapted to other technologies -- for instance, to
provide network access control to very constrained technologies provide network access control to very constrained technologies
(e.g., LoRa network). Authors in [lo-coap-eap] provide a study of a (e.g., Long Range (LoRa) networks). The authors of [LO-CoAP-EAP]
minimal version of CoAP-EAP for LPWAN networks with interesting provide a study of a minimal version of CoAP-EAP for LPWANs, with
results. In this specific case, the compression by SCHC for CoAP interesting results. In this specific case, compression as provided
[RFC8824] can be leveraged. by Static Context Header Compression (SCHC) for CoAP [RFC8824] can be
leveraged.
C.5.2. CoAP-EAP for service authentication C.5.2. CoAP-EAP for Service Authentication
It is not uncommon that the infrastructure where the device is It is not uncommon that the infrastructure where the device is
deployed and the services of the EAP peer are managed by different deployed and the services of the EAP peer are managed by different
organizations. Therefore, in addition to the authentication for organizations. Therefore, in addition to the authentication for
network access control, the possibility of a secondary authentication network access control, the possibility of a secondary authentication
to access different services has to be considered. This process of to access different services has to be considered. This process of
authentication, for example, will provide the necessary key material authentication, for example, will provide the necessary key material
to establish a secure channel and interact with the entity in charge to establish a secure channel and interact with the entity in charge
of granting access to different services. of granting access to different services.
In 5G, for example, consider primary and secondary authentication In 5G, for example, consider primary and secondary authentication
using EAP [TS133.501]. using EAP [TS133.501].
Acknowledgments Acknowledgments
We would like to thank the reviewers of this work: Paul Wouters, We would like to thank the reviewers of this work: Paul Wouters,
Heikki Vatiainen, Josh Howlett, Deb Cooley, Eliot Lear, Alan DeKok, Heikki Vatiainen, Josh Howlett, Deb Cooley, Eliot Lear, Alan DeKok,
Carsten Bormann, Mohit Sethi, Benjamin Kaduk, Christian Amsuss, John Carsten Bormann, Mohit Sethi, Benjamin Kaduk, Christian Amsüss, John
Mattsson, Goran Selander, Alexandre Petrescu, Pedro Moreno-Sanchez Preuß Mattsson, Göran Selander, Alexandre Petrescu, Pedro Moreno-
and Eduardo Ingles-Sanchez. Sanchez, and Eduardo Ingles-Sanchez.
We would also like to thank Gabriel Lopez-Millan for the first review We would also like to thank Gabriel Lopez-Millan for the first review
of this document, and we would like to thank Ivan Jimenez-Sanchez for of this document, Ivan Jimenez-Sanchez for the first proof-of-concept
the first proof-of-concept implementation of this idea, Julian Niklas implementation of this idea, Julian Niklas Schimmelpfennig for the
Schimmelpfennig for the implementation of the Erbium-based IoT device implementation of the Erbium-based IoT device implementation, and
implementation, and Daniel Menendez Gonzalez for the Python Daniel Menendez Gonzalez for the Python implementation.
implementation.
And thank for their valuable comments to Alexander Pelov and Laurent Thanks also to Alexander Pelov and Laurent Toutain for their valuable
Toutain, especially for the potential optimizations of CoAP-EAP. comments, especially regarding the potential optimizations of CoAP-
EAP.
This work was supported in part by Grant PID2020-112675RB-C44 funded This work was supported in part by Grant PID2020-112675RB-C44 funded
by MCIN/AEI/10.13039/5011000011033 (ONOFRE-3-UMU) and in part by the by MCIN/AEI/10.13039/5011000011033 (ONOFRE-3-UMU) and in part by the
H2020 EU project IoTCrawler under contract 779852. H2020 EU project IoTCrawler under contract 779852.
Authors' Addresses Authors' Addresses
Rafa Marin-Lopez Rafa Marin-Lopez
University of Murcia University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science Campus de Espinardo S/N, Faculty of Computer Science
30100 Murcia 30100 Murcia
Spain Spain
Email: rafa@um.es Email: rafa@um.es
Dan Garcia-Carrillo Dan Garcia-Carrillo
University of Oviedo University of Oviedo
Calle Luis Ortiz Berrocal S/N, Edificio Polivalente Calle Luis Ortiz Berrocal S/N, Edificio Polivalente
 End of changes. 300 change blocks. 
971 lines changed or deleted 978 lines changed or added

This html diff was produced by rfcdiff 1.48.