ACE Working Group R. Marin-Lopez
Internet-Draft University of Murcia
Intended status: Standards Track D. Garcia-Carrillo
Expires: 27 January 2022 University of Oviedo
26 July 2021
EAP-based Authentication Service for CoAP
draft-ietf-ace-wg-coap-eap-03
Abstract
This document specifies an authentication service that uses the
Extensible Authentication Protocol (EAP) transported employing
Constrained Application Protocol (CoAP) messages. As such, it
defines an EAP lower-layer based on CoAP called CoAP-EAP. One of the
primer goals is to authenticate a CoAP-enabled device (EAP peer) that
intends to join a security domain managed by a domain Controller (EAP
authenticator). Secondly, it allows deriving key material to protect
CoAP messages exchanged between them based on Object Security for
Constrained RESTful Environments (OSCORE), enabling the establishment
of a security association between them. This document also provides
guidelines on how to generate key material for other types of
security associations.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 27 January 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 1]
Internet-Draft CoAP-EAP July 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. General Architecture . . . . . . . . . . . . . . . . . . . . 4
3. CoAP-EAP Operation . . . . . . . . . . . . . . . . . . . . . 4
3.1. General flow of operation . . . . . . . . . . . . . . . . 4
3.2. Error handling . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Non-responding endpoint . . . . . . . . . . . . . . . 8
3.2.2. Messages with /.well-known/a . . . . . . . . . . . . 8
3.3. Managing the State of the Service . . . . . . . . . . . . 10
3.3.1. Deleting the state . . . . . . . . . . . . . . . . . 10
3.3.2. Reauthentication . . . . . . . . . . . . . . . . . . 11
4. Cryptosuite negotiation and key derivation . . . . . . . . . 11
4.1. Cryptographic suite negotiation . . . . . . . . . . . . . 12
4.2. Deriving the OSCORE Security Context . . . . . . . . . . 14
4.3. Deriving DTLS PSK . . . . . . . . . . . . . . . . . . . . 16
5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. CoAP as EAP lower layer . . . . . . . . . . . . . . . . . 17
5.2. Size of the EAP lower layer vs EAP method size . . . . . 18
5.3. Controller as the CoAP Client . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19
6.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19
6.2. Freshness of the key material . . . . . . . . . . . . . . 19
6.3. Channel Binding support . . . . . . . . . . . . . . . . . 19
6.4. Additional Security Consideration . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Examples of Use Case Scenario . . . . . . . . . . . 23
A.1. Example 1: CoAP-EAP in ACE . . . . . . . . . . . . . . . 24
A.2. Example 2: Multi-domain with AAA infrastructures . . . . 25
A.3. Example 3: Single domain with AAA infrastructure . . . . 26
A.4. Example 4: Single domain without AAA infrastructure . . . 26
A.5. Other use cases . . . . . . . . . . . . . . . . . . . . . 26
A.5.1. CoAP-EAP for network access control . . . . . . . . . 26
A.5.2. CoAP-EAP for service authentication . . . . . . . . . 27
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 2]
Internet-Draft CoAP-EAP July 2021
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
This document specifies an authentication service that uses the
Extensible Authentication Protocol (EAP) [RFC3748] and is built on
top of the Constrained Application Protocol (CoAP) [RFC7252] called
CoAP-EAP. CoAP-EAP allows authenticating two CoAP endpoints by using
EAP, and to establish an OSCORE security association between them.
More specifically, this document specifies how CoAP can be used as a
constrained, link-layer independent, EAP lower layer [RFC3748] to
transport EAP messages between a CoAP server (acting as EAP peer) and
a CoAP client (acting as EAP authenticator) using CoAP messages. The
CoAP client has the option of contacting a backend AAA infrastructure
to complete the EAP negotiation as described in the EAP specification
[RFC3748].
EAP methods transported in CoAP MUST generate cryptographic material
[RFC5247]. This way, CoAP messages are protected after the
authentication. After CoAP-EAP's operation, Object Security for
Constrained RESTful Environments (OSCORE) is established between
endpoints of the service. In addition, using the key material
derived from the authentication, this document specifies how to
establish other types of security associations:
* An OSCORE [RFC8613] security association is established based on
the cryptographic material generated from the EAP authentication.
* A DTLS security association MAY be established using the exported
cryptographic material after a successful EAP authentication.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] [RFC8174]
when, and only when, they appear in all capitals, as shown here.
Readers are expected to be familiar with the terms and concepts of
described in CoAP [RFC7252], EAP [RFC3748]and OSCORE [RFC8613].
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 3]
Internet-Draft CoAP-EAP July 2021
2. General Architecture
Figure 1 illustrates the architecture defined in this document.
Basically, an IoT device, acting as the EAP peer, wants to be
authenticated by using EAP to join a domain that is managed by a
Controller (EAP authenticator). The IoT device will act a CoAP
server for this service, and the EAP authenticator as a CoAP client.
The rationale behind this decision, as expanded later, is that EAP
requests go always from the EAP server to the EAP peer. Accordingly,
the EAP responses go from the EAP peer to the EAP server.
It is worth noting that the CoAP client (EAP authenticator) MAY
interact with a backend AAA infrastructure when EAP pass-through mode
is used, which will place the EAP server in the AAA server that
contains the information required to authenticate the EAP peer.
IoT device Controller
+------------+ +------------+
| EAP peer/ | | EAP auth./ |
| CoAP server|+------+| CoAP client|
+------------+ CoAP +------------+
Figure 1: CoAP-EAP Architecture
3. CoAP-EAP Operation
The sequence flow can be seen in Figure 2. It shows how EAP-X, a
generic EAP method, is used as an authentication mechanism.
(NOTE: any EAP method that exports cryptographic material is valid.
For example, EAP-MD5 cannot be used since it does not export key
material).
3.1. General flow of operation
The first step to run CoAP-EAP is for the IoT device to discover the
Controller, and that it implements the CoAP-EAP service. To do so,
we can rely on any mechanism that allows us to perform this
discovery. For example, the discovery mechanism of CoAP. To access
the authentication service, this document defines the well-known URI
"/.well-known/a" (to be assigned by IANA). This URI is referring to
the authentication service that is present in both the IoT device and
the Controller.
For the rest of this section, the IoT device is referred to as the
EAP peer and the Controller as the EAP authenticator.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 4]
Internet-Draft CoAP-EAP July 2021
In the CoAP-EAP flow of operation, the EAP peer always starts the
authentication process by sending the first message. When the EAP
peer discovers the presence of the EAP authenticator and wants to
start the authentication, it sends a Non-Confirmable "POST /.well-
known/a" request (Step 0). This message will carry the option called
'No-Response' [RFC7967]. The rationale of this option is to avoid
waiting for a response that is not needed. So, the use of this
option will indicate to the EAP authenticator that the EAP peer is
ready to start the authentication process.
This message is the only instance where the EAP authenticator acts as
a CoAP server and the EAP peer as a CoAP client. After this, the
exchange continues with the EAP authenticator as a CoAP client and
the EAP peer as a CoAP server. A discussion about the CoAP roles is
in Section 5.3
Once the EAP authenticator is aware of the intention of the EAP peer
of starting an authentication process, sends a Confirmable "POST
/.well-known/a" request to the EAP peer(Step 1). After receiving the
first POST, the EAP peer (CoAP server) assigns a resource to the
ongoing authentication process, and answers with an Acknowledgment
with a piggybacked response containing the resource identifier in the
Location-Path (and/or Location-Query) Options (Step 2). The path
/.well-known/a at this point will not be used. The name of the
resource is selected by the CoAP server as it pleases. The only
condition is that both end points have to correctly process the
following message based on the selected value. As an example, the
CoAP server MAY follow the the naming "/a/x". Where "a" is the
general name of the authentication service; "x" represents the
resource established to process the following message of the
authentication. This naming, as example, will be used in the figures
of this document. The EAP peer (CoAP server) will only have one
authentication session with that particular EAP authenticator (CoAP
client) and it will not process EAP authentications in parallel (with
the same EAP authenticator) to save resources.
In this exchange (Step 1 and 2), the EAP-Request/Identity (EAP Req/
Id) and EAP-Response/Identity (EAP Resp/Id) messages are exchanged
between the EAP authenticator and the EAP peer. Upon the reception
of the EAP Req/Id message, the EAP authenticator sends this message
to the EAP server. The EAP server is in charge of steering the
conversation, choosing the EAP method to be used (e.g. EAP-X). In
this exchange we can also see the cryptosuite negotiation. If the
cryptosuite is not sent, the default cryptosuite is used. The first
message (Step 1) carries, concatenated to the EAP Req/Id, a CBOR
array containing a list with the cryptosuites, and the CoAP server in
the next message will confirm by sending a choice. The details of
the cryptosuite negotiation are discussed in Section 4.1.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 5]
Internet-Draft CoAP-EAP July 2021
NOTE: Since only an ongoing EAP authentication is permitted per EAP
authenticator and EAP is a lock-step protocol, a CoAP Token of a
constant value can be used throughout the authentication process. An
empty Token MAY be considered to reduce bytes.
From now on, the EAP authenticator and the EAP peer will exchange EAP
packets related to the EAP method, transported in the CoAP message
payload (Steps 3,4,5,6). The EAP authenticator will use the POST
method in a Confirmable message to send EAP requests to the EAP peer.
The EAP peer will use a piggybacked response in the Acknowledgment
message to carry the EAP response. EAP requests and responses are
represented in Figure 2 using the nomenclature (EAP-X-Req n) and
(EAP-X-Resp n) respectively. 'X' indicates the EAP method use. 'n'
indicates the identifier of the EAP message, which is shown
monotonically increasing from 1 in this flow of operation.
When a Confirmable POST message arrives (e.g, /a/x) carrying an EAP
request message, if processed correctly, returns an EAP Response.
Along with the EAP response, a new resource is created (e.g, /a/y)
and the ongoing resource (i.e., /a/x) is erased. This EAP response
will go in a CoAP piggybacked response that will also indicate the
new resource in the Location-Path (and/or Location-Query) Options.
In case there is an error processing a legitimate message, the server
will return an (4.00 Bad Request). There is a discussion about error
handling in Section 3.2.
When the authentication is completed correctly, the EAP server sends
an EAP Success message, and both CoAP endpoints will share a Master
Session Key (MSK)[RFC5295].
Using the MSK, an OSCORE security association is established between
EAP peer and EAP authenticator, which serves as key confirmation of
the MSK and to provide integrity and authentication to the last
exchange (Steps 7 and 8). From that point, any exchange between both
CoAP endpoints is protected with OSCORE. Before sending the EAP
success to the EAP peer, the EAP authenticator can derive the OSCORE
Security Context. The EAP peer can do so when it receives the
message containing the EAP success, and the session liftime, to
verify the message from the EAP authenticator and generate the answer
(Step 8). The establishment of the OSCORE Security Context is
discussed in Section 4.2. The Session Lifetime, in seconds, is
represented with a unsigned integer in a CBOR array. The disposition
of the information is the same to the cryptosuite negotiation () see
Section 4.1).
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 6]
Internet-Draft CoAP-EAP July 2021
EAP peer EAP Auth.
(CoAP server) (CoAP client)
------------- -------------
| NON [0x6af5] POST /.well-known/a |
0) | Token (0xab), No-Response |
|---------------------------------------->|
| CON [0x7654] POST /.well-known/a |
| Token (0xac) |
| Payload (EAP Req/Id||Cryptosuite)|
1) |<----------------------------------------|
| ACK [0x7654] |
| Token (0xac) |
| 2.01 Created Location-Path [/a/x] |
| Payload (EAP Resp/Id||Cryptosuite) |
2) |---------------------------------------->|
| CON [0x8694] POST /a/x |
| Token (0xac) |
| Payload EAP-X-Req 1 |
3) |<----------------------------------------|
| ACK [0x8694] |
| Token (0xac) |
| 2.01 Created Location-Path [/a/y] |
| Payload EAP-X-Resp 1 |
4) |---------------------------------------->|
....
| CON [0x9869] POST /a/y |
| Token (0xac) |
| Payload EAP-X-Req (n) |
5) |<----------------------------------------|
| ACK [0x9869] |
| Token (0xac) |
| 2.01 Created Location-Path [/a/z] | MSK
| Payload EAP-X-Resp (n) | |
6) |---------------------------------------->| v
| CON [0x7811] POST /a/z |OSCORE
| Token (0xac), OSCORE |CONTEXT
MSK | Payload (EAP success||Session-Lifetime) |(*)
| 7) |<----------------------------------------|
v | ACK [0x7811] |
OSCORE (*)| Token (0xac), OSCORE |
CONTEXT 8) |---------------------------------------->|
(*) Protected with OSCORE
Figure 2: CoAP-EAP flow of operation
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 7]
Internet-Draft CoAP-EAP July 2021
3.2. Error handling
This section elaborates how different errors are handled, from a non-
responding endpoint, dealing lost messages and initial POST messages
arriving arriving out of place.
In general, the CoAP engine, in the client and server, will take care
of retransmissions, dealing with lost messages sent out of place, and
sending the errors when a client is trying to access a resource that
does not exist in the CoAP server. But, there are cases where the
messages can arrive out of place, and the CoAP engine may not
recognize them as old or as a retransmission, and send them to the
CoAP application.
3.2.1. Non-responding endpoint
When CoAP-EAP starts, a state is created that stores all information
related to the process. If by any reason one of the entities becomes
non-responding, the state should be only kept form a period of time
before it is removed. According to CoAP, EXCHANGE_LIFETIME considers
the time it takes until a client stops expecting a response to a
Confirmable request. A timer is reseted every time a message is
sent. If EXCHANGE_LIFETIME has passed waiting the next message, both
entities will delete the CoAP-EAP state if the authentication process
has not finished correctly.
3.2.2. Messages with /.well-known/a
The reception of messages containing /.well-known/a needs some
additional considerations, as the resource is always available in
both entities. This message can be sent out of the expected order by
the EAP peer as well as by the EAP authenticator for reasons such as
network delays.
When this message arrives to the other entity during an ongoing
authentication, and it is not recognized by the CoAP engine as an old
or retransmitted message, arriving to the CoAP-EAP application, we
describe the behavior depending on the entity receiving this message.
If this message is from the EAP authenticator to the peer, being a
Confirmable POST message, will honor the request and answer, in this
case with a CoAP Reset message, that will indicate that, since there
is an authentication ongoing, the EAP authenticator is not in
disposition of processing this message. This exchange is illustrated
in Figure 3.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 8]
Internet-Draft CoAP-EAP July 2021
EAP peer EAP Auth.
(CoAP server) . (CoAP client)
------------- . -------------
| |
| CON [0x7654] POST /.well-known/a |
| Token (0xac) |
| Payload (EAP Req/Id||Cryptosuite)|
|<----------------------------------------|
| |
| RST [0x7654] |
| 0.00 Code |
|---------------------------------------->|
Figure 3: /.well-known/a during ongoing authentication from the EAP
authenticator
In case the message goes from the EAP peer to the authenticator,
being a Non-confirmable POST message with the No-Response Option,
there is no need to further process this message, and can be silently
ignored. This exchange is illustrated in Figure 4.
EAP peer EAP Auth.
(CoAP server) . (CoAP client)
------------- . -------------
| |
| NON [0x6af5] POST /.well-known/a |
| Token (0xab), No-Response |
|---------------------------------------->| --+
| . | |
| . | v
(Ignored)
Figure 4: /.well-known/a during ongoing authentication from the
EAP peer
When this message arrives to the CoAP-EAP application, and there is
no authentication ongoing it will understand that a new
authentication process is starting. In case the message goes from
the EAP authenticator to the peer, and no prior Non-confirmable
/.well-known/a message was sent by the EAP peer, it will send a Reset
message indicating that is not in disposition to process this
message, as it has to be the EAP peer the one to initiate the
process. This exchange is illustrated in Figure 5.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 9]
Internet-Draft CoAP-EAP July 2021
EAP peer EAP Auth.
(CoAP server) (CoAP client)
------------- -------------
| |
| CON [0x7654] POST /.well-known/a |
| Token (0xac) |
| Payload (EAP Req/Id||Cryptosuite)|
|<----------------------------------------|
| |
| RST [0x7654] |
| 0.00 Code |
|---------------------------------------->|
Figure 5: /.well-known/a with no ongoing authentication from the EAP
authenticator
If this message is from the EAP peer to the authenticator, receiving
a Non-confirmable /.well-known/a message, it will understand it as
the start of the process by the EAP peer, and start a normal process
of authentication as depicted in the general flow of operation in
Figure 2.
3.3. Managing the State of the Service
The management of the CoAP-EAP state, can be done in different ways.
The Controller MAY choose to delete it as explained in Section 3.3.1.
On the other hand, the IoT device may need to renew the CoAP-EAP
state because the key material is close to expire, as elaborated in
Section 3.3.2.
3.3.1. Deleting the state
There are situations where the current CoAP-EAP state might need to
be removed. For instance due to its expiration or a forced removal
if the IoT device needs to be expelled from the security domain.
This exchange is illustrated in Figure 6. If the Controller, which
implements the CoAP client in this exchange, deems necessary the
removal of the state, it can send a DELETE command to the CoAP
server, referencing the last CoAP-EAP state resource given by the
CoAP server, whose identifier will be the last one received with the
ACK of the EAP success message (/a/z in Figure 2) This message will
be protected with the OSCORE security association to prevent forgery.
Upon reception of this message, the CoAP server sends piggybacked
response to the client with the Code 2.02 Deleted, which is also
protected with the OSCORE security association.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 10]
Internet-Draft CoAP-EAP July 2021
EAP peer EAP Auth.
(CoAP server) (CoAP client)
------------- -------------
| |
| CON [0x7654] DELETE /a/z |
| Token (0xac) |
| OSCORE |
|<----------------------------------------|
| |
| ACK [0x7654] |
| Token (0xac) |
| 2.02 Deleted |
| OSCORE |
|---------------------------------------->|
Figure 6: Deleting state
If the ACK from the CoAP server does not arrive, after the maximum
retransmission attempts, the CoAP client will remove the state from
its side.
3.3.2. Reauthentication
When the CoAP-EAP state is close to expire, the IoT device MAY want
to start a re-authentication process to renew the state. Since the
initial authentication is usually taxing, it is assumed to be done
only once over a long period of time. If further EAP re-
authentications for refreshing the key material are necessary, there
are other methods that can be used to perform these re-
authentications. For example, the EAP re-authentication protocol
(ERP) [RFC6696], EAP-NOOB [I-D.ietf-emu-eap-noob], or EAP-AKA'
[RFC5448] MAY be used to avoid repeating the entire EAP exchange.
The message flow for the reauthentication will be exactly the same as
the one shown in Figure 2, using a more lightweight alternative to do
a re-authentication. While the re-authentication is ongoing, two
different CoAP-EAP states will be active. Once the reauthentication
is completed and OSCORE is exchanged using the newly derived key
material, the old CoAP-EAP state is deleted. If by any reason, the
reauthentication fails to complete, the old CoAP-EAP state will be
available until it expires.
4. Cryptosuite negotiation and key derivation
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 11]
Internet-Draft CoAP-EAP July 2021
4.1. Cryptographic suite negotiation
How the cryptographic suite is selected is important. OSCORE runs
after the EAP authentication, using the cryptosuite selected in the
cryptosuite negotiation. To negotiate the cryptosuite, the protocol
follows a simple approach by sending in the first message from the
Controller, a list in decreasing order or preference, with the
identifiers of the supported cryptosuites. In the response to that
message, the IoT device sends a response with the choice. To do this
without resorting to the creation of a new CoAP option tailored to
this purpose, by leveraging the fact that in the payload it is always
expected at the beginning the EAP message, which by design specifies
its own length. Following the EAP message, optionally there is a
CBOR array that contains the cryptosuites. Be it the list of
cryptosuites supported by the Controller, or the one chosen by the
IoT device. 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
cryptosuite negotiation is shown in Figure 8, where can be
appreciated the disposition of both EAP-Request/Identity and
Response/Identity, followed by the CBOR array. It is worth noting
that the CBOR array is also expected in the EAP Success, containing
the Session Lifetime.
+-----+-----------+-------+------++------------+
|Code |Identifier |Length |Data ||Cyphersuites|
+-----+-----------+-------+------++------------+
EAP Packet CBOR Array
Figure 7: How the cypersuites are sent in the CoAP payload
EAP peer EAP Auth.
(CoAP server) (CoAP client)
------------- -------------
| |
| ... |
|---------------------------------------->|
| CON [0x7654] POST /.well-known/a |
| Token (0xac) |
| Payload (EAP Req/Id, CBORArray[0,1,2]) |
1) |<----------------------------------------|
| ACK [0x7654] |
| Token (0xac) |
| 2.01 Created Location-Path [/a/x] |
| Payload (EAP Resp/Id, CBORArray[0]) |
2) |---------------------------------------->|
...
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 12]
Internet-Draft CoAP-EAP July 2021
Figure 8: Cryptosuite negotition in t CoAP-EAP flow
In case there is no CBOR Array stating the cryptosuites, the default
cryptosuites are applied. If the Controller sends a restricted list
of cryptosuites that is willing to accept, and the ones supported by
the IoT device are not in that list, the IoT device will respond with
a 4.00 Bad Request, expressing in the Payload the cryptosuites
supported. Figure 9 illustrates this exchange.
EAP peer EAP Auth.
(CoAP server) (CoAP client)
------------- -------------
| |
| ... |
|---------------------------------------->|
| CON [0x7654] POST /.well-known/a |
| Token (0xac) |
| Payload (EAP Req/Id, CBORArray[1,2]) |
1) |<----------------------------------------|
| ACK [0x7654] |
| Token (0xac) |
| 4.00 Bad Request |
| Payload (CBORArray[0]) |
2) |---------------------------------------->|
Figure 9: Cryptosuite negotition failed
To avoid a downgrading attack, we will use the proposed cryptosuite
list and the choice in the key derivation process, to bind them to
the generated keys as explained in Section 4.2.
As a result of a successful EAP authentication, both the CoAP server
and CoAP client share a Master Session Key (MSK). The MSK is a fresh
key, so any key derived from the MSK will be also fresh. The CoAP-
EAP exchange finishes with the establishment of an OSCORE security
association for the CoAP-EAP service. The security level for the
CoAP-EAP exchanges with OSCORE is with integrity. Due to the
requirement of using OSCORE, the cryptosuite requirements are
inherited from the ones established by OSCORE. This requires for the
HKDF algorithm by default HKDF SHA-256 and the AEAD algorithm by
default AES-CCM-16-64-128 to be mandatory to implement. The other
cryptosuites supported and negotiated in the cryptosuite negotiation
are, expressed as tuples of AEAD Algorithm and Hash Algorithm, the
following:
0. AES-CCM-16-64-128, SHA-256
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 13]
Internet-Draft CoAP-EAP July 2021
1. A128GCM, SHA-256
2. A256GCM, SHA-384
This specification uses the (HMAC)-based key derivation function
(HKDF) defined in [RFC5869] to derive the necessary key material.
Since the derivation will be done using the MSK, which is considered
fresh key material, we will use the HKDF-Expand function, which we
will shorten here as KDF. In addition to the generation of the
OSCORE parameters, we consider the derivation of a pre-shared key
that can be used for a DTLS security association (DTLS PSK).
4.2. Deriving the OSCORE Security Context
The derivation of the security context for OSCORE has a three
purposes:
* Secure the last two messages of the CoAP-EAP exchange, while
establishing the OSCORE security association
* Perform key confirmation
* Prevent a downgrading attack.
We can achieve this because, after a successful authentication, both
the EAP authenticator and the peer share the MSK. From this MSK,
necessary key material for the OSCORE context is derived. If the
contexts match, both entities confirm they have the same Master
Secret, and therefore they share the same MSK. We prevent a
downgrading attack, by embedding into the derivation process, context
information gathered from the cryptosuite negotiation. To do this,
we concatenate to the label, the content of the cryptosuites
negotiation (which we refer to here as CSO), using the null string
for any part of the negotiation missing. If an attacker changes the
value of the cryptosuite negotiation in any of the messages, the
result will be different security contexts.
Key material needed to derive the OSCORE Security Context, from the
MSK is done as follows:
The Master Secret can be derived by using the chosen cryptosuite and
the KDF. The Master Secret can be derived as follows:
Master Secret = KDF(MSK, CSO | "OSCORE MASTER SECRET", length)
where:
* The algorithms are agreed in the cryptosuite negotiation.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 14]
Internet-Draft CoAP-EAP July 2021
* The MSK exported by the EAP method. Discussion about the use of
the MSK for the key derivation is done in Section 6.
* CSO is the concatenation of the content of the cryptosuite
negotiation, in the request and response. If any of the messages
did not contain the CBOR array, the null string is used.
* "OSCORE MASTER SECRET" is the ASCII code representation of the
non-NULL terminated string (excluding the double quotes around
it).
* CSO and "OSCORE MASTER SECRET" are concatenated.
* length is the size of the output key material.
The Master Salt, similarly to the Master Secret, can be derived as
follows:
Master Salt = KDF(MSK, CSO | "OSCORE MASTER SALT", length)
where:
* The algorithms are agreed in the cryptosuite negotiation.
* The MSK exported by the EAP method. Discussion about the use of
the MSK for the key derivation is done in Section 6.
* CSO is the concatenation of the content of the cryptosuite
negotiation, in the request and response. If any of the messages
did not contain the CBOR array, the null string is used.
* "OSCORE MASTER SALT" is the ASCII code representation of the non-
NULL terminated string (excluding the double quotes around it).
* CSO and "OSCORE MASTER SECRET" are concatenated.
* length is the size of the output key material.
Regarding the Recipient ID and Sender ID, as their purpose is to
serve as identifiers of both entities involved in the exchange, these
identifiers are generated as follows:
Recipient ID = KDF(MSK, "OSCORE RECIPIENT ID", length)
where:
* The algorithms are agreed in the cryptosuite negotiation.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 15]
Internet-Draft CoAP-EAP July 2021
* "OSCORE RECIPIENT ID" is the ASCII code representation of the non-
NULL terminated string (excluding the double quotes around it).
* length is the size of the output. This value will be the maximum
allowed length according to the limits established by OSCORE to
Recipient ID, depending on the chosen cryptographic algorithms
[RFC8613].
For the Sender ID, analogously to the Recipient ID:
Sender ID = KDF(MSK, "OSCORE SENDER ID", length)
where:
* The algorithms are agreed in the cryptosuite negotiation.
* "OSCORE RECIPIENT ID" is the ASCII code representation of the non-
NULL terminated string (excluding the double quotes around it).
* length is the size of the output. The maximum value allowed is
established by OSCORE to Sender ID, depending on the chosen
cryptographic algorithms.
4.3. Deriving DTLS PSK
It is also possible to derive a pre-shared key for DTLS [RFC6347],
refereed to here as "DTLS PSK", from the MSK between both CoAP
endpoints if required. The length of the DTLS PSK will depend on the
cryptosuite. To have a cryptographic material with sufficient length
we will derive a key of 32 bytes that can be later truncated if
needed:
DTLS PSK = KDF(MSK, "DTLS PSK", length).
where:
* MSK is exported by the EAP method.
* "DTLS PSK" is the ASCII code representation of the non-NULL
terminated string (excluding the double quotes around it).
* length is the size of the output key material.
5. Discussion
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 16]
Internet-Draft CoAP-EAP July 2021
5.1. CoAP as EAP lower layer
This section discusses the suitability of the CoAP protocol as EAP
lower layer, and reviews the requisites imposed by the EAP protocol
to any protocol that transports EAP. What EAP expects from its lower
layers can be found in section 3.1 of [RFC3748], which is elaborated
next:
Unreliable transport. EAP does not assume that lower layers are
reliable. CoAP provides a reliability mechanism through the use of
Confirmable messages.
Lower layer error detection. EAP relies on lower layer error
detection (e.g., CRC, Checksum, MIC, etc.). CoAP goes on top of UDP
which provides a checksum mechanism over its payload.
Lower layer security. EAP does not require security services from
the lower layers.
Minimum MTU. Lower layers need to provide an EAP MTU size of 1020
octets or greater. CoAP assumes an upper bound of 1024 for its
payload which covers the requirements of EAP.
Ordering guarantees. EAP relies on lower layer ordering guarantees
for correct operation. Regarding message ordering, every time a new
message arrives at the authentication service hosted by the IoT
device, a new resource is created and this is indicated in a 2.01
Created response code along with the name of the new resource via
Location-Path or Location-Query. This way the application indicates
that its state has advanced. Although the [RFC3748] states: "EAP
provides its own support for duplicate elimination and
retransmission", EAP is also reliant on lower layer ordering
guarantees. In this regard, the RFC talks about possible duplication
and says: "Where the lower layer is reliable, it will provide the EAP
layer with a non-duplicated stream of packets. However, while it is
desirable that lower layers provide for non-duplication, this is not
a requirement". CoAP is providing a non-duplicated stream of packets
and accomplish the "desirable" non-duplication. In addition,
[RFC3748] says that when EAP runs over a reliable lower layer "the
authenticator retransmission timer SHOULD be set to an infinite
value, so that retransmissions do not occur at the EAP layer."
NOTE: This document does not assume any specific naming schema. The
only requisite that both CoAP client and server MUST agree, is the
establishment of a nomenclature indicates that the next URI used to
refer to a resource, univocally points to the next expected EAP
exchange.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 17]
Internet-Draft CoAP-EAP July 2021
Regarding the CoAP Token, CoAP-EAP will use one of a constant value
throughout an authentication. This is because the EAP server will
not send a new EAP request until it has processed the expected EAP
response. Additionally, there will be a single EAP authentication
between the IoT device and the same Controller. This would also
enable the possibility of using an Empty Token to reduce the number
of bytes.
As we can see, CoAP can fulfill the requirements of EAP to be
considered suitable as lower layer.
5.2. Size of the EAP lower layer vs EAP method size
Regarding the impact an EAP lower layer will have to the total byte
size of the whole exchange, there is a comparison with another
network layer based EAP lower layer, PANA [RFC5191] in [coap-eap].
Comparing the EAP lower layer (alone) and taking into account EAP.
On the one hand, at the EAP lower layer level, the usage of CoAP
gives important benefits. On the other hand, when taking into
account the EAP method overload, this reduction is less but still
significant if the EAP method is lightweight (authors of [coap-eap]
used EAP-PSK as a representative of a lightweight EAP method). If
the EAP method is very taxing, the impact of the reduction in size of
the EAP lower layer is less significant. This leads to the
conclusion that possible next steps in this field could be designing
new EAP methods that can be better adapted to the requirements of IoT
devices and networks.
However, the impact of the EAP lower layer itself cannot be ignored,
hence the proposal of using CoAP as lightweight protocol for this
purpose. Other EAP methods such as EAP-AKA'[RFC5448] or new
lightweight EAP methods such as EAP-NOOB [I-D.ietf-emu-eap-noob] or
EAP-EDHOC [I-D.ingles-eap-edhoc] that can benefit from a CoAP-based
EAP lower layer, as well as new ones that may be proposed in the
future with IoT constraints in mind.
5.3. Controller as the CoAP Client
In general, it is assumed that, since the EAP authenticator
(Controller) MAY implement an AAA client to interact with the AAA
infrastructure. Hence, this endpoint will have more resources or, at
least, will not be a so constrained device. Due to the constrained
capacities of IoT devices, to relieve them of the retransmission
tasks, the Controller is set as the CoAP client, for the main
exchange following the recommendations of the [I-D.ietf-lwig-coap]
document to simplify the IoT device implementation.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 18]
Internet-Draft CoAP-EAP July 2021
6. Security Considerations
There are some aspects to be considered such as how authorization is
managed, the use of MSK as keying material and how the trust in the
Controller is established. Additional considerations such as EAP
channel binding as per [RFC6677] are also discussed here.
6.1. Authorization
Authorization is part of bootstrapping. It serves to establish
whether the node can join and the set of conditions it has to adhere.
The authorization data will be gathered from the organization that is
responsible for the IoT device and sent to the EAP authenticator. In
standalone mode, the authorization information will be in the
Controller. If the pass-through mode is used, authorization data
received from the AAA server can be delivered by the AAA protocol
(e.g. Diameter). Providing more fine-grained authorization data can
be with the transport of SAML in RADIUS [RFC7833]. After
bootstrapping, additional authorization information to operate in the
security domain, e.g., access services offered by other nodes, can be
taken care of by the solutions proposed in the ACE WG.
6.2. Freshness of the key material
In CoAP-EAP there is no nonce exchange to provide freshness to the
keys derived from the MSK. The MSK and Extended Master Session Key
(EMSK) keys according to the EAP Key Management Framework [RFC5247]
are fresh key material. Since only one authentication is established
per EAP authenticator, there is no need for generating additional key
material. In case another authentication to be established, a re-
authentication can be done, by running the process again, or using a
more lightweight EAP method to derive additional key material as
elaborated in Section 3.3.2.
6.3. Channel Binding support
According to the [RFC6677], channel binding related with EAP, is sent
through the EAP method that supports it.
To satisfy the requirements of the document, we need to send the EAP
lower layer identifier (To be assigned by IANA), in the EAP Lower-
Layer Attribute if RADIUS is used.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 19]
Internet-Draft CoAP-EAP July 2021
6.4. Additional Security Consideration
Other security-related concerns can be how to ensure that the node
joining the security domain can in fact trust the Controller. This
issue is elaborated in the EAP Key Management Framework [RFC5247].
In particular, the constrained node knows it can trust the Controller
because the key that is used to establish the security association is
derived from the MSK. If the Controller has the MSK, it is clear the
AAA Server of the node trusted the Controller, which can be
considered as a trusted party.
7. IANA Considerations
Considerations for IANA regarding this document:
* Assignment of EAP lower layer identifier.
* Assignment of the URI /.well-known/a
8. Acknowledgments
We would like to thank as the reviewers of this work: Carsten
Bormann, Mohit Sethi, Benjamin Kaduk, Alexandre Petrescu, Pedro
Moreno-Sanchez and Eduardo Ingles-Sanchez.
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
the first proof-of-concept implementation of this idea.
And thank for their valuables comments to Alexander Pelov and Laurent
Toutain, especially for the potential optimizations of CoAP-EAP.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 20]
Internet-Draft CoAP-EAP July 2021
[RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible
Authentication Protocol (EAP) Key Management Framework",
RFC 5247, DOI 10.17487/RFC5247, August 2008,
<https://www.rfc-editor.org/info/rfc5247>.
[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation of Root Keys from an
Extended Master Session Key (EMSK)", RFC 5295,
DOI 10.17487/RFC5295, August 2008,
<https://www.rfc-editor.org/info/rfc5295>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
[RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel-
Binding Support for Extensible Authentication Protocol
(EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012,
<https://www.rfc-editor.org/info/rfc6677>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>.
[RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T.
Bose, "Constrained Application Protocol (CoAP) Option for
No Server Response", RFC 7967, DOI 10.17487/RFC7967,
August 2016, <https://www.rfc-editor.org/info/rfc7967>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019,
<https://www.rfc-editor.org/info/rfc8613>.
9.2. Informative References
[coap-eap] Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP-
Based Bootstrapping Service for the Internet of Things -
https://www.mdpi.com/1424-8220/16/3/358", March 2016.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 21]
Internet-Draft CoAP-EAP July 2021
[I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE) using the OAuth 2.0
Framework (ACE-OAuth)", Work in Progress, Internet-Draft,
draft-ietf-ace-oauth-authz-36, 16 November 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-ace-oauth-
authz-36.txt>.
[I-D.ietf-emu-eap-noob]
Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band
authentication for EAP (EAP-NOOB)", Work in Progress,
Internet-Draft, draft-ietf-emu-eap-noob-05, 12 July 2021,
<https://www.ietf.org/archive/id/draft-ietf-emu-eap-noob-
05.txt>.
[I-D.ietf-lwig-coap]
Kovatsch, M., Bergmann, O., and C. Bormann, "CoAP
Implementation Guidance", Work in Progress, Internet-
Draft, draft-ietf-lwig-coap-06, 2 July 2018,
<http://www.ietf.org/internet-drafts/draft-ietf-lwig-coap-
06.txt>.
[I-D.ingles-eap-edhoc]
Sanchez, E., Garcia-Carrillo, D., and R. Marin-Lopez, "EAP
method based on EDHOC Authentication", Work in Progress,
Internet-Draft, draft-ingles-eap-edhoc-01, 2 November
2020, <https://www.ietf.org/internet-drafts/draft-ingles-
eap-edhoc-01.txt>.
[lo-coap-eap]
Garcia-Carrillo, D., Marin-Lopez, R., Kandasamy, A., and
A. Pelov, "A CoAP-Based Network Access Authentication
Service for Low-Power Wide Area Networks: LO-CoAP-EAP -
https://www.mdpi.com/1424-8220/17/11/2646", November 2017.
[RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A
Pre-Shared Key Extensible Authentication Protocol (EAP)
Method", RFC 4764, DOI 10.17487/RFC4764, January 2007,
<https://www.rfc-editor.org/info/rfc4764>.
[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
and A. Yegin, "Protocol for Carrying Authentication for
Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
May 2008, <https://www.rfc-editor.org/info/rfc5191>.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 22]
Internet-Draft CoAP-EAP July 2021
[RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved
Extensible Authentication Protocol Method for 3rd
Generation Authentication and Key Agreement (EAP-AKA')",
RFC 5448, DOI 10.17487/RFC5448, May 2009,
<https://www.rfc-editor.org/info/rfc5448>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed.,
"EAP Extensions for the EAP Re-authentication Protocol
(ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012,
<https://www.rfc-editor.org/info/rfc6696>.
[RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A
RADIUS Attribute, Binding, Profiles, Name Identifier
Format, and Confirmation Methods for the Security
Assertion Markup Language (SAML)", RFC 7833,
DOI 10.17487/RFC7833, May 2016,
<https://www.rfc-editor.org/info/rfc7833>.
[RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static
Context Header Compression (SCHC) for the Constrained
Application Protocol (CoAP)", RFC 8824,
DOI 10.17487/RFC8824, June 2021,
<https://www.rfc-editor.org/info/rfc8824>.
[TS133.501]
ETSI, "5G; Security architecture and procedures for 5G
System - TS 133 501 V15.2.0 (2018-10)", 2018.
Appendix A. Examples of Use Case Scenario
For a IoT device to act as a trustworthy entity within a security
domain, certain key material is needed to be shared between the IoT
device and the Controller.
Next, we elaborate on examples of different use case scenarios about
the usage of CoAP-EAP. Generally, we are dealing with 4 entities:
* 2 nodes (A and B), which are IoT devices. They are the EAP peers.
* 1 controller (C). The controller manages a domain where nodes can
be deployed. It can be considered a more powerful machine than
the IoT devices.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 23]
Internet-Draft CoAP-EAP July 2021
* 1 AAA server (AAA) - Optional. The AAA is an Authentication,
Authorization and Accounting Server, which is not constrained.
Here, the Controller acts as EAP authenticator in pass-through
mode.
Generally, any IoT device wanting to join the domain managed by the
Controller MUST perform a CoAP-EAP authentication with the Controller
(C). This authentication MAY involve an external AAA server. This
means that A and B, once deployed, will run CoAP-EAP once, as a
bootstrapping phase, to establish a security association with C.
Moreover, any other entity, which wants to join and establish
communications with nodes under C's domain must also do the same. By
using EAP, we can have the flexibility of having different types of
credentials. For instance, if we have a device that is not battery
dependent, and not very constrained, we could use a heavier
authentication method. With varied IoT devices and networks we might
need to resort to more lightweight authentication methods (e.g., EAP-
NOOB[I-D.ietf-emu-eap-noob], EAP-AKA'[RFC5448], EAP-PSK[RFC4764],
EAP-EDHOC[I-D.ingles-eap-edhoc], etc.) being able to adapt to
different types of devices according to organization policies or
devices capabilities.
A.1. Example 1: CoAP-EAP in ACE
In ACE, the process of Client registration and provisioning of
credentials to the client is not specified. The process of Client
registration and provisioning can be achieved using CoAP-EAP. Once
the process of authentication with EAP is completed, fresh key
material is shared between the IoT device and the Controller. In
this instance, the Controller and the Authorization Server (AS) of
ACE can be co-located.
Next, we exemplify how CoAP-EAP can be used to perform the Client
registration in a general way, to allow two IoT devices (A and B) to
communicate and interact after a successful client registration.
Node A wants to communicate with node B (e.g. to activate a light
switch). The overall process is divided into three phases. Let's
start with node A. In the first phase, the node A (EAP peer) does
not yet belong to Controller C's domain. Then, it communicates with
C (EAP authenticator) 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 node A. This key material allows node A
to establish a security association with the C. Some authorization
information may be also provided in this step. In case EAP is used
in standalone mode, the AS itself having information about the
devices can be the entity providing said authorization information.
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 24]
Internet-Draft CoAP-EAP July 2021
If authentication and authorization are correct, node A is enrolled
in controller C's domain for a period of time. In particular,
[RFC5247] recommends 8 hours, though the the entity providing the
authorization information can establish this lifetime. In the same
manner, B needs to perform the same process with CoAP-EAP to be part
of the controller C's domain.
In the second phase, when node A wants to talk with node B, it
contacts controller C for authorization to access node B and obtain
all the required information to do that securely (e.g. keys, tokens,
authorization information, etc.). This phase does NOT require the
usage of CoAP-EAP. The details of this phase are out of the scope of
this document, and the ACE framework is used for this purpose
[I-D.ietf-ace-oauth-authz].
In the third phase, the node A can access node B with the credentials
and information obtained from the controller C in the second phase.
This access can be repeated without contacting the controller, while
the credentials given to A are still valid. The details of this
phase are out of scope of this document.
It is worth noting that first phase with CoAP-EAP is required to join
the controller C's domain. Once it is performed with success, the
communications are local to the controller 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 IoT device
can engage in a reauthentication as explained in Section 3.3.2, to
renew the key material.
A.2. Example 2: Multi-domain with AAA infrastructures
We assume we have a device (A) of the domain acme.org, which uses a
specific kind of credential (e.g., AKA) and intends to join the um.es
domain. This user does not belong to this domain, for which first it
performs a client registration using CoAP-EAP. For this, it
interacts with the controller's domain acting as EAP authenticator,
which in turn communicates with a AAA infrastructure (acting as AAA
client). Through the local AAA server to communicate with the home
AAA server to complete the authentication and integrate the device as
a trustworthy entity into the domain of controller C. In this
scenario, the AS under the role of the Controller receives the key
material from the AAA infrastructure
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 25]
Internet-Draft CoAP-EAP July 2021
A.3. Example 3: Single domain with AAA infrastructure
A University Campus, we have several Faculty buildings and each one
has its own criteria or policies in place to manage IoT devices 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 a Controller (C) of any building
as long as they are managed by the same general domain.
A.4. Example 4: Single domain without AAA infrastructure
In another case, without a AAA infrastructure, we have a Controller
that has co-located the EAP server and using EAP standalone mode we
can manage all the devices within the same domain locally. Client
registration of a node (A) with Controller (C) can also be performed
in the same manner.
A.5. Other use cases
A.5.1. CoAP-EAP for network access control
One of the first steps for an IoT device life-cycle is to perform the
authentication to gain access to the network. To do so, the device
first has to be authenticated and granted authorization to gain
access to the network. Additionally, security parameters such as
credentials can be derived from the authentication process allowing
the trustworthy operation of the IoT device in a particular network
by joining the security domain. By using EAP, we are able to achieve
this with flexibility and scalability, because of the different EAP
methods available and the ability to rely on AAA infrastructures if
needed to support multi-domain scenarios, which is a key feature when
the IoT devices deployed under the same security domain, belong to
different organizations. Given that EAP is also used for network
access control, we can adapt this service for other technologies.
For instance, to provide network access control to very constrained
technologies (e.g., LoRa network). Authors in [lo-coap-eap] provide
an study of a minimal version of CoAP-EAP for LPWAN networks with
interesting results. In this specific case, we could leverage the
compression by SCHC for CoAP [RFC8824].
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 26]
Internet-Draft CoAP-EAP July 2021
A.5.2. CoAP-EAP for service authentication
It is not uncommon that the infrastructure where the device is
deployed and the services of the IoT device are managed by different
organizations. Therefore, in addition to the authentication for
network access control, we have to consider the possibility of a
secondary authentication to access different services. This process
of authentication, for example, will provide with the necessary key
material to establish a secure channel and interact with the entity
in charge of granting access to different services. In 5G, for
example, consider a primary and secondary authentication using EAP
[TS133.501].
Authors' Addresses
Rafa Marin-Lopez
University of Murcia
Campus de Espinardo S/N, Faculty of Computer Science
30100 Murcia
Spain
Phone: +34 868 88 85 01
Email: rafa@um.es
Dan Garcia-Carrillo
University of Oviedo
Calle Luis Ortiz Berrocal S/N, Edificio Polivalente
33203 Gijon Asturias
Spain
Email: garciadan@uniovi.es
Marin-Lopez & Garcia-CarrExpires 27 January 2022 [Page 27]