idnits 2.17.00 (12 Aug 2021) /tmp/idnits43799/draft-ietf-ace-wg-coap-eap-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 December 2021) is 158 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 633 -- Looks like a reference, but probably isn't: '1' on line 630 -- Looks like a reference, but probably isn't: '2' on line 630 ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 7967 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-36 == Outdated reference: draft-ietf-core-resource-directory has been published as RFC 9176 == Outdated reference: draft-ietf-emu-eap-noob has been published as RFC 9140 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group R. Marin-Lopez 3 Internet-Draft University of Murcia 4 Intended status: Standards Track D. Garcia-Carrillo 5 Expires: 10 June 2022 University of Oviedo 6 7 December 2021 8 EAP-based Authentication Service for CoAP 9 draft-ietf-ace-wg-coap-eap-06 11 Abstract 13 This document specifies an authentication service that uses the 14 Extensible Authentication Protocol (EAP) transported employing 15 Constrained Application Protocol (CoAP) messages. As such, it 16 defines an EAP lower layer based on CoAP called CoAP-EAP. One of the 17 main goals is to authenticate a CoAP-enabled IoT device (EAP peer) 18 that intends to join a security domain managed by a Controller (EAP 19 authenticator). Secondly, it allows deriving key material to protect 20 CoAP messages exchanged between them based on Object Security for 21 Constrained RESTful Environments (OSCORE), enabling the establishment 22 of a security association between them. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on 10 June 2022. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Revised BSD License text as 52 described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Revised BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. General Architecture . . . . . . . . . . . . . . . . . . . . 4 60 3. CoAP-EAP Operation . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. Flow of operation (OSCORE establishment) . . . . . . . . 6 63 3.3. Reauthentication . . . . . . . . . . . . . . . . . . . . 9 64 3.4. Managing the State of the Service . . . . . . . . . . . . 10 65 3.5. Error handling . . . . . . . . . . . . . . . . . . . . . 11 66 3.5.1. EAP authentication failure . . . . . . . . . . . . . 11 67 3.5.2. Non-responding endpoint . . . . . . . . . . . . . . . 12 68 3.5.3. Duplicated message with /.well-known/coap-eap . . . . 12 69 3.6. Proxy operation in CoAP-EAP . . . . . . . . . . . . . . . 13 70 4. CBOR Objects in CoAP-EAP . . . . . . . . . . . . . . . . . . 13 71 5. Cipher suite negotiation and key derivation . . . . . . . . . 14 72 5.1. Cipher suite negotiation . . . . . . . . . . . . . . . . 14 73 5.2. Deriving the OSCORE Security Context . . . . . . . . . . 16 74 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 17 75 6.1. CoAP as EAP lower layer . . . . . . . . . . . . . . . . . 17 76 6.2. Size of the EAP lower layer vs EAP method size . . . . . 18 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 78 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 79 7.2. Freshness of the key material . . . . . . . . . . . . . . 19 80 7.3. Channel Binding support . . . . . . . . . . . . . . . . . 19 81 7.4. Additional Security Consideration . . . . . . . . . . . . 20 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 86 10.2. Informative References . . . . . . . . . . . . . . . . . 22 87 Appendix A. Flow of operation (DTLS establishment) . . . . . . . 25 88 A.1. Cryptographic suite negotiation for DTLS . . . . . . . . 26 89 A.2. Deriving DTLS PSK and identity . . . . . . . . . . . . . 26 90 Appendix B. Examples of Use Case Scenario . . . . . . . . . . . 27 91 B.1. Example 1: CoAP-EAP in ACE . . . . . . . . . . . . . . . 28 92 B.2. Example 2: Multi-domain with AAA infrastructures . . . . 29 93 B.3. Example 3: Single domain with AAA infrastructure . . . . 29 94 B.4. Example 4: Single domain without AAA infrastructure . . . 29 95 B.5. Other use cases . . . . . . . . . . . . . . . . . . . . . 29 96 B.5.1. CoAP-EAP for network access control . . . . . . . . . 30 97 B.5.2. CoAP-EAP for service authentication . . . . . . . . . 30 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 100 1. Introduction 102 This document specifies an authentication service (application) that 103 uses the Extensible Authentication Protocol (EAP) [RFC3748] and is 104 built on top of the Constrained Application Protocol (CoAP) [RFC7252] 105 called CoAP-EAP. CoAP-EAP is an application that allows 106 authenticating two CoAP endpoints by using EAP, and to establish an 107 Object Security for Constrained RESTful Environments (OSCORE) 108 security association between them. 110 More specifically, this document specifies how CoAP can be used as a 111 constrained, link-layer independent, reliable EAP lower layer 112 [RFC3748] to transport EAP messages between a CoAP server (acting as 113 EAP peer) and a CoAP client (acting as EAP authenticator) using CoAP 114 messages. The CoAP client has the option of contacting a backend AAA 115 infrastructure to complete the EAP negotiation as described in the 116 EAP specification [RFC3748]. 118 EAP methods transported in CoAP MUST generate cryptographic material 119 [RFC5247] for this specification. This way, CoAP messages are 120 protected after the authentication. After CoAP-EAP's operation, an 121 OSCORE security association is established between endpoints of the 122 service. Using the keying material derived from the authentication, 123 other security associations could be generated. Appendix A shows how 124 to establish a (D)TLS security association using the keying material 125 from the EAP authentication. 127 1.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119] [RFC8174] 132 when, and only when, they appear in all capitals, as shown here. 134 Readers are expected to be familiar with the terms and concepts of 135 described in CoAP [RFC7252], EAP [RFC3748][RFC5247] and OSCORE 136 [RFC8613]. 138 2. General Architecture 140 Figure 1 illustrates the architecture defined in this document. 141 Basically, an IoT device, acting as the EAP peer, wants to be 142 authenticated by using EAP to join a domain that is managed by a 143 Controller acting as EAP authenticator. The IoT device will act a 144 CoAP server for this service, and the EAP authenticator as a CoAP 145 client. The rationale behind this decision, as expanded later, is 146 that EAP requests go always from the EAP server to the EAP peer. 147 Accordingly, the EAP responses go from the EAP peer to the EAP 148 server. 150 It is worth noting that the CoAP client (EAP authenticator) MAY 151 interact with a backend AAA infrastructure when EAP pass-through mode 152 is used, which will place the EAP server in the AAA server that 153 contains the information required to authenticate the EAP peer. 155 The protocol stack is described in Figure 2. CoAP-EAP is an 156 application built on top of CoAP. On top of the application, there 157 is an EAP state machine that can run any EAP method. For this 158 specification, the EAP method MUST be able to derive keying material. 159 CoAP-EAP also relies on CoAP reliability mechanisms in CoAP to 160 transport EAP: CoAP over UDP with Confirmable messages ([RFC7252]) or 161 CoAP over TCP, TLS and Websocket, which is specified in [RFC8323]. 163 +----------+ +--------------+ +----------+ 164 | EAP peer | | EAP | | AAA/ | 165 | peer |<------>| authenticator|<---------->|EAP Server| 166 +----------+ CoAP +--------------+ AAA +----------+ 167 (Optional) 168 <---(SCOPE OF THIS DOCUMENT)----> 170 Figure 1: CoAP-EAP Architecture 172 +-------------------------------+ 173 | EAP State Machine | 174 +-------------------------------+ \ 175 | Application(CoAP-EAP) | | This Document 176 +-------------------------------+ / 177 | Request/Responses/Signaling | RFC 7252 / RFC 8323 178 +-------------------------------+ 179 | Message / Message Framing | RFC 7252 / RFC 8323 180 +-------------------------------+ 181 |Unreliable / Reliable Transport| RFC 7252 / RFC 8323 182 +-------------------------------+ 184 Figure 2: CoAP-EAP Stack 186 3. CoAP-EAP Operation 188 Since CoAP-EAP uses reliable delivery in CoAP ([RFC7252], [RFC8323]), 189 EAP retransmission time is set to infinite as mentioned in [RFC3748]. 190 To keep ordering guarantee, CoAP-EAP uses Hypermedia as the Engine of 191 Application State (HATEOAS). Each step during the EAP authentication 192 is represented as a new resource in the EAP peer (CoAP server). The 193 previous resource is removed once the new resource is created 194 indicating the resource that will process the next expected step of 195 the EAP authentication. 197 An EAP method that does not export keying material MUST NOT be used. 198 One of the benefits of using EAP is that we can choose over a large 199 variety of authentication methods. Although for IoT, where we can 200 find very constrained links (e.g., limited bandwidth) and devices 201 with limited capabilities, EAP methods that do not require many 202 exchanges, with short messages, and that use cryptographic algorithms 203 that are manageable by constrained devices are preferable. 205 In CoAP-EAP, the IoT device (EAP peer/CoAP server) will only have one 206 authentication session with a specific Controller (EAP authenticator/ 207 CoAP client) and it will not process any other EAP authentication in 208 parallel (with the same Controller). That is, a single ongoing EAP 209 authentication is permitted for the same IoT device and same 210 Controller. Moreover, EAP is a lock-step protocol ([RFC3748]). The 211 benefits of the EAP framework in IoT are highlighted in 212 [eap-framework]. 214 To access the authentication service, this document defines the well- 215 known URI "/.well-known/coap-eap" (to be assigned by IANA). This URI 216 is referring to the authentication service that is present in the 217 Controller so that IoT device can start the service. 219 3.1. Discovery 221 Prior to the CoAP-EAP exchange takes place, the IoT device needs to 222 discovers the Controller or the entity that will enable the exchange 223 between the IoT and the Controller (e.g., an intermediary such as a 224 proxy). 226 The discovery process is out of the scope of this document. This 227 document provides the specification using the mechanisms provided by 228 CoAP to discover the Controller for CoAP-EAP. 230 The CoAP-EAP application is designated by the well-known URI "coap- 231 eap" for the trigger message (Step 0). The CoAP-EAP service can be 232 discovered by asking directly about the services offered. This 233 information can be also available in the resource directory 234 [I-D.ietf-core-resource-directory]. 236 Implementation Notes: On the methods on how the IPv6 address of the 237 Controller or intermediary entity can be discovered, there can be 238 different methods depending on the specific deployment. For example, 239 on a 6LoWPAN network, the Border Router will typically act as the 240 Controller hence, after receiving the Router Advertisement (RA) 241 messages from the Border Router, the IoT device may engage on the 242 CoAP-EAP exchange. Different protocols can be used to discover the 243 IP of the Controller. Examples of such protocols are Multicast DNS 244 (mDNS) [RFC6762] or DHCPv6 [RFC8415]. 246 3.2. Flow of operation (OSCORE establishment) 248 Figure 3 shows the general flow of operation for CoAP-EAP to 249 authenticate using EAP and establish an OSCORE security context. The 250 flow does not show a specific EAP method. Instead, we represent the 251 chosen EAP method by using a generic name (EAP-X). The flow assumes 252 that the IoT device knows the Controller implements the CoAP-EAP 253 service. The specific mechanism of discovery is out-of-scope of this 254 document. Some comments about Controller discovery is in 255 Section 3.1. 257 The steps for the operation happens as follows: 259 * Step 0. The IoT device MUST start the authentication process by 260 sending a "POST /.well-known/coap-eap" request (trigger message). 261 This message carries the 'No-Response' [RFC7967] CoAP option to 262 avoid waiting for a response that is not needed. This message is 263 the only instance where the Controller acts as a CoAP server and 264 the IoT device as a CoAP client. The message also includes a URI 265 in the payload of the message to indicate to what resource (e.g. 266 '/a/x') the Controller MUST send the first message with the EAP 267 authentication. The name of the resource is selected by the CoAP 268 server as it pleases. After this, the exchange continues with the 269 Controller as a CoAP client and the IoT device as a CoAP server. 271 * Step 1. The Controller sends a "POST" message to the resource 272 indicated by the IoT device in the Step 0 (e.g., '/a/x'). The 273 payload in this message contains the first EAP message (EAP 274 Request/Identity), the Recipient ID of the Controller (RID-C) for 275 OSCORE and it MAY contain a CBOR array containing a list with the 276 cipher suites (CS) for OSCORE. If the cipher suite is not 277 included the default cipher suite for OSCORE is used. The details 278 of the cipher suite negotiation are discussed in Section 5.1. 280 * Step 2. The IoT device processes the POST message by passing the 281 EAP request (EAP-Req/Id) to the EAP peer state machine, which 282 returns an EAP response (EAP Resp/Id); it assigns a new resource 283 to the ongoing authentication process (e.g., '/a/y'), and deletes 284 the previous one ('/a/x'). It finally sends a '2.01 Created' 285 response with the new resource identifier in the Location-Path 286 (and/or Location-Query) options for the next step; the EAP 287 response, the Recipient ID of the IoT device (RID-I) and the 288 selected cipher suite for OSCORE are in the payload. In this 289 step, the IoT device MAY create a OSCORE security context (see 290 Section 5.2). The required key, the Master Session Key (MSK), 291 will be available once the EAP authentication is successful in 292 step 7. 294 * Step 3-6. From now on, the Controller and the IoT device will 295 exchange EAP packets related to the EAP method (EAP-X), 296 transported in the CoAP message payload. The Controller will use 297 the POST method to send EAP requests to the IoT device. The IoT 298 device will use a response to carry the EAP response in the 299 payload. EAP requests and responses are represented in Figure 3 300 using the nomenclature (EAP-X-Req and EAP-X-Resp, respectively. 301 When a POST message arrives (e.g, '/a/x') carrying an EAP request 302 message, if processed correctly by the EAP peer state machine, 303 returns an EAP Response. Along with each EAP Response, a new 304 resource is created (e.g, '/a/z') for processing the next EAP 305 request and the ongoing resource (e.g., '/a/y') is erased. This 306 way ordering guarantee is achieved. Finally, EAP response is sent 307 in the payload of a CoAP response that will also indicate the new 308 resource in the Location-Path (and/or Location-Query) Options. In 309 case there is an error processing a legitimate message, the server 310 will return a (4.00 Bad Request). There is a discussion about 311 error handling in Section 3.5. 313 * Step 7. When the EAP authentication ends with success, the 314 Controller obtains the Master Session Key (MSK) exported by the 315 EAP method, an EAP Success message and some authorization 316 information (i.e. session lifetime) [RFC5247]. The Controller 317 creates the OSCORE security context using the MSK and Sender ID 318 and Recipient ID exchanged in Step 1 and 2. The establishment of 319 the OSCORE Security Context is defined in Section 5.2. Then, the 320 Controller sends the POST message protected with OSCORE for key 321 confirmation including the EAP Success. The Controller MAY also 322 send a Session Lifetime, in seconds, which is represented with an 323 unsigned integer in a CBOR object (see Section 4. If this Session 324 Lifetime is not sent, the IoT device assumes a default value of 8 325 hours as RECOMMENDED in [RFC5247]. The verification of the 326 received OSCORE protected "POST" message using RID-I (Recipient ID 327 of the IoT device) sent in Step 2 is considered by the IoT device 328 as an alternate indication of success ([RFC3748]). The EAP peer 329 state machine in the IoT device interprets the alternate 330 indication of success similarly the arrival of an EAP Success and 331 returns the MSK, which is used for the OSCORE security context in 332 the IoT device to process the protected POST message received from 333 the Controller. 335 * Step 8. If the EAP authentication and the verification of the 336 OSCORE protected "POST" in Step 7 is successful, then the IoT 337 Device answers with an OSCORE protected '2.04 Changed'. From this 338 point on, the communication with the last resource (e.g. '/a/w') 339 MUST be protected with OSCORE. If allowed by application policy, 340 same OSCORE security context MAY be used to protect communication 341 to other resources between the same endpoints. 343 IoT device Controller 344 ------------- ------------ 345 | POST /.well-known/coap-eap | 346 0) | No-Response | 347 | Payload("/a/x") | 348 |---------------------------------------->| 349 | POST /a/x | 350 | Payload(EAP Req/Id||CS||RID-C) | 351 1) |<----------------------------------------| 352 | 2.01 Created Location-Path [/a/y] | 353 | Payload(EAP Resp/Id||CS||RID-I) | 354 2) |---------------------------------------->| 355 | POST /a/y | 356 | Payload(EAP-X Req) | 357 3) |<----------------------------------------| 358 | 2.01 Created Location-Path [/a/z] | 359 | Payload(EAP-X Resp) | 360 4) |---------------------------------------->| 361 .... 362 | POST /a/q | 363 | Payload(EAP-X Req) | 364 5) |<----------------------------------------| 365 | 2.01 Created Location-Path [/a/w] | 366 | Payload (EAP-X Resp) | 367 6) |---------------------------------------->| 368 | | MSK 369 | POST /a/w | | 370 | OSCORE | V 371 | Payload (EAP Success||*Session-Lifetime)| OSCORE 372 MSK 7) |<----------------------------------------| CONTEXT 373 | | | 374 V | 2.04 Changed | 375 OSCORE | OSCORE | 376 CONTEXT 8 )|---------------------------------------->| 378 (*) Session-Lifetime is optional. 380 Figure 3: CoAP-EAP flow of operation with OSCORE 382 3.3. Reauthentication 384 When the CoAP-EAP state is close to expire, the IoT device MAY want 385 to start a new authentication process (re-authentication) to renew 386 the state. The main goal is to derive new and fresh keying material 387 (MSK/EMSK) that, in turn, allows deriving a new OSCORE security 388 context, increasing the protection against key leakage. The keying 389 material MUST be renewed before the expiration of the Session- 390 Lifetime. By default, the EAP Key Management Framework establishes a 391 default value of 8 hours to refresh the keying material. Certain EAP 392 methods such as EAP-NOOB [I-D.ietf-emu-eap-noob] or EAP-AKA' 393 [RFC5448] provides fast reconnect for quicker re-authentication. The 394 EAP re-authentication protocol (ERP) [RFC6696] MAY be also used for 395 avoiding the repetition of the entire EAP exchange. 397 The message flow for the re-authentication will be the same as the 398 one shown in Figure 3. Nevertheless, two different CoAP-EAP states 399 will be active during the re-authentication: the current CoAP-EAP 400 state and the new CoAP-EAP state, which will be created once the re- 401 authentication has finished with success. Once the re-authentication 402 is completed successfully, the current CoAP-EAP state is deleted and 403 the new CoAP-EAP becomes the current one. If by any reason, the re- 404 authentication fails to complete, the current CoAP-EAP state will be 405 available until it expires, or it is renewed in another try of re- 406 authentication. 408 If the re-authentication fails, it is up to the IoT device decide 409 when to restart a re-authentication before the current EAP state 410 expires. 412 3.4. Managing the State of the Service 414 The IoT device and the Controller keep a state during the CoAP-EAP 415 negotiation. The CoAP-EAP state includes several important parts: 417 * A reference to an instance of the EAP (peer or authenticator/ 418 server) state machine. 420 * The resource for the next message in the negotiation (e.g '/a/y') 422 * The MSK exported when the EAP authentication is successful. In 423 particular, CoAP-EAP is able to access to the different variables 424 by the EAP state machine (i.e. [RFC4137]). 426 * A reference to the OSCORE context. 428 Once created, the Controller MAY choose to delete it as described in 429 Figure 4. On the other hand, the IoT device may need to renew the 430 CoAP-EAP state because the key material is close to expire, as 431 mentioned in Section 3.3. 433 There are situations where the current CoAP-EAP state might need to 434 be removed. For instance, due to its expiration or a forced removal 435 if the IoT device needs to be expelled from the security domain. 436 This exchange is illustrated in Figure 4. 438 If the Controller deems necessary, the removal of the CoAP-EAP state 439 from the IoT device before it expires, it can send a DELETE command 440 in a request to the IoT device, referencing the last CoAP-EAP state 441 resource given by the CoAP server, whose identifier will be the last 442 one received (e.g., '/a/w' in Figure 3). This message is protected 443 with the OSCORE security association to prevent forgery. Upon 444 reception of this message, the CoAP server sends a response to the 445 Controller with the Code '2.02 Deleted', which is also protected with 446 the OSCORE security association. If a response from the IoT device 447 does not arrive after EXCHANGE_LIFETIME the Controller will remove 448 the state from its side. 450 IoT device Controller 451 ------------- ------------- 452 | | 453 | DELETE /a/w | 454 | OSCORE | 455 |<----------------------------------------| 456 | | 457 | 2.02 Deleted | 458 | OSCORE | 459 |---------------------------------------->| 461 Figure 4: Deleting state 463 3.5. Error handling 465 This section elaborates how different errors are handled, from EAP 466 authentication failure, a non-responding endpoint, lost messages or 467 initial POST message arriving out of place. 469 3.5.1. EAP authentication failure 471 EAP authentication MAY fail for different situations (e.g. wrong 472 credentials). The result is that the Controller will send an EAP 473 failure because of the EAP authentication (Step 7 in Figure 3). In 474 this case, the IoT device MUST send a response '4.01 Unauthorized' in 475 Step 8. Therefore, Step 7 and Step 8 are not protected in this case 476 because no MSK is exported and the OSCORE security context is not 477 generated. 479 If the EAP authentication fails during the re-authentication and the 480 Controller sends an EAP failure, the current CoAP-EAP state will be 481 still usable until it expires. 483 3.5.2. Non-responding endpoint 485 If, by any reason, one of the entities becomes non-responding, the 486 CoAP-EAP state SHOULD be kept only for a period of time before it is 487 removed. The removal of the CoAP-EAP state in the Controller assumes 488 that the IoT device will need to authenticate again. According to 489 CoAP, EXCHANGE_LIFETIME considers the time it takes until a client 490 stops expecting a response to a request. A timer is reset every time 491 a message is sent. If EXCHANGE_LIFETIME has passed waiting for the 492 next message, both entities will delete the CoAP-EAP state if the 493 authentication process has not finished correctly. 495 3.5.3. Duplicated message with /.well-known/coap-eap 497 The reception of the trigger message in Step 0 containing /.well- 498 known/coap-eap needs some additional considerations, as the resource 499 is always available in the EAP authenticator. 501 If a trigger message (Step 0) arrives to the Controller during an 502 ongoing authentication, the Controller MUST silently discard this 503 trigger message. 505 If an old "POST /.well-known/coap-eap" (Step 0) arrives to the 506 Controller and there is no authentication ongoing, the Controller may 507 understand that a new authentication process is requested. 508 Consequently, the Controller will start a new EAP authentication. 509 However, the IoT device did not start any authentication and 510 therefore, it has not selected any resource for the EAP 511 authentication. Thus, IoT device sends a '4.04 Not found' in the 512 response (Figure 5). 514 IoT device Controller 515 ------------- ------------- 516 | *POST /.well-known/coap-eap | 517 0) | , No-Response | 518 | Payload("/a/x") | 519 | ------------------------->| 520 | POST /a/x | 521 | Payload (EAP Req/Id||CS) | 522 1) |<----------------------------------------| 523 | | 524 | 4.04 Not found | 525 |---------------------------------------->| 526 * Old 528 Figure 5: /.well-known/coap-eap with no ongoing authentication 529 from the EAP authenticator 531 3.6. Proxy operation in CoAP-EAP 533 The CoAP-EAP operation is intended to be compatible with the use of 534 intermediary entities between the IoT device and the Controller, when 535 direct communication is not possible. In this context, CoAP proxies 536 can be used as enablers of the CoAP-EAP exchange. 538 This specification is limited to use standard CoAP [RFC7252] as well 539 as standardized CoAP options [RFC8613]. It does not specify any 540 addition in the form of CoAP options. This is expected to ease the 541 integration of CoAP intermediaries in the CoAP-EAP exchange. 543 There is a consideration that needs to be considered, when using 544 proxies in the CoAP-EAP, as the exchange contains a role-reversal 545 process at the beginning of the exchange. In the first message, the 546 IoT device acts as a CoAP client, and the Controller as the CoAP 547 server. After that, remaining exchanges the roles are reversed, 548 being the IoT device, the CoAP server and the Controller, the CoAP 549 client. 551 4. CBOR Objects in CoAP-EAP 553 In the CoAP-EAP exchange, there is information that needs to be 554 exchanged between the two entities. Examples of these are the cipher 555 suites that need to be negotiated or authorization information 556 (Session-lifetime). There may be also a need of extending the 557 information that has to be exchanged in the future. This section 558 specifies the CBOR [RFC8949] data structure to exchange information 559 between the IoT device and the Controller in the CoAP payload. 561 Next, is the specification of the CBOR Object to exchange information 562 in CoAP-EAP 564 CoAP-EAP_Info = { 565 ? 1 : array, ; cipher suite 566 ? 2 : bstr, ; RID-C 567 ? 3 : bstr, ; RID-I 568 ? 4 : uint ; Session-Lifetime 569 } 571 Figure 6: CBOR data structure for CoAP-EAP 573 The parameters contain the following information: 575 1. cipher suite: It contains a array with the list of the proposed 576 or selected CBOR algorithms for OSCORE. If the field is carried 577 over a request, the meaning is the proposed cipher suite, if it 578 is carried over a response, corresponds to the response. 580 2. RID-I: It contains the Recipient ID of the IoT device. The 581 Controller uses this value as Sender ID for its OSCORE Sender 582 Context. The IoT device uses this value as Recipient ID for its 583 Recipient Context. 585 3. RID-C: It contains the Recipient ID of the Controller. The IoT 586 device uses this value as Sender ID for its OSCORE Sender 587 Context. The Controller uses this value as Recipient ID for its 588 Recipient Context. 590 4. Session-Lifetime: Contains the time the session is valid in 591 seconds. 593 The indexes from 65000 to 65535 are reserved for experimentation. 595 5. Cipher suite negotiation and key derivation 597 5.1. Cipher suite negotiation 599 OSCORE runs after the EAP authentication, using the cipher suite 600 selected in the cipher suite negotiation (Step 1 and 2). To 601 negotiate the cipher suite, CoAP-EAP follows a simple approach: the 602 Controller sends a list, in decreasing order or preference, with the 603 identifiers of the supported cipher suites (Step 1). In the response 604 to that message (Step 2), the IoT device sends a response with the 605 choice. 607 This list is included in the payload after the EAP message with a 608 CBOR array that contains the cipher suites. An example of how the 609 fields are arranged in the CoAP payload can be seen in Figure 7. An 610 example of the exchange with the cipher suite negotiation is shown in 611 Figure 8, where can be appreciated the disposition of both EAP- 612 Request/Identity and EAP-Response/Identity, followed by the CBOR 613 object defined in Section 4, containing in the cipher suite field the 614 CBOR array for the cipher suite negotiation. 616 +-----+-----------+-------+------++-------------+ 617 |Code |Identifier |Length | Data ||cipher suites| 618 +-----+-----------+-------+------++-------------+ 619 EAP Packet CBOR Object 621 Figure 7: cipher suites are in the CoAP payload 623 EAP peer EAP Auth. 624 (CoAP server) (CoAP client) 625 ------------- ------------- 626 | | 627 | ... | 628 |---------------------------------------->| 629 | POST /a/x | 630 | Payload (EAP Req/Id, CBORArray[0,1,2]) | 631 1) |<----------------------------------------| 632 | 2.01 Created Location-Path [/a/y] | 633 | Payload (EAP Resp/Id, CBORArray[0]) | 634 2) |---------------------------------------->| 635 ... 637 Figure 8: cipher suite negotiation 639 In case there is no CBOR array stating the cipher suites, the default 640 cipher suites are applied. If the Controller sends a restricted list 641 of cipher suites that is willing to accept it MUST include the 642 default value 0 since it is mandatory to implement. The IoT device 643 will have at least that option available. 645 The cipher suite requirements are inherited from the ones established 646 by OSCORE. By default, the HKDF algorithm is SHA-256 and the AEAD 647 algorithm is AES-CCM-16-64-128. Both are mandatory to implement. 648 The other cipher suites supported and negotiated in the cipher suite 649 negotiation are the following: 651 0. AES-CCM-16-64-128, SHA-256 (default) 653 1. A128GCM, SHA-256 655 2. A256GCM, SHA-384 657 3. ChaCha20/Poly1305, SHA-256 659 4. ChaCha20/Poly1305, SHAKE256 661 This specification uses the (HMAC)-based key derivation function 662 (HKDF) defined in [RFC5869] to derive the necessary key material. 663 Since the key derivation process uses the MSK, which is considered 664 fresh key material, we will use the HKDF-Expand function, which we 665 will shorten here as KDF. 667 5.2. Deriving the OSCORE Security Context 669 The derivation of the security context for OSCORE allows securing the 670 communication between the IoT device and the Controller once the MSK 671 has been exported providing, confidentiality, integrity, key 672 confirmation (Step 7 and 8) and detecting a downgrading attack. 674 The Master Secret can be derived by using the chosen cipher suite and 675 the KDF. The Master Secret can be derived as follows: 677 Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", 678 length) 680 where: 682 * The algorithms for OSCORE are agreed in the cipher suite 683 negotiation. 685 * The MSK exported by the EAP method. Discussion about the use of 686 the MSK for the key derivation is done in Section 7. 688 * CS is the concatenation of the content of the cipher suite 689 negotiation, that is, the list of cipher suites sent by the 690 Controller (Step 1) the selected option by the IoT device (Step 691 2). If any of the messages did not contain the CBOR array 692 (default algorithms), the null string is used. 694 * "COAP-EAP OSCORE MASTER SECRET" is the ASCII code representation 695 of the non-NULL terminated string (excluding the double quotes 696 around it). 698 * CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated. 700 * length is the size of the output key material. 702 The Master Salt, similarly to the Master Secret, can be derived as 703 follows: 705 Master Salt = KDF(MSK, CS | "OSCORE MASTER SALT", length) 707 where: 709 * The algorithms are agreed in the cipher suite negotiation. 711 * The MSK exported by the EAP method. Discussion about the use of 712 the MSK for the key derivation is done in Section 7. 714 * CS is the concatenation of the content of the cipher suite 715 negotiation, in the request and response. If any of the messages 716 did not contain the CBOR array, the null string is used. 718 * "OSCORE MASTER SALT" is the ASCII code representation of the non- 719 NULL terminated string (excluding the double quotes around it). 721 * CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated. 723 * length is the size of the output key material. 725 Since the MSK is used to derive the Master Key, the correct 726 verification of the OSCORE protected request (Step 7) and response 727 (Step 8) confirms the Controller and the IoT device have the same 728 Master Secret, achieving key confirmation. 730 To prevent a downgrading attack, the content of the cipher suites 731 negotiation (which we refer to here as CS) is embedded in the Master 732 Secret derivation. If an attacker changes the value of the cipher 733 suite negotiation, the result will be different OSCORE security 734 contexts, that ends up with a failure in Step 7 and 8. 736 The Controller will use the Recipient ID of the IoT device (RID-I) as 737 Sender ID for its OSCORE Sender Context. The IoT device will use 738 this value as Recipient ID for its Recipient Context. 740 The IoT device will use the Recipient ID of the Controller (RID-C) as 741 Sender ID for its OSCORE Sender Context. The Controller will use 742 this value as Recipient ID for its Recipient Context. 744 6. Discussion 746 6.1. CoAP as EAP lower layer 748 This section discusses the suitability of the CoAP protocol as EAP 749 lower layer, and reviews the requisites imposed by the EAP protocol 750 to any protocol that transports EAP. What EAP expects from its lower 751 layers can be found in section 3.1 of [RFC3748], which is elaborated 752 next: 754 Unreliable transport. EAP does not assume that lower layers are 755 reliable but it can benefit for a reliable lower layer. In this 756 sense, CoAP provides a reliability mechanism (e.g. through the use 757 of Confirmable messages). 759 Lower layer error detection. EAP relies on lower layer error 760 detection (e.g., CRC, Checksum, MIC, etc.). CoAP goes on top of UDP/ 761 TCP which provides a checksum mechanism over its payload. 763 Lower layer security. EAP does not require security services from 764 the lower layers. 766 Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 767 octets or greater. CoAP assumes an upper bound of 1024 for its 768 payload which covers the requirements of EAP. 770 Ordering guarantees. EAP relies on lower layer ordering guarantees 771 for correct operation. Regarding message ordering, every time a new 772 message arrives at the authentication service hosted by the IoT 773 device, a new resource is created and this is indicated in a "2.01 774 Created" response code along with the name of the new resource via 775 Location-Path or Location-Query. This way the application indicates 776 that its state has advanced. Although the [RFC3748] states: "EAP 777 provides its own support for duplicate elimination and 778 retransmission", EAP is also reliant on lower layer ordering 779 guarantees. In this regard, [RFC3748] talks about possible 780 duplication and says: "Where the lower layer is reliable, it will 781 provide the EAP layer with a non-duplicated stream of packets. 782 However, while it is desirable that lower layers provide for non- 783 duplication, this is not a requirement". CoAP is providing a non- 784 duplicated stream of packets and accomplish the "desirable" non- 785 duplication. In addition, [RFC3748] says that when EAP runs over a 786 reliable lower layer "the authenticator retransmission timer SHOULD 787 be set to an infinite value, so that retransmissions do not occur at 788 the EAP layer." 790 6.2. Size of the EAP lower layer vs EAP method size 792 Regarding the impact that an EAP lower layer will have to the total 793 byte size of the whole exchange, there is a comparison with another 794 network layer based EAP lower layer, PANA [RFC5191], in [coap-eap]. 795 Comparing the EAP lower layer (alone) and taking into account EAP. 796 On the one hand, at the EAP lower layer level, the usage of CoAP 797 gives important benefits. On the other hand, when taking into 798 account the EAP method overload, this reduction is less but still 799 significant if the EAP method generates large EAP messages. If the 800 EAP method is very taxing, the impact of the reduction in size of the 801 EAP lower layer is less significant. This leads to the conclusion 802 that possible next steps in this field could be designing new EAP 803 methods that can be better adapted to the requirements of IoT devices 804 and networks. For example, authors in [coap-eap] used EAP-PSK as an 805 example, since it only involves 4 messages and their length can be 806 less than 60 bytes. Moreover, it only uses symmetric cryptography. 808 However, the impact of the EAP lower layer itself cannot be ignored, 809 hence the proposal of using CoAP as lightweight protocol for this 810 purpose. Other EAP methods such as EAP-AKA'[RFC5448] or new EAP 811 methods such as EAP-NOOB [I-D.ietf-emu-eap-noob] or EAP-EDHOC 812 [I-D.ingles-eap-edhoc] that can benefit, as well as new ones that may 813 be proposed in the future with IoT constraints in mind, from a CoAP- 814 based EAP lower layer. 816 7. Security Considerations 818 There are some aspects to be considered such as how authorization is 819 managed, the use of MSK as keying material and how the trust in the 820 Controller is established. Additional considerations such as EAP 821 channel binding as per [RFC6677] are also discussed here. 823 7.1. Authorization 825 Authorization is part of bootstrapping. It serves to establish 826 whether the node can join and the set of conditions it has to adhere. 827 The authorization data will be gathered from the organization that is 828 responsible for the IoT device and sent to the EAP authenticator in 829 case of AAA infrastructure is deployed. 831 In standalone mode, the authorization information will be in the 832 Controller. If the pass-through mode is used, authorization data 833 received from the AAA server can be delivered by the AAA protocol 834 (e.g. RADIUS or Diameter). Providing more fine-grained 835 authorization data can be with the transport of SAML in RADIUS 836 [RFC7833]. 838 After bootstrapping, additional authorization information to operate 839 in the security domain, e.g., access services offered by other nodes, 840 can be taken care of by the solutions proposed in the ACE WG. 842 7.2. Freshness of the key material 844 In CoAP-EAP there is no nonce exchange to provide freshness to the 845 keys derived from the MSK. The MSK and Extended Master Session Key 846 (EMSK) keys according to the EAP Key Management Framework [RFC5247] 847 are fresh key material. Since only one authentication is established 848 per EAP authenticator, there is no need for generating additional key 849 material. In case a new MSK is required, a re-authentication can be 850 done, by running the process again, or using a more lightweight EAP 851 method to derive additional key material as elaborated in 852 Section 3.3. 854 7.3. Channel Binding support 856 According to the [RFC6677], channel binding related with EAP, is sent 857 through the EAP method that supports it. 859 To satisfy the requirements of the document, we need to send the EAP 860 lower layer identifier (To be assigned by IANA), in the EAP Lower- 861 Layer Attribute if RADIUS is used. 863 7.4. Additional Security Consideration 865 In the process of authentication, there is a possibility of an entity 866 forging messages to generate denial of service (DoS) attacks on any 867 of the entities involved. For instance, an attacker can forge 868 multiple initial message to start an authentication (Step 0) with the 869 Controller as if they were sent by different IoT devices. 870 Consequently, the Controller will start an authentication per each 871 message received in Step 0, sending the EAP Request/Id (Step 1). 873 To minimize the effects of this DoS attack, it is RECOMMENDED that 874 the Controller limits the rate at which it processes incoming 875 messages in Step 0 to provide robustness against denial of service 876 (DoS) attacks. The details of rate limiting are outside the scope of 877 this specification. Nevertheless, the rate of these messages are 878 also limited by the bandwidth available between the IoT device and 879 the Controller. This bandwidth will be specially limited in 880 constrained links (e.g., LPWAN). Lastly, it is also RECOMMENDED to 881 reduce at a minimum the state in the Controller at least until the 882 EAP Response/Ids received by the Controller. 884 Other security-related concerns can be how to ensure that the IoT 885 device joining the security domain can in fact trust the Controller. 886 This issue is elaborated in the EAP Key Management Framework 887 [RFC5247]. In particular, the IoT device knows it can trust the 888 Controller because the key that is used to establish the security 889 association is derived from the MSK. If the Controller has the MSK, 890 it is clear the AAA Server of the node trusted the Controller, which 891 can be considered as a trusted party. 893 8. IANA Considerations 895 Considerations for IANA regarding this document: 897 * Assignment of EAP lower layer identifier. 899 * Assignment of the URI /.well-known/coap-eap 901 * Assignment of the media type "application/coap-eap" 903 * Assignment of the content format "application/coap-eap" 905 * Assignment of the resource type (rt=) "core.coap-eap" 906 * Assignment of the numbers assigned for the cipher suite 907 negotiation 909 * Assignment of the numbers assigned for the numbers of the CBOR 910 object in CoAP-EAP 912 9. Acknowledgments 914 We would like to thank as the reviewers of this work: Carsten 915 Bormann, Mohit Sethi, Benjamin Kaduk, Christian Amsuss, John 916 Mattsson, Goran Selander, Alexandre Petrescu, Pedro Moreno-Sanchez 917 and Eduardo Ingles-Sanchez. 919 We would also like to thank Gabriel Lopez-Millan for the first review 920 of this document and we would like to thank Ivan Jimenez-Sanchez for 921 the first proof-of-concept implementation of this idea. 923 And thank for their valuable comments to Alexander Pelov and Laurent 924 Toutain, especially for the potential optimizations of CoAP-EAP. 926 10. References 928 10.1. Normative References 930 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 931 Requirement Levels", BCP 14, RFC 2119, 932 DOI 10.17487/RFC2119, March 1997, 933 . 935 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 936 Levkowetz, Ed., "Extensible Authentication Protocol 937 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 938 . 940 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 941 Authentication Protocol (EAP) Key Management Framework", 942 RFC 5247, DOI 10.17487/RFC5247, August 2008, 943 . 945 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 946 Key Derivation Function (HKDF)", RFC 5869, 947 DOI 10.17487/RFC5869, May 2010, 948 . 950 [RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel- 951 Binding Support for Extensible Authentication Protocol 952 (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, 953 . 955 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 956 Application Protocol (CoAP)", RFC 7252, 957 DOI 10.17487/RFC7252, June 2014, 958 . 960 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 961 Bose, "Constrained Application Protocol (CoAP) Option for 962 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 963 August 2016, . 965 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 966 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 967 May 2017, . 969 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 970 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 971 Application Protocol) over TCP, TLS, and WebSockets", 972 RFC 8323, DOI 10.17487/RFC8323, February 2018, 973 . 975 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 976 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 977 . 979 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 980 "Object Security for Constrained RESTful Environments 981 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 982 . 984 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 985 Representation (CBOR)", STD 94, RFC 8949, 986 DOI 10.17487/RFC8949, December 2020, 987 . 989 10.2. Informative References 991 [coap-eap] Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP- 992 Based Bootstrapping Service for the Internet of Things - 993 https://www.mdpi.com/1424-8220/16/3/358", March 2016. 995 [eap-framework] 996 Sethi, M. and T. Aura, "Secure Network Access 997 Authentication for IoT Devices: EAP Framework vs. 998 Individual Protocols - 999 https://ieeexplore.ieee.org/document/9579387", October 1000 2021. 1002 [I-D.ietf-ace-oauth-authz] 1003 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1004 H. Tschofenig, "Authentication and Authorization for 1005 Constrained Environments (ACE) using the OAuth 2.0 1006 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 1007 draft-ietf-ace-oauth-authz-36, 16 November 2020, 1008 . 1011 [I-D.ietf-core-resource-directory] 1012 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. 1013 Van der Stok, "CoRE Resource Directory", Work in Progress, 1014 Internet-Draft, draft-ietf-core-resource-directory-28, 7 1015 March 2021, . 1018 [I-D.ietf-emu-eap-noob] 1019 Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band 1020 authentication for EAP (EAP-NOOB)", Work in Progress, 1021 Internet-Draft, draft-ietf-emu-eap-noob-05, 12 July 2021, 1022 . 1025 [I-D.ingles-eap-edhoc] 1026 Sanchez, E., Garcia-Carrillo, D., and R. Marin-Lopez, "EAP 1027 method based on EDHOC Authentication", Work in Progress, 1028 Internet-Draft, draft-ingles-eap-edhoc-01, 2 November 1029 2020, . 1032 [lo-coap-eap] 1033 Garcia-Carrillo, D., Marin-Lopez, R., Kandasamy, A., and 1034 A. Pelov, "A CoAP-Based Network Access Authentication 1035 Service for Low-Power Wide Area Networks: LO-CoAP-EAP - 1036 https://www.mdpi.com/1424-8220/17/11/2646", November 2017. 1038 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 1039 "State Machines for Extensible Authentication Protocol 1040 (EAP) Peer and Authenticator", RFC 4137, 1041 DOI 10.17487/RFC4137, August 2005, 1042 . 1044 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 1045 Pre-Shared Key Extensible Authentication Protocol (EAP) 1046 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 1047 . 1049 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1050 and A. Yegin, "Protocol for Carrying Authentication for 1051 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1052 May 2008, . 1054 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1055 Extensible Authentication Protocol Method for 3rd 1056 Generation Authentication and Key Agreement (EAP-AKA')", 1057 RFC 5448, DOI 10.17487/RFC5448, May 2009, 1058 . 1060 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1061 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1062 January 2012, . 1064 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., 1065 "EAP Extensions for the EAP Re-authentication Protocol 1066 (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012, 1067 . 1069 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1070 DOI 10.17487/RFC6762, February 2013, 1071 . 1073 [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A 1074 RADIUS Attribute, Binding, Profiles, Name Identifier 1075 Format, and Confirmation Methods for the Security 1076 Assertion Markup Language (SAML)", RFC 7833, 1077 DOI 10.17487/RFC7833, May 2016, 1078 . 1080 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1081 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1082 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1083 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1084 . 1086 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 1087 Context Header Compression (SCHC) for the Constrained 1088 Application Protocol (CoAP)", RFC 8824, 1089 DOI 10.17487/RFC8824, June 2021, 1090 . 1092 [TS133.501] 1093 ETSI, "5G; Security architecture and procedures for 5G 1094 System - TS 133 501 V15.2.0 (2018-10)", 2018. 1096 Appendix A. Flow of operation (DTLS establishment) 1098 CoAP-EAP makes possible to derive a PSK for (D)TLS to allow PSK-based 1099 authentication between the IoT device and the Controller. In the 1100 instance of using (D)TLS to establish a security association, there 1101 is a limitation to the use of intermediaries between the IoT device 1102 and the Controller, as (D)TLS breaks the end-to-end communications 1103 when using intermediaries such as proxies. 1105 IoT device Controller 1106 ------------- ------------- 1107 ... 1108 | 2.01 Created Location-Path [/a/w] | 1109 | Payload (EAP-X Resp) | 1110 6)|---------------------------------------->| 1111 | | MSK 1112 | (D)TLS 1.3 Client Hello | | 1113 MSK 7) |<----------------------------------------| V 1114 | | | DTLS_PSK 1115 V |===============DTLS hanshake=============| 1116 DTLS_PSK | | 1117 *... 1118 (*) Protected with (D)TLS 1120 Figure 9: CoAP-EAP flow of operation with DTLS 1122 Figure 9 shows the last steps of the operation for CoAP-EAP when 1123 (D)TLS is used to protect the communication between the IoT device 1124 and the Controller using the keying material exported by the EAP 1125 authentication. The general flow is essentially the same as in the 1126 case of OSCORE, except that DTLS negotiation is established in Step 1127 7). Once DTLS negotiation has finished successfully the IoT device 1128 is granted access to the domain. Step 7 MUST be interpreted by the 1129 IoT device as an alternate success indication, which will end up with 1130 the MSK and the DTLS_PSK derivation for the (D)TLS authentication 1131 based on PSK. 1133 According to [RFC8446] the provision of the PSK out-of-band also 1134 requires the provision of the KDF hash algorithm and the PSK 1135 identity. To simplify the design in CoAP-EAP, the KDF hash algorithm 1136 can be included in the list of cipher suites exchange in Step 1 and 1137 Step 2 if DTLS wants to be used instead of OSCORE. For the same 1138 reason, the PSK identity is derived from (RID-C) (RID-I) as defined 1139 in Appendix A.2. 1141 A.1. Cryptographic suite negotiation for DTLS 1143 It is also possible to derive a pre-shared key for DTLS to establish 1144 a DLTS security association after a successful EAP authentication. 1145 Analogously to how the cipher suite is negotiated for OSCORE 1146 Section 5.1, the Controller sends a list, in decreasing order of 1147 preference, with the identifiers of the cipher suites supported (Step 1148 1). In the response, the IoT device sends the choice. 1150 This list is included in the payload after the EAP message with a 1151 CBOR array that contains the cipher suites. This CBOR array is 1152 enclosed as one of the elements of the CBOR Object used for 1153 transporting information in CoAP-EAP (See Section 4. An example of 1154 how the fields are arranged in the CoAP payload can be seen in 1155 Figure 7. 1157 In case there is no CBOR array stating the cipher suites, the default 1158 cipher suites are applied. If the Controller sends a restricted list 1159 of cipher suites that is willing to accept it MUST include the 1160 default value 0 since it is mandatory to implement. The IoT device 1161 will have at least that option available. 1163 The cipher suites are the following: 1165 3. TLS_SHA256 1167 4. TLS_SHA384 1169 5. TLS_SHA512 1171 A.2. Deriving DTLS PSK and identity 1173 To enable DTLS after an EAP authentication using the key material 1174 generated, we define the Identity and the PSK for DTLS. The Identity 1175 in this case is generated by concatenating the exchanged Sender ID 1176 and the Recipient ID. 1178 CoAP-EAP PSK Identity = RID-C || RID-I 1180 It is also possible to derive a pre-shared key for DTLS [RFC6347], 1181 refereed to here as "DTLS PSK", from the MSK between both IoT device 1182 and Controller if required. The length of the DTLS PSK will depend 1183 on the cipher suite. To have keying material with sufficient length 1184 a key of 32 bytes is derived that can be later truncated if needed: 1186 DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length). 1188 where: 1190 * MSK is exported by the EAP method. 1192 * "CoAP-EAP DTLS PSK" is the ASCII code representation of the non- 1193 NULL terminated string (excluding the double quotes around it). 1195 * length is the size of the output key material. 1197 Appendix B. Examples of Use Case Scenario 1199 For a IoT device to act as a trustworthy entity within a security 1200 domain, certain key material is needed to be shared between the IoT 1201 device and the Controller. 1203 Next, we elaborate on examples of different use case scenarios about 1204 the usage of CoAP-EAP. Generally, we are dealing with 4 entities: 1206 * 2 nodes (A and B), which are IoT devices. They are the EAP peers. 1208 * 1 controller (C). The controller manages a domain where nodes can 1209 be deployed. It can be considered a more powerful machine than 1210 the IoT devices. 1212 * 1 AAA server (AAA) - Optional. The AAA is an Authentication, 1213 Authorization and Accounting Server, which is not constrained. 1214 Here, the Controller acts as EAP authenticator in pass-through 1215 mode. 1217 Generally, any IoT device wanting to join the domain managed by the 1218 Controller MUST perform a CoAP-EAP authentication with the Controller 1219 (C). This authentication MAY involve an external AAA server. This 1220 means that A and B, once deployed, will run CoAP-EAP once, as a 1221 bootstrapping phase, to establish a security association with C. 1222 Moreover, any other entity, which wants to join and establish 1223 communications with nodes under C's domain must also do the same. By 1224 using EAP, we can have the flexibility of having different types of 1225 credentials. For instance, if we have a device that is not battery 1226 dependent, and not very constrained, we could use a heavier 1227 authentication method. With varied IoT devices and networks we might 1228 need to resort to more lightweight authentication methods (e.g., EAP- 1229 NOOB[I-D.ietf-emu-eap-noob], EAP-AKA'[RFC5448], EAP-PSK[RFC4764], 1230 EAP-EDHOC[I-D.ingles-eap-edhoc], etc.) being able to adapt to 1231 different types of devices according to organization policies or 1232 devices capabilities. 1234 B.1. Example 1: CoAP-EAP in ACE 1236 In ACE, the process of Client registration and provisioning of 1237 credentials to the client is not specified. The process of Client 1238 registration and provisioning can be achieved using CoAP-EAP. Once 1239 the process of authentication with EAP is completed, fresh key 1240 material is shared between the IoT device and the Controller. In 1241 this instance, the Controller and the Authorization Server (AS) of 1242 ACE can be co-located. 1244 Next, we exemplify how CoAP-EAP can be used to perform the Client 1245 registration in a general way, to allow two IoT devices (A and B) to 1246 communicate and interact after a successful client registration. 1248 Node A wants to communicate with node B (e.g. to activate a light 1249 switch). The overall process is divided into three phases. Let's 1250 start with node A. In the first phase, the node A (EAP peer) does 1251 not yet belong to Controller C's domain. Then, it communicates with 1252 C (EAP authenticator) and authenticates with CoAP-EAP, which, 1253 optionally, communicates with the AAA server to complete the 1254 authentication process. If the authentication is successful, a fresh 1255 MSK is shared between C and node A. This key material allows node A 1256 to establish a security association with the C. Some authorization 1257 information may be also provided in this step. In case EAP is used 1258 in standalone mode, the AS itself having information about the 1259 devices can be the entity providing said authorization information. 1260 If authentication and authorization are correct, node A is enrolled 1261 in controller C's domain for a period of time. In particular, 1262 [RFC5247] recommends 8 hours, though the the entity providing the 1263 authorization information can establish this lifetime. In the same 1264 manner, B needs to perform the same process with CoAP-EAP to be part 1265 of the controller C's domain. 1267 In the second phase, when node A wants to talk with node B, it 1268 contacts controller C for authorization to access node B and obtain 1269 all the required information to do that securely (e.g. keys, tokens, 1270 authorization information, etc.). This phase does NOT require the 1271 usage of CoAP-EAP. The details of this phase are out-of-scope of 1272 this document, and the ACE framework is used for this purpose 1273 [I-D.ietf-ace-oauth-authz]. 1275 In the third phase, the node A can access node B with the credentials 1276 and information obtained from the controller C in the second phase. 1277 This access can be repeated without contacting the controller, while 1278 the credentials given to A are still valid. The details of this 1279 phase are out-of-scope of this document. 1281 It is worth noting that first phase with CoAP-EAP is required to join 1282 the controller C's domain. Once it is performed with success, the 1283 communications are local to the controller C's domain and there is no 1284 need to perform a new EAP authentication as long as the key material 1285 is still valid. When the keys are about to expire, the IoT device 1286 can engage in a re-authentication as explained in Section 3.3, to 1287 renew the key material. 1289 B.2. Example 2: Multi-domain with AAA infrastructures 1291 We assume we have a device (A) of the domain acme.org, which uses a 1292 specific kind of credential (e.g., AKA) and intends to join the um.es 1293 domain. This user does not belong to this domain, for which first it 1294 performs a client registration using CoAP-EAP. For this, it 1295 interacts with the controller's domain acting as EAP authenticator, 1296 which in turn communicates with a AAA infrastructure (acting as AAA 1297 client). Through the local AAA server to communicate with the home 1298 AAA server to complete the authentication and integrate the device as 1299 a trustworthy entity into the domain of controller C. In this 1300 scenario, the AS under the role of the Controller receives the key 1301 material from the AAA infrastructure 1303 B.3. Example 3: Single domain with AAA infrastructure 1305 A University Campus, we have several Faculty buildings and each one 1306 has its own criteria or policies in place to manage IoT devices under 1307 an AS. All buildings belong to the same domain (e.g., um.es). All 1308 these buildings are managed with a AAA infrastructure. A new device 1309 (A) with credentials from the domain (e.g., um.es) will be able to 1310 perform the device registration with a Controller (C) of any building 1311 as long as they are managed by the same general domain. 1313 B.4. Example 4: Single domain without AAA infrastructure 1315 In another case, without a AAA infrastructure, we have a Controller 1316 that has co-located the EAP server and using EAP standalone mode we 1317 can manage all the devices within the same domain locally. Client 1318 registration of a node (A) with Controller (C) can also be performed 1319 in the same manner. 1321 B.5. Other use cases 1322 B.5.1. CoAP-EAP for network access control 1324 One of the first steps for an IoT device life-cycle is to perform the 1325 authentication to gain access to the network. To do so, the device 1326 first has to be authenticated and granted authorization to gain 1327 access to the network. Additionally, security parameters such as 1328 credentials can be derived from the authentication process allowing 1329 the trustworthy operation of the IoT device in a particular network 1330 by joining the security domain. By using EAP, we are able to achieve 1331 this with flexibility and scalability, because of the different EAP 1332 methods available and the ability to rely on AAA infrastructures if 1333 needed to support multi-domain scenarios, which is a key feature when 1334 the IoT devices deployed under the same security domain, belong to 1335 different organizations. Given that EAP is also used for network 1336 access control, we can adapt this service for other technologies. 1337 For instance, to provide network access control to very constrained 1338 technologies (e.g., LoRa network). Authors in [lo-coap-eap] provide 1339 an study of a minimal version of CoAP-EAP for LPWAN networks with 1340 interesting results. In this specific case, we could leverage the 1341 compression by SCHC for CoAP [RFC8824]. 1343 B.5.2. CoAP-EAP for service authentication 1345 It is not uncommon that the infrastructure where the device is 1346 deployed and the services of the IoT device are managed by different 1347 organizations. Therefore, in addition to the authentication for 1348 network access control, we have to consider the possibility of a 1349 secondary authentication to access different services. This process 1350 of authentication, for example, will provide with the necessary key 1351 material to establish a secure channel and interact with the entity 1352 in charge of granting access to different services. In 5G, for 1353 example, consider a primary and secondary authentication using EAP 1354 [TS133.501]. 1356 Authors' Addresses 1358 Rafa Marin-Lopez 1359 University of Murcia 1360 Campus de Espinardo S/N, Faculty of Computer Science 1361 30100 Murcia 1362 Spain 1364 Phone: +34 868 88 85 01 1365 Email: rafa@um.es 1366 Dan Garcia-Carrillo 1367 University of Oviedo 1368 Calle Luis Ortiz Berrocal S/N, Edificio Polivalente 1369 33203 Gijon Asturias 1370 Spain 1372 Email: garciadan@uniovi.es