idnits 2.17.1 draft-ietf-ace-wg-coap-eap-07.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 (27 May 2022) is 699 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 632 -- Looks like a reference, but probably isn't: '1' on line 629 -- Looks like a reference, but probably isn't: '2' on line 629 ** 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: A later version (-06) exists of draft-ietf-emu-eap-noob-05 == Outdated reference: A later version (-05) exists of draft-ingles-eap-edhoc-01 -- 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: 28 November 2022 University of Oviedo 6 27 May 2022 8 EAP-based Authentication Service for CoAP 9 draft-ietf-ace-wg-coap-eap-07 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 28 November 2022. 41 Copyright Notice 43 Copyright (c) 2022 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 establishing a 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 the 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 devices can start the service. 219 3.1. Discovery 221 Prior to the CoAP-EAP exchange taking 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 are 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 Step 0 (e.g., '/a/x'). The payload 273 in this message contains the first EAP message (EAP Request/ 274 Identity), the Recipient ID of the Controller (RID-C) for OSCORE 275 and it MAY contain a CBOR array containing a list with the cipher 276 suites (CS) for OSCORE. If the cipher suite is not included the 277 default cipher suite for OSCORE is used. The details of the 278 cipher suite negotiation are discussed in Section 5.1. 280 * Step 2. The IoT device processes the POST message passing the EAP 281 request (EAP-Req/Id) to the EAP peer state machine, which returns 282 an EAP response (EAP Resp/Id); it assigns a new resource to the 283 ongoing authentication process (e.g., '/a/y'), and deletes the 284 previous one ('/a/x'). It finally sends a '2.01 Created' response 285 with the new resource identifier in the Location-Path (and/or 286 Location-Query) options for the next step; the EAP response, the 287 Recipient ID of the IoT device (RID-I) and the selected cipher 288 suite for OSCORE are in the payload. In this step, the IoT device 289 MAY create an OSCORE security context (see Section 5.2). The 290 required key, the Master Session Key (MSK), will be available once 291 the EAP authentication is successful in step 7. 293 * Step 3-6. From now on, the Controller and the IoT device will 294 exchange EAP packets related to the EAP method (EAP-X), 295 transported in the CoAP message payload. The Controller will use 296 the POST method to send EAP requests to the IoT device. The IoT 297 device will use a response to carry the EAP response in the 298 payload. EAP requests and responses are represented in Figure 3 299 using the nomenclature (EAP-X-Req and EAP-X-Resp, respectively. 300 When a POST message arrives (e.g, '/a/x') carrying an EAP request 301 message, if processed correctly by the EAP peer state machine, 302 returns an EAP Response. Along with each EAP Response, a new 303 resource is created (e.g, '/a/z') for processing the next EAP 304 request and the ongoing resource (e.g., '/a/y') is erased. This 305 way ordering guarantee is achieved. Finally, an EAP response is 306 sent in the payload of a CoAP response that will also indicate the 307 new resource in the Location-Path (and/or Location-Query) Options. 308 In case there is an error processing a legitimate message, the 309 server will return a (4.00 Bad Request). There is a discussion 310 about error handling in Section 3.5. 312 * Step 7. When the EAP authentication ends with success, the 313 Controller obtains the Master Session Key (MSK) exported by the 314 EAP method, an EAP Success message and some authorization 315 information (i.e. session lifetime) [RFC5247]. The Controller 316 creates the OSCORE security context using the MSK and Sender ID 317 and Recipient ID exchanged in Steps 1 and 2. The establishment of 318 the OSCORE Security Context is defined in Section 5.2. Then, the 319 Controller sends the POST message protected with OSCORE for key 320 confirmation including the EAP Success. The Controller MAY also 321 send a Session Lifetime, in seconds, which is represented with an 322 unsigned integer in a CBOR object (see Section 4. If this Session 323 Lifetime is not sent, the IoT device assumes a default value of 8 324 hours as RECOMMENDED in [RFC5247]. The verification of the 325 received OSCORE protected "POST" message using RID-I (Recipient ID 326 of the IoT device) sent in Step 2 is considered by the IoT device 327 as an alternate indication of success ([RFC3748]). The EAP peer 328 state machine in the IoT device interprets the alternate 329 indication of success in a similar way to the arrival of an EAP 330 Success and returns the MSK, which is used for the OSCORE security 331 context in the IoT device to process the protected POST message 332 received from the Controller. 334 * Step 8. If the EAP authentication and the verification of the 335 OSCORE protected "POST" in Step 7 is successful, then the IoT 336 Device answers with an OSCORE protected '2.04 Changed'. From this 337 point on, the communication with the last resource (e.g. '/a/w') 338 MUST be protected with OSCORE. If allowed by application policy, 339 the same OSCORE security context MAY be used to protect 340 communication to other resources between the same endpoints. 342 IoT device Controller 343 ------------- ------------ 344 | POST /.well-known/coap-eap | 345 0) | No-Response | 346 | Payload("/a/x") | 347 |---------------------------------------->| 348 | POST /a/x | 349 | Payload(EAP Req/Id||CS||RID-C) | 350 1) |<----------------------------------------| 351 | 2.01 Created Location-Path [/a/y] | 352 | Payload(EAP Resp/Id||CS||RID-I) | 353 2) |---------------------------------------->| 354 | POST /a/y | 355 | Payload(EAP-X Req) | 356 3) |<----------------------------------------| 357 | 2.01 Created Location-Path [/a/z] | 358 | Payload(EAP-X Resp) | 359 4) |---------------------------------------->| 360 .... 361 | POST /a/q | 362 | Payload(EAP-X Req) | 363 5) |<----------------------------------------| 364 | 2.01 Created Location-Path [/a/w] | 365 | Payload (EAP-X Resp) | 366 6) |---------------------------------------->| 367 | | MSK 368 | POST /a/w | | 369 | OSCORE | V 370 | Payload (EAP Success||*Session-Lifetime)| OSCORE 371 MSK 7) |<----------------------------------------| CONTEXT 372 | | | 373 V | 2.04 Changed | 374 OSCORE | OSCORE | 375 CONTEXT 8 )|---------------------------------------->| 377 (*) Session-Lifetime is optional. 379 Figure 3: CoAP-EAP flow of operation with OSCORE 381 3.3. Reauthentication 383 When the CoAP-EAP state is close to expiring, the IoT device MAY want 384 to start a new authentication process (re-authentication) to renew 385 the state. The main goal is to derive new and fresh keying material 386 (MSK/EMSK) that, in turn, allows deriving a new OSCORE security 387 context, increasing the protection against key leakage. The keying 388 material MUST be renewed before the expiration of the Session- 389 Lifetime. By default, the EAP Key Management Framework establishes a 390 default value of 8 hours to refresh the keying material. Certain EAP 391 methods such as EAP-NOOB [I-D.ietf-emu-eap-noob] or EAP-AKA' 392 [RFC5448] provides fast reconnect for quicker re-authentication. The 393 EAP re-authentication protocol (ERP) [RFC6696] MAY be also used for 394 avoiding the repetition of the entire EAP exchange. 396 The message flow for the re-authentication will be the same as the 397 one shown in Figure 3. Nevertheless, two different CoAP-EAP states 398 will be active during the re-authentication: the current CoAP-EAP 399 state and the new CoAP-EAP state, which will be created once the re- 400 authentication has finished with success. Once the re-authentication 401 is completed successfully, the current CoAP-EAP state is deleted and 402 the new CoAP-EAP becomes the current one. If for any reason, the re- 403 authentication fails to complete, the current CoAP-EAP state will be 404 available until it expires, or it is renewed in another try of re- 405 authentication. 407 If the re-authentication fails, it is up to the IoT device to decide 408 when to restart a re-authentication before the current EAP state 409 expires. 411 3.4. Managing the State of the Service 413 The IoT device and the Controller keep a state during the CoAP-EAP 414 negotiation. The CoAP-EAP state includes several important parts: 416 * A reference to an instance of the EAP (peer or authenticator/ 417 server) state machine. 419 * The resource for the next message in the negotiation (e.g '/a/y') 421 * The MSK exported when the EAP authentication is successful. In 422 particular, CoAP-EAP is able to access to the different variables 423 by the EAP state machine (i.e. [RFC4137]). 425 * A reference to the OSCORE context. 427 Once created, the Controller MAY choose to delete it as described in 428 Figure 4. On the other hand, the IoT device may need to renew the 429 CoAP-EAP state because the key material is close to expire, as 430 mentioned in Section 3.3. 432 There are situations where the current CoAP-EAP state might need to 433 be removed. For instance, due to its expiration or a forced removal 434 if the IoT device needs to be expelled from the security domain. 435 This exchange is illustrated in Figure 4. 437 If the Controller deems necessary the removal of the CoAP-EAP state 438 from the IoT device before it expires, it can send a DELETE command 439 in a request to the IoT device, referencing the last CoAP-EAP state 440 resource given by the CoAP server, whose identifier will be the last 441 one received (e.g., '/a/w' in Figure 3). This message is protected 442 with the OSCORE security association to prevent forgery. Upon 443 reception of this message, the CoAP server sends a response to the 444 Controller with the Code '2.02 Deleted', which is also protected with 445 the OSCORE security association. If a response from the IoT device 446 does not arrive after EXCHANGE_LIFETIME the Controller will remove 447 the state from its side. 449 IoT device Controller 450 ------------- ------------- 451 | | 452 | DELETE /a/w | 453 | OSCORE | 454 |<----------------------------------------| 455 | | 456 | 2.02 Deleted | 457 | OSCORE | 458 |---------------------------------------->| 460 Figure 4: Deleting state 462 3.5. Error handling 464 This section elaborates on how different errors are handled. From 465 EAP authentication failure, a non-responding endpoint, lost messages 466 or initial POST message arriving out of place. 468 3.5.1. EAP authentication failure 470 EAP authentication MAY fail for different situations (e.g. wrong 471 credentials). The result is that the Controller will send an EAP 472 failure because of the EAP authentication (Step 7 in Figure 3). In 473 this case, the IoT device MUST send a response '4.01 Unauthorized' in 474 Step 8. Therefore, Step 7 and Step 8 are not protected in this case 475 because no MSK is exported and the OSCORE security context is not 476 generated. 478 If the EAP authentication fails during the re-authentication and the 479 Controller sends an EAP failure, the current CoAP-EAP state will be 480 still usable until it expires. 482 3.5.2. Non-responding endpoint 484 If, for any reason, one of the entities becomes non-responding, the 485 CoAP-EAP state SHOULD be kept only for a period of time before it is 486 removed. The removal of the CoAP-EAP state in the Controller assumes 487 that the IoT device will need to authenticate again. According to 488 CoAP, EXCHANGE_LIFETIME considers the time it takes until a client 489 stops expecting a response to a request. A timer is reset every time 490 a message is sent. If EXCHANGE_LIFETIME has passed waiting for the 491 next message, both entities will delete the CoAP-EAP state if the 492 authentication process has not finished correctly. 494 3.5.3. Duplicated message with /.well-known/coap-eap 496 The reception of the trigger message in Step 0 containing /.well- 497 known/coap-eap needs some additional considerations, as the resource 498 is always available in the EAP authenticator. 500 If a trigger message (Step 0) arrives to the Controller during an 501 ongoing authentication, the Controller MUST silently discard this 502 trigger message. 504 If an old "POST /.well-known/coap-eap" (Step 0) arrives to the 505 Controller and there is no authentication ongoing, the Controller may 506 understand that a new authentication process is requested. 507 Consequently, the Controller will start a new EAP authentication. 508 However, the IoT device did not start any authentication and 509 therefore, it has not selected any resource for the EAP 510 authentication. Thus, IoT device sends a '4.04 Not found' in the 511 response (Figure 5). 513 IoT device Controller 514 ------------- ------------- 515 | *POST /.well-known/coap-eap | 516 0) | , No-Response | 517 | Payload("/a/x") | 518 | ------------------------->| 519 | POST /a/x | 520 | Payload (EAP Req/Id||CS) | 521 1) |<----------------------------------------| 522 | | 523 | 4.04 Not found | 524 |---------------------------------------->| 525 * Old 527 Figure 5: /.well-known/coap-eap with no ongoing authentication 528 from the EAP authenticator 530 3.6. Proxy operation in CoAP-EAP 532 The CoAP-EAP operation is intended to be compatible with the use of 533 intermediary entities between the IoT device and the Controller, when 534 direct communication is not possible. In this context, CoAP proxies 535 can be used as enablers of the CoAP-EAP exchange. 537 This specification is limited to using standard CoAP [RFC7252] as 538 well as standardized CoAP options [RFC8613]. It does not specify any 539 addition in the form of CoAP options. This is expected to ease the 540 integration of CoAP intermediaries in the CoAP-EAP exchange. 542 There is a consideration that needs to be considered, when using 543 proxies in the CoAP-EAP, as the exchange contains a role-reversal 544 process at the beginning of the exchange. In the first message, the 545 IoT device acts as a CoAP client, and the Controller as the CoAP 546 server. After that, the remaining exchanges the roles are reversed, 547 being the IoT device, the CoAP server and the Controller, the CoAP 548 client. 550 4. CBOR Objects in CoAP-EAP 552 In the CoAP-EAP exchange, there is information that needs to be 553 exchanged between the two entities. Examples of these are the cipher 554 suites that need to be negotiated or authorization information 555 (Session-lifetime). There may be also a need of extending the 556 information that has to be exchanged in the future. This section 557 specifies the CBOR [RFC8949] data structure to exchange information 558 between the IoT device and the Controller in the CoAP payload. 560 Next, is the specification of the CBOR Object to exchange information 561 in CoAP-EAP 563 CoAP-EAP_Info = { 564 ? 1 : array, ; cipher suite 565 ? 2 : bstr, ; RID-C 566 ? 3 : bstr, ; RID-I 567 ? 4 : uint ; Session-Lifetime 568 } 570 Figure 6: CBOR data structure for CoAP-EAP 572 The parameters contain the following information: 574 1. cipher suite: It contains an array with the list of the proposed 575 or selected CBOR algorithms for OSCORE. If the field is carried 576 over a request, the meaning is the proposed cipher suite, if it 577 is carried over a response, corresponds to the response. 579 2. RID-I: It contains the Recipient ID of the IoT device. The 580 Controller uses this value as Sender ID for its OSCORE Sender 581 Context. The IoT device uses this value as Recipient ID for its 582 Recipient Context. 584 3. RID-C: It contains the Recipient ID of the Controller. The IoT 585 device uses this value as Sender ID for its OSCORE Sender 586 Context. The Controller uses this value as Recipient ID for its 587 Recipient Context. 589 4. Session-Lifetime: Contains the time the session is valid in 590 seconds. 592 The indexes from 65000 to 65535 are reserved for experimentation. 594 5. Cipher suite negotiation and key derivation 596 5.1. Cipher suite negotiation 598 OSCORE runs after the EAP authentication, using the cipher suite 599 selected in the cipher suite negotiation (Steps 1 and 2). To 600 negotiate the cipher suite, CoAP-EAP follows a simple approach: the 601 Controller sends a list, in decreasing order of preference, with the 602 identifiers of the supported cipher suites (Step 1). In the response 603 to that message (Step 2), the IoT device sends a response with the 604 choice. 606 This list is included in the payload after the EAP message with a 607 CBOR array that contains the cipher suites. An example of how the 608 fields are arranged in the CoAP payload can be seen in Figure 7. An 609 example of the exchange with the cipher suite negotiation is shown in 610 Figure 8, where can be appreciated the disposition of both EAP- 611 Request/Identity and EAP-Response/Identity, followed by the CBOR 612 object defined in Section 4, containing in the cipher suite field the 613 CBOR array for the cipher suite negotiation. 615 +-----+-----------+-------+------++-------------+ 616 |Code |Identifier |Length | Data ||cipher suites| 617 +-----+-----------+-------+------++-------------+ 618 EAP Packet CBOR Object 620 Figure 7: cipher suites are in the CoAP payload 622 EAP peer EAP Auth. 623 (CoAP server) (CoAP client) 624 ------------- ------------- 625 | | 626 | ... | 627 |---------------------------------------->| 628 | POST /a/x | 629 | Payload (EAP Req/Id, CBORArray[0,1,2]) | 630 1) |<----------------------------------------| 631 | 2.01 Created Location-Path [/a/y] | 632 | Payload (EAP Resp/Id, CBORArray[0]) | 633 2) |---------------------------------------->| 634 ... 636 Figure 8: cipher suite negotiation 638 In case there is no CBOR array stating the cipher suites, the default 639 cipher suites are applied. If the Controller sends a restricted list 640 of cipher suites that is willing to accept it MUST include the 641 default value 0 since it is mandatory to implement. The IoT device 642 will have at least that option available. 644 The cipher suite requirements are inherited from the ones established 645 by OSCORE. By default, the HKDF algorithm is SHA-256 and the AEAD 646 algorithm is AES-CCM-16-64-128. Both are mandatory to implement. 647 The other cipher suites supported and negotiated in the cipher suite 648 negotiation are the following: 650 0. AES-CCM-16-64-128, SHA-256 (default) 652 1. A128GCM, SHA-256 654 2. A256GCM, SHA-384 656 3. ChaCha20/Poly1305, SHA-256 658 4. ChaCha20/Poly1305, SHAKE256 660 This specification uses the (HMAC)-based key derivation function 661 (HKDF) defined in [RFC5869] to derive the necessary key material. 662 Since the key derivation process uses the MSK, which is considered 663 fresh key material, we will use the HKDF-Expand function, which we 664 will shorten here as KDF. 666 5.2. Deriving the OSCORE Security Context 668 The derivation of the security context for OSCORE allows securing the 669 communication between the IoT device and the Controller once the MSK 670 has been exported providing, confidentiality, integrity, key 671 confirmation (Steps 7 and 8), and detecting a downgrading attack. 673 The Master Secret can be derived by using the chosen cipher suite and 674 the KDF. The Master Secret can be derived as follows: 676 Master Secret = KDF(MSK, CS | "COAP-EAP OSCORE MASTER SECRET", 677 length) 679 where: 681 * The algorithms for OSCORE are agreed in the cipher suite 682 negotiation. 684 * The MSK is exported by the EAP method. Discussion about the use 685 of the MSK for the key derivation is done in Section 7. 687 * CS is the concatenation of the content of the cipher suite 688 negotiation, that is, the list of cipher suites sent by the 689 Controller (Step 1) the selected option by the IoT device (Step 690 2). If any of the messages did not contain the CBOR array 691 (default algorithms), the null string is used. 693 * "COAP-EAP OSCORE MASTER SECRET" is the ASCII code representation 694 of the non-NULL terminated string (excluding the double quotes 695 around it). 697 * CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated. 699 * length is the size of the output key material. 701 The Master Salt, similarly to the Master Secret, can be derived as 702 follows: 704 Master Salt = KDF(MSK, CS | "OSCORE MASTER SALT", length) 706 where: 708 * The algorithms are agreed upon in the cipher suite negotiation. 710 * The MSK is exported by the EAP method. Discussion about the use 711 of the MSK for the key derivation is done in Section 7. 713 * CS is the concatenation of the content of the cipher suite 714 negotiation, in the request and response. If any of the messages 715 did not contain the CBOR array, the null string is used. 717 * "OSCORE MASTER SALT" is the ASCII code representation of the non- 718 NULL-terminated string (excluding the double quotes around it). 720 * CS and "COAP-EAP OSCORE MASTER SECRET" are concatenated. 722 * length is the size of the output key material. 724 Since the MSK is used to derive the Master Key, the correct 725 verification of the OSCORE protected request (Step 7) and response 726 (Step 8) confirms the Controller and the IoT device have the same 727 Master Secret, achieving key confirmation. 729 To prevent a downgrading attack, the content of the cipher suites 730 negotiation (which we refer to here as CS) is embedded in the Master 731 Secret derivation. If an attacker changes the value of the cipher 732 suite negotiation, the result will be different OSCORE security 733 contexts, that ends up with a failure in Step 7 and 8. 735 The Controller will use the Recipient ID of the IoT device (RID-I) as 736 Sender ID for its OSCORE Sender Context. The IoT device will use 737 this value as Recipient ID for its Recipient Context. 739 The IoT device will use the Recipient ID of the Controller (RID-C) as 740 Sender ID for its OSCORE Sender Context. The Controller will use 741 this value as Recipient ID for its Recipient Context. 743 6. Discussion 745 6.1. CoAP as EAP lower layer 747 This section discusses the suitability of the CoAP protocol as EAP 748 lower layer, and reviews the requisites imposed by the EAP protocol 749 on any protocol that transports EAP. What EAP expects from its lower 750 layers can be found in section 3.1 of [RFC3748], which is elaborated 751 next: 753 Unreliable transport. EAP does not assume that lower layers are 754 reliable but it can benefit from a reliable lower layer. In this 755 sense, CoAP provides a reliability mechanism (e.g. through the use 756 of Confirmable messages). 758 Lower layer error detection. EAP relies on lower layer error 759 detection (e.g., CRC, Checksum, MIC, etc.). CoAP goes on top of UDP/ 760 TCP which provides a checksum mechanism over its payload. 762 Lower layer security. EAP does not require security services from 763 the lower layers. 765 Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 766 octets or greater. CoAP assumes an upper bound of 1024 for its 767 payload which covers the requirements of EAP. 769 Ordering guarantees. EAP relies on lower layer ordering guarantees 770 for correct operation. Regarding message ordering, every time a new 771 message arrives at the authentication service hosted by the IoT 772 device, a new resource is created and this is indicated in a "2.01 773 Created" response code along with the name of the new resource via 774 Location-Path or Location-Query. This way the application shows that 775 its state has advanced. Although the [RFC3748] states: "EAP provides 776 its own support for duplicate elimination and retransmission", EAP is 777 also reliant on lower layer ordering guarantees. In this regard, 778 [RFC3748] talks about possible duplication and says: "Where the lower 779 layer is reliable, it will provide the EAP layer with a non- 780 duplicated stream of packets. However, while it is desirable that 781 lower layers provide for non-duplication, this is not a requirement". 782 CoAP is providing a non-duplicated stream of packets and accomplish 783 the "desirable" non-duplication. In addition, [RFC3748] says that 784 when EAP runs over a reliable lower layer "the authenticator 785 retransmission timer SHOULD be set to an infinite value, so that 786 retransmissions do not occur at the EAP layer." 788 6.2. Size of the EAP lower layer vs EAP method size 790 Regarding the impact that an EAP lower layer will have on the total 791 byte size of the whole exchange, there is a comparison with another 792 network layer based EAP lower layer, PANA [RFC5191], in [coap-eap]. 793 Comparing the EAP lower layer (alone) and taking into account EAP. 794 On the one hand, at the EAP lower layer level, the usage of CoAP 795 gives important benefits. On the other hand, when taking into 796 account the EAP method overload, this reduction is less but still 797 significant if the EAP method generates large EAP messages. If the 798 EAP method is very taxing, the impact of the reduction in the size of 799 the EAP lower layer is less significant. This leads to the 800 conclusion that possible next steps in this field could be designing 801 new EAP methods that can be better adapted to the requirements of IoT 802 devices and networks. For example, authors in [coap-eap] used EAP- 803 PSK as an example, since it only involves 4 messages and their length 804 can be less than 60 bytes. Moreover, it only uses symmetric 805 cryptography. 807 However, the impact of the EAP lower layer itself cannot be ignored, 808 hence the proposal of using CoAP as a lightweight protocol for this 809 purpose. Other EAP methods such as EAP-AKA'[RFC5448] or new EAP 810 methods such as EAP-NOOB [I-D.ietf-emu-eap-noob] or EAP-EDHOC 811 [I-D.ingles-eap-edhoc] that can benefit, as well as new ones that may 812 be proposed in the future with IoT constraints in mind, from a CoAP- 813 based EAP lower layer. 815 7. Security Considerations 817 There are some aspects to be considered such as how authorization is 818 managed, the use of MSK as keying material and how the trust in the 819 Controller is established. Additional considerations such as EAP 820 channel binding as per [RFC6677] are also discussed here. 822 7.1. Authorization 824 Authorization is part of bootstrapping. It serves to establish 825 whether the node can join and the set of conditions it has to adhere 826 to. The authorization data will be gathered from the organization 827 that is responsible for the IoT device and sent to the EAP 828 authenticator in case of AAA infrastructure is deployed. 830 In standalone mode, the authorization information will be in the 831 Controller. If the pass-through mode is used, authorization data 832 received from the AAA server can be delivered by the AAA protocol 833 (e.g. RADIUS or Diameter). Providing more fine-grained 834 authorization data can be with the transport of SAML in RADIUS 835 [RFC7833]. 837 After bootstrapping, additional authorization information to operate 838 in the security domain, e.g., access services offered by other nodes, 839 can be taken care of by the solutions proposed in the ACE WG. 841 7.2. Freshness of the key material 843 In CoAP-EAP there is no nonce exchange to provide freshness to the 844 keys derived from the MSK. The MSK and Extended Master Session Key 845 (EMSK) keys according to the EAP Key Management Framework [RFC5247] 846 are fresh key material. Since only one authentication is established 847 per EAP authenticator, there is no need for generating additional key 848 material. In case a new MSK is required, a re-authentication can be 849 done, by running the process again, or using a more lightweight EAP 850 method to derive additional key material as elaborated in 851 Section 3.3. 853 7.3. Channel Binding support 855 According to the [RFC6677], channel binding related to EAP, is sent 856 through the EAP method that supports it. 858 To satisfy the requirements of the document, we need to send the EAP 859 lower layer identifier (To be assigned by IANA), in the EAP Lower- 860 Layer Attribute if RADIUS is used. 862 7.4. Additional Security Consideration 864 In the process of authentication, there is a possibility of an entity 865 forging messages to generate a denial of service (DoS) attacks on any 866 of the entities involved. For instance, an attacker can forge 867 multiple initial messages to start an authentication (Step 0) with 868 the Controller as if they were sent by different IoT devices. 869 Consequently, the Controller will start an authentication per each 870 message received in Step 0, sending the EAP Request/Id (Step 1). 872 To minimize the effects of this DoS attack, it is RECOMMENDED that 873 the Controller limits the rate at which it processes incoming 874 messages in Step 0 to provide robustness against denial of service 875 (DoS) attacks. The details of rate limiting are outside the scope of 876 this specification. Nevertheless, the rate of these messages is also 877 limited by the bandwidth available between the IoT device and the 878 Controller. This bandwidth will be especially limited in constrained 879 links (e.g., LPWAN). Lastly, it is also RECOMMENDED to reduce at a 880 minimum the state in the Controller at least until the EAP Response/ 881 Ids received by the Controller. 883 Other security-related concerns can be how to ensure that the IoT 884 device joining the security domain can in fact trust the Controller. 885 This issue is elaborated in the EAP Key Management Framework 886 [RFC5247]. In particular, the IoT device knows it can trust the 887 Controller because the key that is used to establish the security 888 association is derived from the MSK. If the Controller has the MSK, 889 it is clear the AAA Server of the node trusted the Controller, which 890 can be considered as a trusted party. 892 8. IANA Considerations 894 Considerations for IANA regarding this document: 896 * Assignment of EAP lower layer identifier. 898 * Assignment of the URI /.well-known/coap-eap 900 * Assignment of the media type "application/coap-eap" 902 * Assignment of the content format "application/coap-eap" 904 * Assignment of the resource type (rt=) "core.coap-eap" 905 * Assignment of the numbers assigned for the cipher suite 906 negotiation 908 * Assignment of the numbers assigned for the numbers of the CBOR 909 object in CoAP-EAP 911 9. Acknowledgments 913 We would like to thank as the reviewers of this work: Carsten 914 Bormann, Mohit Sethi, Benjamin Kaduk, Christian Amsuss, John 915 Mattsson, Goran Selander, Alexandre Petrescu, Pedro Moreno-Sanchez 916 and Eduardo Ingles-Sanchez. 918 We would also like to thank Gabriel Lopez-Millan for the first review 919 of this document and we would like to thank Ivan Jimenez-Sanchez for 920 the first proof-of-concept implementation of this idea. 922 And thank for their valuable comments to Alexander Pelov and Laurent 923 Toutain, especially for the potential optimizations of CoAP-EAP. 925 10. References 927 10.1. Normative References 929 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 930 Requirement Levels", BCP 14, RFC 2119, 931 DOI 10.17487/RFC2119, March 1997, 932 . 934 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 935 Levkowetz, Ed., "Extensible Authentication Protocol 936 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 937 . 939 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 940 Authentication Protocol (EAP) Key Management Framework", 941 RFC 5247, DOI 10.17487/RFC5247, August 2008, 942 . 944 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 945 Key Derivation Function (HKDF)", RFC 5869, 946 DOI 10.17487/RFC5869, May 2010, 947 . 949 [RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel- 950 Binding Support for Extensible Authentication Protocol 951 (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, 952 . 954 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 955 Application Protocol (CoAP)", RFC 7252, 956 DOI 10.17487/RFC7252, June 2014, 957 . 959 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 960 Bose, "Constrained Application Protocol (CoAP) Option for 961 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 962 August 2016, . 964 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 965 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 966 May 2017, . 968 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 969 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 970 Application Protocol) over TCP, TLS, and WebSockets", 971 RFC 8323, DOI 10.17487/RFC8323, February 2018, 972 . 974 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 975 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 976 . 978 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 979 "Object Security for Constrained RESTful Environments 980 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 981 . 983 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 984 Representation (CBOR)", STD 94, RFC 8949, 985 DOI 10.17487/RFC8949, December 2020, 986 . 988 10.2. Informative References 990 [coap-eap] Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP- 991 Based Bootstrapping Service for the Internet of Things - 992 https://www.mdpi.com/1424-8220/16/3/358", March 2016. 994 [eap-framework] 995 Sethi, M. and T. Aura, "Secure Network Access 996 Authentication for IoT Devices: EAP Framework vs. 997 Individual Protocols - 998 https://ieeexplore.ieee.org/document/9579387", October 999 2021. 1001 [I-D.ietf-ace-oauth-authz] 1002 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1003 H. Tschofenig, "Authentication and Authorization for 1004 Constrained Environments (ACE) using the OAuth 2.0 1005 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 1006 draft-ietf-ace-oauth-authz-36, 16 November 2020, 1007 . 1010 [I-D.ietf-core-resource-directory] 1011 Amsüss, C., Shelby, Z., Koster, M., Bormann, C., and P. 1012 Van der Stok, "CoRE Resource Directory", Work in Progress, 1013 Internet-Draft, draft-ietf-core-resource-directory-28, 7 1014 March 2021, . 1017 [I-D.ietf-emu-eap-noob] 1018 Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band 1019 authentication for EAP (EAP-NOOB)", Work in Progress, 1020 Internet-Draft, draft-ietf-emu-eap-noob-05, 12 July 2021, 1021 . 1024 [I-D.ingles-eap-edhoc] 1025 Sanchez, E., Garcia-Carrillo, D., and R. Marin-Lopez, "EAP 1026 method based on EDHOC Authentication", Work in Progress, 1027 Internet-Draft, draft-ingles-eap-edhoc-01, 2 November 1028 2020, . 1031 [lo-coap-eap] 1032 Garcia-Carrillo, D., Marin-Lopez, R., Kandasamy, A., and 1033 A. Pelov, "A CoAP-Based Network Access Authentication 1034 Service for Low-Power Wide Area Networks: LO-CoAP-EAP - 1035 https://www.mdpi.com/1424-8220/17/11/2646", November 2017. 1037 [RFC4137] Vollbrecht, J., Eronen, P., Petroni, N., and Y. Ohba, 1038 "State Machines for Extensible Authentication Protocol 1039 (EAP) Peer and Authenticator", RFC 4137, 1040 DOI 10.17487/RFC4137, August 2005, 1041 . 1043 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 1044 Pre-Shared Key Extensible Authentication Protocol (EAP) 1045 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 1046 . 1048 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1049 and A. Yegin, "Protocol for Carrying Authentication for 1050 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1051 May 2008, . 1053 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1054 Extensible Authentication Protocol Method for 3rd 1055 Generation Authentication and Key Agreement (EAP-AKA')", 1056 RFC 5448, DOI 10.17487/RFC5448, May 2009, 1057 . 1059 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1060 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1061 January 2012, . 1063 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., 1064 "EAP Extensions for the EAP Re-authentication Protocol 1065 (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012, 1066 . 1068 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 1069 DOI 10.17487/RFC6762, February 2013, 1070 . 1072 [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A 1073 RADIUS Attribute, Binding, Profiles, Name Identifier 1074 Format, and Confirmation Methods for the Security 1075 Assertion Markup Language (SAML)", RFC 7833, 1076 DOI 10.17487/RFC7833, May 2016, 1077 . 1079 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., 1080 Richardson, M., Jiang, S., Lemon, T., and T. Winters, 1081 "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1082 RFC 8415, DOI 10.17487/RFC8415, November 2018, 1083 . 1085 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 1086 Context Header Compression (SCHC) for the Constrained 1087 Application Protocol (CoAP)", RFC 8824, 1088 DOI 10.17487/RFC8824, June 2021, 1089 . 1091 [TS133.501] 1092 ETSI, "5G; Security architecture and procedures for 5G 1093 System - TS 133 501 V15.2.0 (2018-10)", 2018. 1095 Appendix A. Flow of operation (DTLS establishment) 1097 CoAP-EAP makes possible to derive a PSK for (D)TLS to allow PSK-based 1098 authentication between the IoT device and the Controller. In the 1099 instance of using (D)TLS to establish a security association, there 1100 is a limitation to the use of intermediaries between the IoT device 1101 and the Controller, as (D)TLS breaks the end-to-end communications 1102 when using intermediaries such as proxies. 1104 IoT device Controller 1105 ------------- ------------- 1106 ... 1107 | 2.01 Created Location-Path [/a/w] | 1108 | Payload (EAP-X Resp) | 1109 6)|---------------------------------------->| 1110 | | MSK 1111 | (D)TLS 1.3 Client Hello | | 1112 MSK 7) |<----------------------------------------| V 1113 | | | DTLS_PSK 1114 V |===============DTLS hanshake=============| 1115 DTLS_PSK | | 1116 *... 1117 (*) Protected with (D)TLS 1119 Figure 9: CoAP-EAP flow of operation with DTLS 1121 Figure 9 shows the last steps of the operation for CoAP-EAP when 1122 (D)TLS is used to protect the communication between the IoT device 1123 and the Controller using the keying material exported by the EAP 1124 authentication. The general flow is essentially the same as in the 1125 case of OSCORE, except that DTLS negotiation is established in Step 1126 7). Once DTLS negotiation has finished successfully the IoT device 1127 is granted access to the domain. Step 7 MUST be interpreted by the 1128 IoT device as an alternate success indication, which will end up with 1129 the MSK and the DTLS_PSK derivation for the (D)TLS authentication 1130 based on PSK. 1132 According to [RFC8446] the provision of the PSK out-of-band also 1133 requires the provision of the KDF hash algorithm and the PSK 1134 identity. To simplify the design in CoAP-EAP, the KDF hash algorithm 1135 can be included in the list of cipher suites exchange in Step 1 and 1136 Step 2 if DTLS wants to be used instead of OSCORE. For the same 1137 reason, the PSK identity is derived from (RID-C) (RID-I) as defined 1138 in Appendix A.2. 1140 A.1. Cryptographic suite negotiation for DTLS 1142 It is also possible to derive a pre-shared key for DTLS to establish 1143 a DLTS security association after a successful EAP authentication. 1144 Analogously to how the cipher suite is negotiated for OSCORE 1145 Section 5.1, the Controller sends a list, in decreasing order of 1146 preference, with the identifiers of the cipher suites supported (Step 1147 1). In the response, the IoT device sends the choice. 1149 This list is included in the payload after the EAP message with a 1150 CBOR array that contains the cipher suites. This CBOR array is 1151 enclosed as one of the elements of the CBOR Object used for 1152 transporting information in CoAP-EAP (See Section 4. An example of 1153 how the fields are arranged in the CoAP payload can be seen in 1154 Figure 7. 1156 In case there is no CBOR array stating the cipher suites, the default 1157 cipher suites are applied. If the Controller sends a restricted list 1158 of cipher suites that is willing to accept it MUST include the 1159 default value 0 since it is mandatory to implement. The IoT device 1160 will have at least that option available. 1162 The cipher suites are the following: 1164 3. TLS_SHA256 1166 4. TLS_SHA384 1168 5. TLS_SHA512 1170 A.2. Deriving DTLS PSK and identity 1172 To enable DTLS after an EAP authentication using the key material 1173 generated, we define the Identity and the PSK for DTLS. The Identity 1174 in this case is generated by concatenating the exchanged Sender ID 1175 and the Recipient ID. 1177 CoAP-EAP PSK Identity = RID-C || RID-I 1179 It is also possible to derive a pre-shared key for DTLS [RFC6347], 1180 refereed to here as "DTLS PSK", from the MSK between both IoT device 1181 and Controller if required. The length of the DTLS PSK will depend 1182 on the cipher suite. To have keying material with sufficient length 1183 a key of 32 bytes is derived that can be later truncated if needed: 1185 DTLS PSK = KDF(MSK, "CoAP-EAP DTLS PSK", length). 1187 where: 1189 * MSK is exported by the EAP method. 1191 * "CoAP-EAP DTLS PSK" is the ASCII code representation of the non- 1192 NULL terminated string (excluding the double quotes around it). 1194 * length is the size of the output key material. 1196 Appendix B. Examples of Use Case Scenario 1198 For a IoT device to act as a trustworthy entity within a security 1199 domain, certain key material is needed to be shared between the IoT 1200 device and the Controller. 1202 Next, we elaborate on examples of different use case scenarios about 1203 the usage of CoAP-EAP. Generally, we are dealing with 4 entities: 1205 * 2 nodes (A and B), which are IoT devices. They are the EAP peers. 1207 * 1 controller (C). The controller manages a domain where nodes can 1208 be deployed. It can be considered a more powerful machine than 1209 the IoT devices. 1211 * 1 AAA server (AAA) - Optional. The AAA is an Authentication, 1212 Authorization and Accounting Server, which is not constrained. 1213 Here, the Controller acts as EAP authenticator in pass-through 1214 mode. 1216 Generally, any IoT device wanting to join the domain managed by the 1217 Controller MUST perform a CoAP-EAP authentication with the Controller 1218 (C). This authentication MAY involve an external AAA server. This 1219 means that A and B, once deployed, will run CoAP-EAP once, as a 1220 bootstrapping phase, to establish a security association with C. 1221 Moreover, any other entity, which wants to join and establish 1222 communications with nodes under C's domain must also do the same. By 1223 using EAP, we can have the flexibility of having different types of 1224 credentials. For instance, if we have a device that is not battery 1225 dependent, and not very constrained, we could use a heavier 1226 authentication method. With varied IoT devices and networks we might 1227 need to resort to more lightweight authentication methods (e.g., EAP- 1228 NOOB[I-D.ietf-emu-eap-noob], EAP-AKA'[RFC5448], EAP-PSK[RFC4764], 1229 EAP-EDHOC[I-D.ingles-eap-edhoc], etc.) being able to adapt to 1230 different types of devices according to organization policies or 1231 devices capabilities. 1233 B.1. Example 1: CoAP-EAP in ACE 1235 In ACE, the process of Client registration and provisioning of 1236 credentials to the client is not specified. The process of Client 1237 registration and provisioning can be achieved using CoAP-EAP. Once 1238 the process of authentication with EAP is completed, fresh key 1239 material is shared between the IoT device and the Controller. In 1240 this instance, the Controller and the Authorization Server (AS) of 1241 ACE can be co-located. 1243 Next, we exemplify how CoAP-EAP can be used to perform the Client 1244 registration in a general way, to allow two IoT devices (A and B) to 1245 communicate and interact after a successful client registration. 1247 Node A wants to communicate with node B (e.g. to activate a light 1248 switch). The overall process is divided into three phases. Let's 1249 start with node A. In the first phase, the node A (EAP peer) does 1250 not yet belong to Controller C's domain. Then, it communicates with 1251 C (EAP authenticator) and authenticates with CoAP-EAP, which, 1252 optionally, communicates with the AAA server to complete the 1253 authentication process. If the authentication is successful, a fresh 1254 MSK is shared between C and node A. This key material allows node A 1255 to establish a security association with the C. Some authorization 1256 information may be also provided in this step. In case EAP is used 1257 in standalone mode, the AS itself having information about the 1258 devices can be the entity providing said authorization information. 1259 If authentication and authorization are correct, node A is enrolled 1260 in controller C's domain for a period of time. In particular, 1261 [RFC5247] recommends 8 hours, though the the entity providing the 1262 authorization information can establish this lifetime. In the same 1263 manner, B needs to perform the same process with CoAP-EAP to be part 1264 of the controller C's domain. 1266 In the second phase, when node A wants to talk with node B, it 1267 contacts controller C for authorization to access node B and obtain 1268 all the required information to do that securely (e.g. keys, tokens, 1269 authorization information, etc.). This phase does NOT require the 1270 usage of CoAP-EAP. The details of this phase are out-of-scope of 1271 this document, and the ACE framework is used for this purpose 1272 [I-D.ietf-ace-oauth-authz]. 1274 In the third phase, the node A can access node B with the credentials 1275 and information obtained from the controller C in the second phase. 1276 This access can be repeated without contacting the controller, while 1277 the credentials given to A are still valid. The details of this 1278 phase are out-of-scope of this document. 1280 It is worth noting that first phase with CoAP-EAP is required to join 1281 the controller C's domain. Once it is performed with success, the 1282 communications are local to the controller C's domain and there is no 1283 need to perform a new EAP authentication as long as the key material 1284 is still valid. When the keys are about to expire, the IoT device 1285 can engage in a re-authentication as explained in Section 3.3, to 1286 renew the key material. 1288 B.2. Example 2: Multi-domain with AAA infrastructures 1290 We assume we have a device (A) of the domain acme.org, which uses a 1291 specific kind of credential (e.g., AKA) and intends to join the um.es 1292 domain. This user does not belong to this domain, for which first it 1293 performs a client registration using CoAP-EAP. For this, it 1294 interacts with the controller's domain acting as EAP authenticator, 1295 which in turn communicates with a AAA infrastructure (acting as AAA 1296 client). Through the local AAA server to communicate with the home 1297 AAA server to complete the authentication and integrate the device as 1298 a trustworthy entity into the domain of controller C. In this 1299 scenario, the AS under the role of the Controller receives the key 1300 material from the AAA infrastructure 1302 B.3. Example 3: Single domain with AAA infrastructure 1304 A University Campus, we have several Faculty buildings and each one 1305 has its own criteria or policies in place to manage IoT devices under 1306 an AS. All buildings belong to the same domain (e.g., um.es). All 1307 these buildings are managed with a AAA infrastructure. A new device 1308 (A) with credentials from the domain (e.g., um.es) will be able to 1309 perform the device registration with a Controller (C) of any building 1310 as long as they are managed by the same general domain. 1312 B.4. Example 4: Single domain without AAA infrastructure 1314 In another case, without a AAA infrastructure, we have a Controller 1315 that has co-located the EAP server and using EAP standalone mode we 1316 can manage all the devices within the same domain locally. Client 1317 registration of a node (A) with Controller (C) can also be performed 1318 in the same manner. 1320 B.5. Other use cases 1321 B.5.1. CoAP-EAP for network access control 1323 One of the first steps for an IoT device life-cycle is to perform the 1324 authentication to gain access to the network. To do so, the device 1325 first has to be authenticated and granted authorization to gain 1326 access to the network. Additionally, security parameters such as 1327 credentials can be derived from the authentication process allowing 1328 the trustworthy operation of the IoT device in a particular network 1329 by joining the security domain. By using EAP, we are able to achieve 1330 this with flexibility and scalability, because of the different EAP 1331 methods available and the ability to rely on AAA infrastructures if 1332 needed to support multi-domain scenarios, which is a key feature when 1333 the IoT devices deployed under the same security domain, belong to 1334 different organizations. Given that EAP is also used for network 1335 access control, we can adapt this service for other technologies. 1336 For instance, to provide network access control to very constrained 1337 technologies (e.g., LoRa network). Authors in [lo-coap-eap] provide 1338 an study of a minimal version of CoAP-EAP for LPWAN networks with 1339 interesting results. In this specific case, we could leverage the 1340 compression by SCHC for CoAP [RFC8824]. 1342 B.5.2. CoAP-EAP for service authentication 1344 It is not uncommon that the infrastructure where the device is 1345 deployed and the services of the IoT device are managed by different 1346 organizations. Therefore, in addition to the authentication for 1347 network access control, we have to consider the possibility of a 1348 secondary authentication to access different services. This process 1349 of authentication, for example, will provide with the necessary key 1350 material to establish a secure channel and interact with the entity 1351 in charge of granting access to different services. In 5G, for 1352 example, consider a primary and secondary authentication using EAP 1353 [TS133.501]. 1355 Authors' Addresses 1357 Rafa Marin-Lopez 1358 University of Murcia 1359 Campus de Espinardo S/N, Faculty of Computer Science 1360 30100 Murcia 1361 Spain 1362 Phone: +34 868 88 85 01 1363 Email: rafa@um.es 1364 Dan Garcia-Carrillo 1365 University of Oviedo 1366 Calle Luis Ortiz Berrocal S/N, Edificio Polivalente 1367 33203 Gijon Asturias 1368 Spain 1369 Email: garciadan@uniovi.es