idnits 2.17.1 draft-ietf-ace-wg-coap-eap-03.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: ---------------------------------------------------------------------------- No issues found here. 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 (26 July 2021) is 999 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) == Missing Reference: '0x6af5' is mentioned on line 396, but not defined == Missing Reference: '0x7654' is mentioned on line 569, but not defined == Missing Reference: '0x8694' is mentioned on line 299, but not defined == Missing Reference: '0x9869' is mentioned on line 310, but not defined == Missing Reference: '0x7811' is mentioned on line 319, but not defined -- Looks like a reference, but probably isn't: '0' on line 572 -- Looks like a reference, but probably isn't: '1' on line 567 -- Looks like a reference, but probably isn't: '2' on line 567 ** 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 (~~), 9 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: 27 January 2022 University of Oviedo 6 26 July 2021 8 EAP-based Authentication Service for CoAP 9 draft-ietf-ace-wg-coap-eap-03 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 primer goals is to authenticate a CoAP-enabled device (EAP peer) that 18 intends to join a security domain managed by a domain 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. This document also provides 23 guidelines on how to generate key material for other types of 24 security associations. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 27 January 2022. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2. General Architecture . . . . . . . . . . . . . . . . . . . . 4 62 3. CoAP-EAP Operation . . . . . . . . . . . . . . . . . . . . . 4 63 3.1. General flow of operation . . . . . . . . . . . . . . . . 4 64 3.2. Error handling . . . . . . . . . . . . . . . . . . . . . 8 65 3.2.1. Non-responding endpoint . . . . . . . . . . . . . . . 8 66 3.2.2. Messages with /.well-known/a . . . . . . . . . . . . 8 67 3.3. Managing the State of the Service . . . . . . . . . . . . 10 68 3.3.1. Deleting the state . . . . . . . . . . . . . . . . . 10 69 3.3.2. Reauthentication . . . . . . . . . . . . . . . . . . 11 70 4. Cryptosuite negotiation and key derivation . . . . . . . . . 11 71 4.1. Cryptographic suite negotiation . . . . . . . . . . . . . 12 72 4.2. Deriving the OSCORE Security Context . . . . . . . . . . 14 73 4.3. Deriving DTLS PSK . . . . . . . . . . . . . . . . . . . . 16 74 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 5.1. CoAP as EAP lower layer . . . . . . . . . . . . . . . . . 17 76 5.2. Size of the EAP lower layer vs EAP method size . . . . . 18 77 5.3. Controller as the CoAP Client . . . . . . . . . . . . . . 18 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 79 6.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 80 6.2. Freshness of the key material . . . . . . . . . . . . . . 19 81 6.3. Channel Binding support . . . . . . . . . . . . . . . . . 19 82 6.4. Additional Security Consideration . . . . . . . . . . . . 20 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 84 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 9.2. Informative References . . . . . . . . . . . . . . . . . 21 88 Appendix A. Examples of Use Case Scenario . . . . . . . . . . . 23 89 A.1. Example 1: CoAP-EAP in ACE . . . . . . . . . . . . . . . 24 90 A.2. Example 2: Multi-domain with AAA infrastructures . . . . 25 91 A.3. Example 3: Single domain with AAA infrastructure . . . . 26 92 A.4. Example 4: Single domain without AAA infrastructure . . . 26 93 A.5. Other use cases . . . . . . . . . . . . . . . . . . . . . 26 94 A.5.1. CoAP-EAP for network access control . . . . . . . . . 26 95 A.5.2. CoAP-EAP for service authentication . . . . . . . . . 27 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 99 1. Introduction 101 This document specifies an authentication service that uses the 102 Extensible Authentication Protocol (EAP) [RFC3748] and is built on 103 top of the Constrained Application Protocol (CoAP) [RFC7252] called 104 CoAP-EAP. CoAP-EAP allows authenticating two CoAP endpoints by using 105 EAP, and to establish an OSCORE security association between them. 107 More specifically, this document specifies how CoAP can be used as a 108 constrained, link-layer independent, EAP lower layer [RFC3748] to 109 transport EAP messages between a CoAP server (acting as EAP peer) and 110 a CoAP client (acting as EAP authenticator) using CoAP messages. The 111 CoAP client has the option of contacting a backend AAA infrastructure 112 to complete the EAP negotiation as described in the EAP specification 113 [RFC3748]. 115 EAP methods transported in CoAP MUST generate cryptographic material 116 [RFC5247]. This way, CoAP messages are protected after the 117 authentication. After CoAP-EAP's operation, Object Security for 118 Constrained RESTful Environments (OSCORE) is established between 119 endpoints of the service. In addition, using the key material 120 derived from the authentication, this document specifies how to 121 establish other types of security associations: 123 * An OSCORE [RFC8613] security association is established based on 124 the cryptographic material generated from the EAP authentication. 126 * A DTLS security association MAY be established using the exported 127 cryptographic material after a successful EAP authentication. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119] [RFC8174] 134 when, and only when, they appear in all capitals, as shown here. 136 Readers are expected to be familiar with the terms and concepts of 137 described in CoAP [RFC7252], EAP [RFC3748]and OSCORE [RFC8613]. 139 2. General Architecture 141 Figure 1 illustrates the architecture defined in this document. 142 Basically, an IoT device, acting as the EAP peer, wants to be 143 authenticated by using EAP to join a domain that is managed by a 144 Controller (EAP authenticator). The IoT device will act a CoAP 145 server for this service, and the EAP authenticator as a CoAP client. 146 The rationale behind this decision, as expanded later, is that EAP 147 requests go always from the EAP server to the EAP peer. Accordingly, 148 the EAP responses go from the EAP peer to the EAP 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 IoT device Controller 156 +------------+ +------------+ 157 | EAP peer/ | | EAP auth./ | 158 | CoAP server|+------+| CoAP client| 159 +------------+ CoAP +------------+ 161 Figure 1: CoAP-EAP Architecture 163 3. CoAP-EAP Operation 165 The sequence flow can be seen in Figure 2. It shows how EAP-X, a 166 generic EAP method, is used as an authentication mechanism. 168 (NOTE: any EAP method that exports cryptographic material is valid. 169 For example, EAP-MD5 cannot be used since it does not export key 170 material). 172 3.1. General flow of operation 174 The first step to run CoAP-EAP is for the IoT device to discover the 175 Controller, and that it implements the CoAP-EAP service. To do so, 176 we can rely on any mechanism that allows us to perform this 177 discovery. For example, the discovery mechanism of CoAP. To access 178 the authentication service, this document defines the well-known URI 179 "/.well-known/a" (to be assigned by IANA). This URI is referring to 180 the authentication service that is present in both the IoT device and 181 the Controller. 183 For the rest of this section, the IoT device is referred to as the 184 EAP peer and the Controller as the EAP authenticator. 186 In the CoAP-EAP flow of operation, the EAP peer always starts the 187 authentication process by sending the first message. When the EAP 188 peer discovers the presence of the EAP authenticator and wants to 189 start the authentication, it sends a Non-Confirmable "POST /.well- 190 known/a" request (Step 0). This message will carry the option called 191 'No-Response' [RFC7967]. The rationale of this option is to avoid 192 waiting for a response that is not needed. So, the use of this 193 option will indicate to the EAP authenticator that the EAP peer is 194 ready to start the authentication process. 196 This message is the only instance where the EAP authenticator acts as 197 a CoAP server and the EAP peer as a CoAP client. After this, the 198 exchange continues with the EAP authenticator as a CoAP client and 199 the EAP peer as a CoAP server. A discussion about the CoAP roles is 200 in Section 5.3 202 Once the EAP authenticator is aware of the intention of the EAP peer 203 of starting an authentication process, sends a Confirmable "POST 204 /.well-known/a" request to the EAP peer(Step 1). After receiving the 205 first POST, the EAP peer (CoAP server) assigns a resource to the 206 ongoing authentication process, and answers with an Acknowledgment 207 with a piggybacked response containing the resource identifier in the 208 Location-Path (and/or Location-Query) Options (Step 2). The path 209 /.well-known/a at this point will not be used. The name of the 210 resource is selected by the CoAP server as it pleases. The only 211 condition is that both end points have to correctly process the 212 following message based on the selected value. As an example, the 213 CoAP server MAY follow the the naming "/a/x". Where "a" is the 214 general name of the authentication service; "x" represents the 215 resource established to process the following message of the 216 authentication. This naming, as example, will be used in the figures 217 of this document. The EAP peer (CoAP server) will only have one 218 authentication session with that particular EAP authenticator (CoAP 219 client) and it will not process EAP authentications in parallel (with 220 the same EAP authenticator) to save resources. 222 In this exchange (Step 1 and 2), the EAP-Request/Identity (EAP Req/ 223 Id) and EAP-Response/Identity (EAP Resp/Id) messages are exchanged 224 between the EAP authenticator and the EAP peer. Upon the reception 225 of the EAP Req/Id message, the EAP authenticator sends this message 226 to the EAP server. The EAP server is in charge of steering the 227 conversation, choosing the EAP method to be used (e.g. EAP-X). In 228 this exchange we can also see the cryptosuite negotiation. If the 229 cryptosuite is not sent, the default cryptosuite is used. The first 230 message (Step 1) carries, concatenated to the EAP Req/Id, a CBOR 231 array containing a list with the cryptosuites, and the CoAP server in 232 the next message will confirm by sending a choice. The details of 233 the cryptosuite negotiation are discussed in Section 4.1. 235 NOTE: Since only an ongoing EAP authentication is permitted per EAP 236 authenticator and EAP is a lock-step protocol, a CoAP Token of a 237 constant value can be used throughout the authentication process. An 238 empty Token MAY be considered to reduce bytes. 240 From now on, the EAP authenticator and the EAP peer will exchange EAP 241 packets related to the EAP method, transported in the CoAP message 242 payload (Steps 3,4,5,6). The EAP authenticator will use the POST 243 method in a Confirmable message to send EAP requests to the EAP peer. 244 The EAP peer will use a piggybacked response in the Acknowledgment 245 message to carry the EAP response. EAP requests and responses are 246 represented in Figure 2 using the nomenclature (EAP-X-Req n) and 247 (EAP-X-Resp n) respectively. 'X' indicates the EAP method use. 'n' 248 indicates the identifier of the EAP message, which is shown 249 monotonically increasing from 1 in this flow of operation. 251 When a Confirmable POST message arrives (e.g, /a/x) carrying an EAP 252 request message, if processed correctly, returns an EAP Response. 253 Along with the EAP response, a new resource is created (e.g, /a/y) 254 and the ongoing resource (i.e., /a/x) is erased. This EAP response 255 will go in a CoAP piggybacked response that will also indicate the 256 new resource in the Location-Path (and/or Location-Query) Options. 257 In case there is an error processing a legitimate message, the server 258 will return an (4.00 Bad Request). There is a discussion about error 259 handling in Section 3.2. 261 When the authentication is completed correctly, the EAP server sends 262 an EAP Success message, and both CoAP endpoints will share a Master 263 Session Key (MSK)[RFC5295]. 265 Using the MSK, an OSCORE security association is established between 266 EAP peer and EAP authenticator, which serves as key confirmation of 267 the MSK and to provide integrity and authentication to the last 268 exchange (Steps 7 and 8). From that point, any exchange between both 269 CoAP endpoints is protected with OSCORE. Before sending the EAP 270 success to the EAP peer, the EAP authenticator can derive the OSCORE 271 Security Context. The EAP peer can do so when it receives the 272 message containing the EAP success, and the session liftime, to 273 verify the message from the EAP authenticator and generate the answer 274 (Step 8). The establishment of the OSCORE Security Context is 275 discussed in Section 4.2. The Session Lifetime, in seconds, is 276 represented with a unsigned integer in a CBOR array. The disposition 277 of the information is the same to the cryptosuite negotiation () see 278 Section 4.1). 280 EAP peer EAP Auth. 281 (CoAP server) (CoAP client) 282 ------------- ------------- 283 | NON [0x6af5] POST /.well-known/a | 284 0) | Token (0xab), No-Response | 285 |---------------------------------------->| 286 | CON [0x7654] POST /.well-known/a | 287 | Token (0xac) | 288 | Payload (EAP Req/Id||Cryptosuite)| 289 1) |<----------------------------------------| 290 | ACK [0x7654] | 291 | Token (0xac) | 292 | 2.01 Created Location-Path [/a/x] | 293 | Payload (EAP Resp/Id||Cryptosuite) | 294 2) |---------------------------------------->| 295 | CON [0x8694] POST /a/x | 296 | Token (0xac) | 297 | Payload EAP-X-Req 1 | 298 3) |<----------------------------------------| 299 | ACK [0x8694] | 300 | Token (0xac) | 301 | 2.01 Created Location-Path [/a/y] | 302 | Payload EAP-X-Resp 1 | 303 4) |---------------------------------------->| 304 .... 306 | CON [0x9869] POST /a/y | 307 | Token (0xac) | 308 | Payload EAP-X-Req (n) | 309 5) |<----------------------------------------| 310 | ACK [0x9869] | 311 | Token (0xac) | 312 | 2.01 Created Location-Path [/a/z] | MSK 313 | Payload EAP-X-Resp (n) | | 314 6) |---------------------------------------->| v 315 | CON [0x7811] POST /a/z |OSCORE 316 | Token (0xac), OSCORE |CONTEXT 317 MSK | Payload (EAP success||Session-Lifetime) |(*) 318 | 7) |<----------------------------------------| 319 v | ACK [0x7811] | 320 OSCORE (*)| Token (0xac), OSCORE | 321 CONTEXT 8) |---------------------------------------->| 322 (*) Protected with OSCORE 324 Figure 2: CoAP-EAP flow of operation 326 3.2. Error handling 328 This section elaborates how different errors are handled, from a non- 329 responding endpoint, dealing lost messages and initial POST messages 330 arriving arriving out of place. 332 In general, the CoAP engine, in the client and server, will take care 333 of retransmissions, dealing with lost messages sent out of place, and 334 sending the errors when a client is trying to access a resource that 335 does not exist in the CoAP server. But, there are cases where the 336 messages can arrive out of place, and the CoAP engine may not 337 recognize them as old or as a retransmission, and send them to the 338 CoAP application. 340 3.2.1. Non-responding endpoint 342 When CoAP-EAP starts, a state is created that stores all information 343 related to the process. If by any reason one of the entities becomes 344 non-responding, the state should be only kept form a period of time 345 before it is removed. According to CoAP, EXCHANGE_LIFETIME considers 346 the time it takes until a client stops expecting a response to a 347 Confirmable request. A timer is reseted every time a message is 348 sent. If EXCHANGE_LIFETIME has passed waiting the next message, both 349 entities will delete the CoAP-EAP state if the authentication process 350 has not finished correctly. 352 3.2.2. Messages with /.well-known/a 354 The reception of messages containing /.well-known/a needs some 355 additional considerations, as the resource is always available in 356 both entities. This message can be sent out of the expected order by 357 the EAP peer as well as by the EAP authenticator for reasons such as 358 network delays. 360 When this message arrives to the other entity during an ongoing 361 authentication, and it is not recognized by the CoAP engine as an old 362 or retransmitted message, arriving to the CoAP-EAP application, we 363 describe the behavior depending on the entity receiving this message. 364 If this message is from the EAP authenticator to the peer, being a 365 Confirmable POST message, will honor the request and answer, in this 366 case with a CoAP Reset message, that will indicate that, since there 367 is an authentication ongoing, the EAP authenticator is not in 368 disposition of processing this message. This exchange is illustrated 369 in Figure 3. 371 EAP peer EAP Auth. 372 (CoAP server) . (CoAP client) 373 ------------- . ------------- 374 | | 375 | CON [0x7654] POST /.well-known/a | 376 | Token (0xac) | 377 | Payload (EAP Req/Id||Cryptosuite)| 378 |<----------------------------------------| 379 | | 380 | RST [0x7654] | 381 | 0.00 Code | 382 |---------------------------------------->| 384 Figure 3: /.well-known/a during ongoing authentication from the EAP 385 authenticator 387 In case the message goes from the EAP peer to the authenticator, 388 being a Non-confirmable POST message with the No-Response Option, 389 there is no need to further process this message, and can be silently 390 ignored. This exchange is illustrated in Figure 4. 392 EAP peer EAP Auth. 393 (CoAP server) . (CoAP client) 394 ------------- . ------------- 395 | | 396 | NON [0x6af5] POST /.well-known/a | 397 | Token (0xab), No-Response | 398 |---------------------------------------->| --+ 399 | . | | 400 | . | v 401 (Ignored) 403 Figure 4: /.well-known/a during ongoing authentication from the 404 EAP peer 406 When this message arrives to the CoAP-EAP application, and there is 407 no authentication ongoing it will understand that a new 408 authentication process is starting. In case the message goes from 409 the EAP authenticator to the peer, and no prior Non-confirmable 410 /.well-known/a message was sent by the EAP peer, it will send a Reset 411 message indicating that is not in disposition to process this 412 message, as it has to be the EAP peer the one to initiate the 413 process. This exchange is illustrated in Figure 5. 415 EAP peer EAP Auth. 416 (CoAP server) (CoAP client) 417 ------------- ------------- 418 | | 419 | CON [0x7654] POST /.well-known/a | 420 | Token (0xac) | 421 | Payload (EAP Req/Id||Cryptosuite)| 422 |<----------------------------------------| 423 | | 424 | RST [0x7654] | 425 | 0.00 Code | 426 |---------------------------------------->| 428 Figure 5: /.well-known/a with no ongoing authentication from the EAP 429 authenticator 431 If this message is from the EAP peer to the authenticator, receiving 432 a Non-confirmable /.well-known/a message, it will understand it as 433 the start of the process by the EAP peer, and start a normal process 434 of authentication as depicted in the general flow of operation in 435 Figure 2. 437 3.3. Managing the State of the Service 439 The management of the CoAP-EAP state, can be done in different ways. 440 The Controller MAY choose to delete it as explained in Section 3.3.1. 441 On the other hand, the IoT device may need to renew the CoAP-EAP 442 state because the key material is close to expire, as elaborated in 443 Section 3.3.2. 445 3.3.1. Deleting the state 447 There are situations where the current CoAP-EAP state might need to 448 be removed. For instance due to its expiration or a forced removal 449 if the IoT device needs to be expelled from the security domain. 450 This exchange is illustrated in Figure 6. If the Controller, which 451 implements the CoAP client in this exchange, deems necessary the 452 removal of the state, it can send a DELETE command to the CoAP 453 server, referencing the last CoAP-EAP state resource given by the 454 CoAP server, whose identifier will be the last one received with the 455 ACK of the EAP success message (/a/z in Figure 2) This message will 456 be protected with the OSCORE security association to prevent forgery. 457 Upon reception of this message, the CoAP server sends piggybacked 458 response to the client with the Code 2.02 Deleted, which is also 459 protected with the OSCORE security association. 461 EAP peer EAP Auth. 462 (CoAP server) (CoAP client) 463 ------------- ------------- 464 | | 465 | CON [0x7654] DELETE /a/z | 466 | Token (0xac) | 467 | OSCORE | 468 |<----------------------------------------| 469 | | 470 | ACK [0x7654] | 471 | Token (0xac) | 472 | 2.02 Deleted | 473 | OSCORE | 474 |---------------------------------------->| 476 Figure 6: Deleting state 478 If the ACK from the CoAP server does not arrive, after the maximum 479 retransmission attempts, the CoAP client will remove the state from 480 its side. 482 3.3.2. Reauthentication 484 When the CoAP-EAP state is close to expire, the IoT device MAY want 485 to start a re-authentication process to renew the state. Since the 486 initial authentication is usually taxing, it is assumed to be done 487 only once over a long period of time. If further EAP re- 488 authentications for refreshing the key material are necessary, there 489 are other methods that can be used to perform these re- 490 authentications. For example, the EAP re-authentication protocol 491 (ERP) [RFC6696], EAP-NOOB [I-D.ietf-emu-eap-noob], or EAP-AKA' 492 [RFC5448] MAY be used to avoid repeating the entire EAP exchange. 493 The message flow for the reauthentication will be exactly the same as 494 the one shown in Figure 2, using a more lightweight alternative to do 495 a re-authentication. While the re-authentication is ongoing, two 496 different CoAP-EAP states will be active. Once the reauthentication 497 is completed and OSCORE is exchanged using the newly derived key 498 material, the old CoAP-EAP state is deleted. If by any reason, the 499 reauthentication fails to complete, the old CoAP-EAP state will be 500 available until it expires. 502 4. Cryptosuite negotiation and key derivation 503 4.1. Cryptographic suite negotiation 505 How the cryptographic suite is selected is important. OSCORE runs 506 after the EAP authentication, using the cryptosuite selected in the 507 cryptosuite negotiation. To negotiate the cryptosuite, the protocol 508 follows a simple approach by sending in the first message from the 509 Controller, a list in decreasing order or preference, with the 510 identifiers of the supported cryptosuites. In the response to that 511 message, the IoT device sends a response with the choice. To do this 512 without resorting to the creation of a new CoAP option tailored to 513 this purpose, by leveraging the fact that in the payload it is always 514 expected at the beginning the EAP message, which by design specifies 515 its own length. Following the EAP message, optionally there is a 516 CBOR array that contains the cryptosuites. Be it the list of 517 cryptosuites supported by the Controller, or the one chosen by the 518 IoT device. An example of how the fields are arranged in the CoAP 519 payload can be seen in Figure 7. An example of the exchange with the 520 cryptosuite negotiation is shown in Figure 8, where can be 521 appreciated the disposition of both EAP-Request/Identity and 522 Response/Identity, followed by the CBOR array. It is worth noting 523 that the CBOR array is also expected in the EAP Success, containing 524 the Session Lifetime. 526 +-----+-----------+-------+------++------------+ 527 |Code |Identifier |Length |Data ||Cyphersuites| 528 +-----+-----------+-------+------++------------+ 529 EAP Packet CBOR Array 531 Figure 7: How the cypersuites are sent in the CoAP payload 533 EAP peer EAP Auth. 534 (CoAP server) (CoAP client) 535 ------------- ------------- 536 | | 537 | ... | 538 |---------------------------------------->| 539 | CON [0x7654] POST /.well-known/a | 540 | Token (0xac) | 541 | Payload (EAP Req/Id, CBORArray[0,1,2]) | 542 1) |<----------------------------------------| 543 | ACK [0x7654] | 544 | Token (0xac) | 545 | 2.01 Created Location-Path [/a/x] | 546 | Payload (EAP Resp/Id, CBORArray[0]) | 547 2) |---------------------------------------->| 548 ... 550 Figure 8: Cryptosuite negotition in t CoAP-EAP flow 552 In case there is no CBOR Array stating the cryptosuites, the default 553 cryptosuites are applied. If the Controller sends a restricted list 554 of cryptosuites that is willing to accept, and the ones supported by 555 the IoT device are not in that list, the IoT device will respond with 556 a 4.00 Bad Request, expressing in the Payload the cryptosuites 557 supported. Figure 9 illustrates this exchange. 559 EAP peer EAP Auth. 560 (CoAP server) (CoAP client) 561 ------------- ------------- 562 | | 563 | ... | 564 |---------------------------------------->| 565 | CON [0x7654] POST /.well-known/a | 566 | Token (0xac) | 567 | Payload (EAP Req/Id, CBORArray[1,2]) | 568 1) |<----------------------------------------| 569 | ACK [0x7654] | 570 | Token (0xac) | 571 | 4.00 Bad Request | 572 | Payload (CBORArray[0]) | 573 2) |---------------------------------------->| 575 Figure 9: Cryptosuite negotition failed 577 To avoid a downgrading attack, we will use the proposed cryptosuite 578 list and the choice in the key derivation process, to bind them to 579 the generated keys as explained in Section 4.2. 581 As a result of a successful EAP authentication, both the CoAP server 582 and CoAP client share a Master Session Key (MSK). The MSK is a fresh 583 key, so any key derived from the MSK will be also fresh. The CoAP- 584 EAP exchange finishes with the establishment of an OSCORE security 585 association for the CoAP-EAP service. The security level for the 586 CoAP-EAP exchanges with OSCORE is with integrity. Due to the 587 requirement of using OSCORE, the cryptosuite requirements are 588 inherited from the ones established by OSCORE. This requires for the 589 HKDF algorithm by default HKDF SHA-256 and the AEAD algorithm by 590 default AES-CCM-16-64-128 to be mandatory to implement. The other 591 cryptosuites supported and negotiated in the cryptosuite negotiation 592 are, expressed as tuples of AEAD Algorithm and Hash Algorithm, the 593 following: 595 0. AES-CCM-16-64-128, SHA-256 596 1. A128GCM, SHA-256 598 2. A256GCM, SHA-384 600 This specification uses the (HMAC)-based key derivation function 601 (HKDF) defined in [RFC5869] to derive the necessary key material. 602 Since the derivation will be done using the MSK, which is considered 603 fresh key material, we will use the HKDF-Expand function, which we 604 will shorten here as KDF. In addition to the generation of the 605 OSCORE parameters, we consider the derivation of a pre-shared key 606 that can be used for a DTLS security association (DTLS PSK). 608 4.2. Deriving the OSCORE Security Context 610 The derivation of the security context for OSCORE has a three 611 purposes: 613 * Secure the last two messages of the CoAP-EAP exchange, while 614 establishing the OSCORE security association 616 * Perform key confirmation 618 * Prevent a downgrading attack. 620 We can achieve this because, after a successful authentication, both 621 the EAP authenticator and the peer share the MSK. From this MSK, 622 necessary key material for the OSCORE context is derived. If the 623 contexts match, both entities confirm they have the same Master 624 Secret, and therefore they share the same MSK. We prevent a 625 downgrading attack, by embedding into the derivation process, context 626 information gathered from the cryptosuite negotiation. To do this, 627 we concatenate to the label, the content of the cryptosuites 628 negotiation (which we refer to here as CSO), using the null string 629 for any part of the negotiation missing. If an attacker changes the 630 value of the cryptosuite negotiation in any of the messages, the 631 result will be different security contexts. 633 Key material needed to derive the OSCORE Security Context, from the 634 MSK is done as follows: 636 The Master Secret can be derived by using the chosen cryptosuite and 637 the KDF. The Master Secret can be derived as follows: 639 Master Secret = KDF(MSK, CSO | "OSCORE MASTER SECRET", length) 641 where: 643 * The algorithms are agreed in the cryptosuite negotiation. 645 * The MSK exported by the EAP method. Discussion about the use of 646 the MSK for the key derivation is done in Section 6. 648 * CSO is the concatenation of the content of the cryptosuite 649 negotiation, in the request and response. If any of the messages 650 did not contain the CBOR array, the null string is used. 652 * "OSCORE MASTER SECRET" is the ASCII code representation of the 653 non-NULL terminated string (excluding the double quotes around 654 it). 656 * CSO and "OSCORE MASTER SECRET" are concatenated. 658 * length is the size of the output key material. 660 The Master Salt, similarly to the Master Secret, can be derived as 661 follows: 663 Master Salt = KDF(MSK, CSO | "OSCORE MASTER SALT", length) 665 where: 667 * The algorithms are agreed in the cryptosuite negotiation. 669 * The MSK exported by the EAP method. Discussion about the use of 670 the MSK for the key derivation is done in Section 6. 672 * CSO is the concatenation of the content of the cryptosuite 673 negotiation, in the request and response. If any of the messages 674 did not contain the CBOR array, the null string is used. 676 * "OSCORE MASTER SALT" is the ASCII code representation of the non- 677 NULL terminated string (excluding the double quotes around it). 679 * CSO and "OSCORE MASTER SECRET" are concatenated. 681 * length is the size of the output key material. 683 Regarding the Recipient ID and Sender ID, as their purpose is to 684 serve as identifiers of both entities involved in the exchange, these 685 identifiers are generated as follows: 687 Recipient ID = KDF(MSK, "OSCORE RECIPIENT ID", length) 689 where: 691 * The algorithms are agreed in the cryptosuite negotiation. 693 * "OSCORE RECIPIENT ID" is the ASCII code representation of the non- 694 NULL terminated string (excluding the double quotes around it). 696 * length is the size of the output. This value will be the maximum 697 allowed length according to the limits established by OSCORE to 698 Recipient ID, depending on the chosen cryptographic algorithms 699 [RFC8613]. 701 For the Sender ID, analogously to the Recipient ID: 703 Sender ID = KDF(MSK, "OSCORE SENDER ID", length) 705 where: 707 * The algorithms are agreed in the cryptosuite negotiation. 709 * "OSCORE RECIPIENT ID" is the ASCII code representation of the non- 710 NULL terminated string (excluding the double quotes around it). 712 * length is the size of the output. The maximum value allowed is 713 established by OSCORE to Sender ID, depending on the chosen 714 cryptographic algorithms. 716 4.3. Deriving DTLS PSK 718 It is also possible to derive a pre-shared key for DTLS [RFC6347], 719 refereed to here as "DTLS PSK", from the MSK between both CoAP 720 endpoints if required. The length of the DTLS PSK will depend on the 721 cryptosuite. To have a cryptographic material with sufficient length 722 we will derive a key of 32 bytes that can be later truncated if 723 needed: 725 DTLS PSK = KDF(MSK, "DTLS PSK", length). 727 where: 729 * MSK is exported by the EAP method. 731 * "DTLS PSK" is the ASCII code representation of the non-NULL 732 terminated string (excluding the double quotes around it). 734 * length is the size of the output key material. 736 5. Discussion 737 5.1. CoAP as EAP lower layer 739 This section discusses the suitability of the CoAP protocol as EAP 740 lower layer, and reviews the requisites imposed by the EAP protocol 741 to any protocol that transports EAP. What EAP expects from its lower 742 layers can be found in section 3.1 of [RFC3748], which is elaborated 743 next: 745 Unreliable transport. EAP does not assume that lower layers are 746 reliable. CoAP provides a reliability mechanism through the use of 747 Confirmable messages. 749 Lower layer error detection. EAP relies on lower layer error 750 detection (e.g., CRC, Checksum, MIC, etc.). CoAP goes on top of UDP 751 which provides a checksum mechanism over its payload. 753 Lower layer security. EAP does not require security services from 754 the lower layers. 756 Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 757 octets or greater. CoAP assumes an upper bound of 1024 for its 758 payload which covers the requirements of EAP. 760 Ordering guarantees. EAP relies on lower layer ordering guarantees 761 for correct operation. Regarding message ordering, every time a new 762 message arrives at the authentication service hosted by the IoT 763 device, a new resource is created and this is indicated in a 2.01 764 Created response code along with the name of the new resource via 765 Location-Path or Location-Query. This way the application indicates 766 that its state has advanced. Although the [RFC3748] states: "EAP 767 provides its own support for duplicate elimination and 768 retransmission", EAP is also reliant on lower layer ordering 769 guarantees. In this regard, the RFC talks about possible duplication 770 and says: "Where the lower layer is reliable, it will provide the EAP 771 layer with a non-duplicated stream of packets. However, while it is 772 desirable that lower layers provide for non-duplication, this is not 773 a requirement". CoAP is providing a non-duplicated stream of packets 774 and accomplish the "desirable" non-duplication. In addition, 775 [RFC3748] says that when EAP runs over a reliable lower layer "the 776 authenticator retransmission timer SHOULD be set to an infinite 777 value, so that retransmissions do not occur at the EAP layer." 779 NOTE: This document does not assume any specific naming schema. The 780 only requisite that both CoAP client and server MUST agree, is the 781 establishment of a nomenclature indicates that the next URI used to 782 refer to a resource, univocally points to the next expected EAP 783 exchange. 785 Regarding the CoAP Token, CoAP-EAP will use one of a constant value 786 throughout an authentication. This is because the EAP server will 787 not send a new EAP request until it has processed the expected EAP 788 response. Additionally, there will be a single EAP authentication 789 between the IoT device and the same Controller. This would also 790 enable the possibility of using an Empty Token to reduce the number 791 of bytes. 793 As we can see, CoAP can fulfill the requirements of EAP to be 794 considered suitable as lower layer. 796 5.2. Size of the EAP lower layer vs EAP method size 798 Regarding the impact an EAP lower layer will have to the total byte 799 size of the whole exchange, there is a comparison with another 800 network layer based EAP lower layer, PANA [RFC5191] in [coap-eap]. 801 Comparing the EAP lower layer (alone) and taking into account EAP. 802 On the one hand, at the EAP lower layer level, the usage of CoAP 803 gives important benefits. On the other hand, when taking into 804 account the EAP method overload, this reduction is less but still 805 significant if the EAP method is lightweight (authors of [coap-eap] 806 used EAP-PSK as a representative of a lightweight EAP method). If 807 the EAP method is very taxing, the impact of the reduction in size of 808 the EAP lower layer is less significant. This leads to the 809 conclusion that possible next steps in this field could be designing 810 new EAP methods that can be better adapted to the requirements of IoT 811 devices and networks. 813 However, the impact of the EAP lower layer itself cannot be ignored, 814 hence the proposal of using CoAP as lightweight protocol for this 815 purpose. Other EAP methods such as EAP-AKA'[RFC5448] or new 816 lightweight EAP methods such as EAP-NOOB [I-D.ietf-emu-eap-noob] or 817 EAP-EDHOC [I-D.ingles-eap-edhoc] that can benefit from a CoAP-based 818 EAP lower layer, as well as new ones that may be proposed in the 819 future with IoT constraints in mind. 821 5.3. Controller as the CoAP Client 823 In general, it is assumed that, since the EAP authenticator 824 (Controller) MAY implement an AAA client to interact with the AAA 825 infrastructure. Hence, this endpoint will have more resources or, at 826 least, will not be a so constrained device. Due to the constrained 827 capacities of IoT devices, to relieve them of the retransmission 828 tasks, the Controller is set as the CoAP client, for the main 829 exchange following the recommendations of the [I-D.ietf-lwig-coap] 830 document to simplify the IoT device implementation. 832 6. Security Considerations 834 There are some aspects to be considered such as how authorization is 835 managed, the use of MSK as keying material and how the trust in the 836 Controller is established. Additional considerations such as EAP 837 channel binding as per [RFC6677] are also discussed here. 839 6.1. Authorization 841 Authorization is part of bootstrapping. It serves to establish 842 whether the node can join and the set of conditions it has to adhere. 843 The authorization data will be gathered from the organization that is 844 responsible for the IoT device and sent to the EAP authenticator. In 845 standalone mode, the authorization information will be in the 846 Controller. If the pass-through mode is used, authorization data 847 received from the AAA server can be delivered by the AAA protocol 848 (e.g. Diameter). Providing more fine-grained authorization data can 849 be with the transport of SAML in RADIUS [RFC7833]. After 850 bootstrapping, additional authorization information to operate in the 851 security domain, e.g., access services offered by other nodes, can be 852 taken care of by the solutions proposed in the ACE WG. 854 6.2. Freshness of the key material 856 In CoAP-EAP there is no nonce exchange to provide freshness to the 857 keys derived from the MSK. The MSK and Extended Master Session Key 858 (EMSK) keys according to the EAP Key Management Framework [RFC5247] 859 are fresh key material. Since only one authentication is established 860 per EAP authenticator, there is no need for generating additional key 861 material. In case another authentication to be established, a re- 862 authentication can be done, by running the process again, or using a 863 more lightweight EAP method to derive additional key material as 864 elaborated in Section 3.3.2. 866 6.3. Channel Binding support 868 According to the [RFC6677], channel binding related with EAP, is sent 869 through the EAP method that supports it. 871 To satisfy the requirements of the document, we need to send the EAP 872 lower layer identifier (To be assigned by IANA), in the EAP Lower- 873 Layer Attribute if RADIUS is used. 875 6.4. Additional Security Consideration 877 Other security-related concerns can be how to ensure that the node 878 joining the security domain can in fact trust the Controller. This 879 issue is elaborated in the EAP Key Management Framework [RFC5247]. 880 In particular, the constrained node knows it can trust the Controller 881 because the key that is used to establish the security association is 882 derived from the MSK. If the Controller has the MSK, it is clear the 883 AAA Server of the node trusted the Controller, which can be 884 considered as a trusted party. 886 7. IANA Considerations 888 Considerations for IANA regarding this document: 890 * Assignment of EAP lower layer identifier. 892 * Assignment of the URI /.well-known/a 894 8. Acknowledgments 896 We would like to thank as the reviewers of this work: Carsten 897 Bormann, Mohit Sethi, Benjamin Kaduk, Alexandre Petrescu, Pedro 898 Moreno-Sanchez and Eduardo Ingles-Sanchez. 900 We would also like to thank Gabriel Lopez-Millan for the first review 901 of this document and we would like to thank Ivan Jimenez-Sanchez for 902 the first proof-of-concept implementation of this idea. 904 And thank for their valuables comments to Alexander Pelov and Laurent 905 Toutain, especially for the potential optimizations of CoAP-EAP. 907 9. References 909 9.1. Normative References 911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 912 Requirement Levels", BCP 14, RFC 2119, 913 DOI 10.17487/RFC2119, March 1997, 914 . 916 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 917 Levkowetz, Ed., "Extensible Authentication Protocol 918 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 919 . 921 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 922 Authentication Protocol (EAP) Key Management Framework", 923 RFC 5247, DOI 10.17487/RFC5247, August 2008, 924 . 926 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 927 "Specification for the Derivation of Root Keys from an 928 Extended Master Session Key (EMSK)", RFC 5295, 929 DOI 10.17487/RFC5295, August 2008, 930 . 932 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 933 Key Derivation Function (HKDF)", RFC 5869, 934 DOI 10.17487/RFC5869, May 2010, 935 . 937 [RFC6677] Hartman, S., Ed., Clancy, T., and K. Hoeper, "Channel- 938 Binding Support for Extensible Authentication Protocol 939 (EAP) Methods", RFC 6677, DOI 10.17487/RFC6677, July 2012, 940 . 942 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 943 Application Protocol (CoAP)", RFC 7252, 944 DOI 10.17487/RFC7252, June 2014, 945 . 947 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 948 Bose, "Constrained Application Protocol (CoAP) Option for 949 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 950 August 2016, . 952 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 953 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 954 May 2017, . 956 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 957 "Object Security for Constrained RESTful Environments 958 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 959 . 961 9.2. Informative References 963 [coap-eap] Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP- 964 Based Bootstrapping Service for the Internet of Things - 965 https://www.mdpi.com/1424-8220/16/3/358", March 2016. 967 [I-D.ietf-ace-oauth-authz] 968 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 969 H. Tschofenig, "Authentication and Authorization for 970 Constrained Environments (ACE) using the OAuth 2.0 971 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 972 draft-ietf-ace-oauth-authz-36, 16 November 2020, 973 . 976 [I-D.ietf-emu-eap-noob] 977 Aura, T., Sethi, M., and A. Peltonen, "Nimble out-of-band 978 authentication for EAP (EAP-NOOB)", Work in Progress, 979 Internet-Draft, draft-ietf-emu-eap-noob-05, 12 July 2021, 980 . 983 [I-D.ietf-lwig-coap] 984 Kovatsch, M., Bergmann, O., and C. Bormann, "CoAP 985 Implementation Guidance", Work in Progress, Internet- 986 Draft, draft-ietf-lwig-coap-06, 2 July 2018, 987 . 990 [I-D.ingles-eap-edhoc] 991 Sanchez, E., Garcia-Carrillo, D., and R. Marin-Lopez, "EAP 992 method based on EDHOC Authentication", Work in Progress, 993 Internet-Draft, draft-ingles-eap-edhoc-01, 2 November 994 2020, . 997 [lo-coap-eap] 998 Garcia-Carrillo, D., Marin-Lopez, R., Kandasamy, A., and 999 A. Pelov, "A CoAP-Based Network Access Authentication 1000 Service for Low-Power Wide Area Networks: LO-CoAP-EAP - 1001 https://www.mdpi.com/1424-8220/17/11/2646", November 2017. 1003 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 1004 Pre-Shared Key Extensible Authentication Protocol (EAP) 1005 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 1006 . 1008 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1009 and A. Yegin, "Protocol for Carrying Authentication for 1010 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1011 May 2008, . 1013 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 1014 Extensible Authentication Protocol Method for 3rd 1015 Generation Authentication and Key Agreement (EAP-AKA')", 1016 RFC 5448, DOI 10.17487/RFC5448, May 2009, 1017 . 1019 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1020 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1021 January 2012, . 1023 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., 1024 "EAP Extensions for the EAP Re-authentication Protocol 1025 (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012, 1026 . 1028 [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A 1029 RADIUS Attribute, Binding, Profiles, Name Identifier 1030 Format, and Confirmation Methods for the Security 1031 Assertion Markup Language (SAML)", RFC 7833, 1032 DOI 10.17487/RFC7833, May 2016, 1033 . 1035 [RFC8824] Minaburo, A., Toutain, L., and R. Andreasen, "Static 1036 Context Header Compression (SCHC) for the Constrained 1037 Application Protocol (CoAP)", RFC 8824, 1038 DOI 10.17487/RFC8824, June 2021, 1039 . 1041 [TS133.501] 1042 ETSI, "5G; Security architecture and procedures for 5G 1043 System - TS 133 501 V15.2.0 (2018-10)", 2018. 1045 Appendix A. Examples of Use Case Scenario 1047 For a IoT device to act as a trustworthy entity within a security 1048 domain, certain key material is needed to be shared between the IoT 1049 device and the Controller. 1051 Next, we elaborate on examples of different use case scenarios about 1052 the usage of CoAP-EAP. Generally, we are dealing with 4 entities: 1054 * 2 nodes (A and B), which are IoT devices. They are the EAP peers. 1056 * 1 controller (C). The controller manages a domain where nodes can 1057 be deployed. It can be considered a more powerful machine than 1058 the IoT devices. 1060 * 1 AAA server (AAA) - Optional. The AAA is an Authentication, 1061 Authorization and Accounting Server, which is not constrained. 1062 Here, the Controller acts as EAP authenticator in pass-through 1063 mode. 1065 Generally, any IoT device wanting to join the domain managed by the 1066 Controller MUST perform a CoAP-EAP authentication with the Controller 1067 (C). This authentication MAY involve an external AAA server. This 1068 means that A and B, once deployed, will run CoAP-EAP once, as a 1069 bootstrapping phase, to establish a security association with C. 1070 Moreover, any other entity, which wants to join and establish 1071 communications with nodes under C's domain must also do the same. By 1072 using EAP, we can have the flexibility of having different types of 1073 credentials. For instance, if we have a device that is not battery 1074 dependent, and not very constrained, we could use a heavier 1075 authentication method. With varied IoT devices and networks we might 1076 need to resort to more lightweight authentication methods (e.g., EAP- 1077 NOOB[I-D.ietf-emu-eap-noob], EAP-AKA'[RFC5448], EAP-PSK[RFC4764], 1078 EAP-EDHOC[I-D.ingles-eap-edhoc], etc.) being able to adapt to 1079 different types of devices according to organization policies or 1080 devices capabilities. 1082 A.1. Example 1: CoAP-EAP in ACE 1084 In ACE, the process of Client registration and provisioning of 1085 credentials to the client is not specified. The process of Client 1086 registration and provisioning can be achieved using CoAP-EAP. Once 1087 the process of authentication with EAP is completed, fresh key 1088 material is shared between the IoT device and the Controller. In 1089 this instance, the Controller and the Authorization Server (AS) of 1090 ACE can be co-located. 1092 Next, we exemplify how CoAP-EAP can be used to perform the Client 1093 registration in a general way, to allow two IoT devices (A and B) to 1094 communicate and interact after a successful client registration. 1096 Node A wants to communicate with node B (e.g. to activate a light 1097 switch). The overall process is divided into three phases. Let's 1098 start with node A. In the first phase, the node A (EAP peer) does 1099 not yet belong to Controller C's domain. Then, it communicates with 1100 C (EAP authenticator) and authenticates with CoAP-EAP, which, 1101 optionally, communicates with the AAA server to complete the 1102 authentication process. If the authentication is successful, a fresh 1103 MSK is shared between C and node A. This key material allows node A 1104 to establish a security association with the C. Some authorization 1105 information may be also provided in this step. In case EAP is used 1106 in standalone mode, the AS itself having information about the 1107 devices can be the entity providing said authorization information. 1109 If authentication and authorization are correct, node A is enrolled 1110 in controller C's domain for a period of time. In particular, 1111 [RFC5247] recommends 8 hours, though the the entity providing the 1112 authorization information can establish this lifetime. In the same 1113 manner, B needs to perform the same process with CoAP-EAP to be part 1114 of the controller C's domain. 1116 In the second phase, when node A wants to talk with node B, it 1117 contacts controller C for authorization to access node B and obtain 1118 all the required information to do that securely (e.g. keys, tokens, 1119 authorization information, etc.). This phase does NOT require the 1120 usage of CoAP-EAP. The details of this phase are out of the scope of 1121 this document, and the ACE framework is used for this purpose 1122 [I-D.ietf-ace-oauth-authz]. 1124 In the third phase, the node A can access node B with the credentials 1125 and information obtained from the controller C in the second phase. 1126 This access can be repeated without contacting the controller, while 1127 the credentials given to A are still valid. The details of this 1128 phase are out of scope of this document. 1130 It is worth noting that first phase with CoAP-EAP is required to join 1131 the controller C's domain. Once it is performed with success, the 1132 communications are local to the controller C's domain and there is no 1133 need to perform a new EAP authentication as long as the key material 1134 is still valid. When the keys are about to expire, the IoT device 1135 can engage in a reauthentication as explained in Section 3.3.2, to 1136 renew the key material. 1138 A.2. Example 2: Multi-domain with AAA infrastructures 1140 We assume we have a device (A) of the domain acme.org, which uses a 1141 specific kind of credential (e.g., AKA) and intends to join the um.es 1142 domain. This user does not belong to this domain, for which first it 1143 performs a client registration using CoAP-EAP. For this, it 1144 interacts with the controller's domain acting as EAP authenticator, 1145 which in turn communicates with a AAA infrastructure (acting as AAA 1146 client). Through the local AAA server to communicate with the home 1147 AAA server to complete the authentication and integrate the device as 1148 a trustworthy entity into the domain of controller C. In this 1149 scenario, the AS under the role of the Controller receives the key 1150 material from the AAA infrastructure 1152 A.3. Example 3: Single domain with AAA infrastructure 1154 A University Campus, we have several Faculty buildings and each one 1155 has its own criteria or policies in place to manage IoT devices under 1156 an AS. All buildings belong to the same domain (e.g., um.es). All 1157 these buildings are managed with a AAA infrastructure. A new device 1158 (A) with credentials from the domain (e.g., um.es) will be able to 1159 perform the device registration with a Controller (C) of any building 1160 as long as they are managed by the same general domain. 1162 A.4. Example 4: Single domain without AAA infrastructure 1164 In another case, without a AAA infrastructure, we have a Controller 1165 that has co-located the EAP server and using EAP standalone mode we 1166 can manage all the devices within the same domain locally. Client 1167 registration of a node (A) with Controller (C) can also be performed 1168 in the same manner. 1170 A.5. Other use cases 1172 A.5.1. CoAP-EAP for network access control 1174 One of the first steps for an IoT device life-cycle is to perform the 1175 authentication to gain access to the network. To do so, the device 1176 first has to be authenticated and granted authorization to gain 1177 access to the network. Additionally, security parameters such as 1178 credentials can be derived from the authentication process allowing 1179 the trustworthy operation of the IoT device in a particular network 1180 by joining the security domain. By using EAP, we are able to achieve 1181 this with flexibility and scalability, because of the different EAP 1182 methods available and the ability to rely on AAA infrastructures if 1183 needed to support multi-domain scenarios, which is a key feature when 1184 the IoT devices deployed under the same security domain, belong to 1185 different organizations. Given that EAP is also used for network 1186 access control, we can adapt this service for other technologies. 1187 For instance, to provide network access control to very constrained 1188 technologies (e.g., LoRa network). Authors in [lo-coap-eap] provide 1189 an study of a minimal version of CoAP-EAP for LPWAN networks with 1190 interesting results. In this specific case, we could leverage the 1191 compression by SCHC for CoAP [RFC8824]. 1193 A.5.2. CoAP-EAP for service authentication 1195 It is not uncommon that the infrastructure where the device is 1196 deployed and the services of the IoT device are managed by different 1197 organizations. Therefore, in addition to the authentication for 1198 network access control, we have to consider the possibility of a 1199 secondary authentication to access different services. This process 1200 of authentication, for example, will provide with the necessary key 1201 material to establish a secure channel and interact with the entity 1202 in charge of granting access to different services. In 5G, for 1203 example, consider a primary and secondary authentication using EAP 1204 [TS133.501]. 1206 Authors' Addresses 1208 Rafa Marin-Lopez 1209 University of Murcia 1210 Campus de Espinardo S/N, Faculty of Computer Science 1211 30100 Murcia 1212 Spain 1214 Phone: +34 868 88 85 01 1215 Email: rafa@um.es 1217 Dan Garcia-Carrillo 1218 University of Oviedo 1219 Calle Luis Ortiz Berrocal S/N, Edificio Polivalente 1220 33203 Gijon Asturias 1221 Spain 1223 Email: garciadan@uniovi.es