idnits 2.17.1 draft-ietf-ace-wg-coap-eap-01.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 (May 27, 2021) is 1058 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 455, but not defined == Missing Reference: '0x7654' is mentioned on line 482, but not defined == Missing Reference: '0x8694' is mentioned on line 476, but not defined == Missing Reference: '0x9869' is mentioned on line 312, but not defined == Missing Reference: '0x7811' is mentioned on line 324, but not defined == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-36 ** Downref: Normative reference to an Informational draft: draft-ietf-lwig-coap (ref. 'I-D.ietf-lwig-coap') == Outdated reference: A later version (-05) exists of draft-ingles-eap-edhoc-01 ** Downref: Normative reference to an Informational RFC: RFC 4493 ** Downref: Normative reference to an Informational RFC: RFC 7228 ** Downref: Normative reference to an Informational RFC: RFC 7967 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). 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: November 28, 2021 University of Oviedo 6 May 27, 2021 8 EAP-based Authentication Service for CoAP 9 draft-ietf-ace-wg-coap-eap-01 11 Abstract 13 This document describes an authentication service that uses EAP 14 transported employing CoAP messages with following purposes: 1) 15 Authenticate a CoAP-enabled device that enters a new security domain 16 managed by a domain Controller, 2) Derive key material to protect 17 CoAP messages exchanged between them, enabling the establishment of a 18 security association between them, and 3) Optionally, to generate key 19 material for other types of Security Associations. 21 Generally speaking, this document is specifying an EAP lower layer 22 based on CoAP, to bring the benefits of EAP to IoT. 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 November 28, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. General Architecture . . . . . . . . . . . . . . . . . . . . 3 61 3. General Flow Operation . . . . . . . . . . . . . . . . . . . 4 62 3.1. EAP over CoAP flow of operation . . . . . . . . . . . . . 5 63 3.2. Message processing of EAP over CoAP . . . . . . . . . . . 8 64 3.3. EAP over CoAP operation casuistics . . . . . . . . . . . 8 65 4. Key Derivation for protecting CoAP messages . . . . . . . . . 11 66 4.1. Deriving the OSCORE Security Context . . . . . . . . . . 12 67 4.2. Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . . 13 68 5. Examples of Use Case Scenario . . . . . . . . . . . . . . . . 13 69 5.1. Example 1: CoAP-EAP in ACE . . . . . . . . . . . . . . . 14 70 5.2. Example 2: Multi-domain with AAA infrastructures . . . . 15 71 5.3. Example 3: Single domain with AAA infrastructure . . . . 15 72 5.4. Example 4: Single domain without AAA infrastructure . . . 16 73 5.5. Other use cases . . . . . . . . . . . . . . . . . . . . . 16 74 5.5.1. CoAP-EAP for network access control . . . . . . . . . 16 75 5.5.2. CoAP-EAP for service authentication . . . . . . . . . 16 76 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 6.1. CoAP as EAP lower layer . . . . . . . . . . . . . . . . . 17 78 6.2. Size of the EAP lower layer vs EAP method size . . . . . 18 79 6.3. Controller as the CoAP Client . . . . . . . . . . . . . . 18 80 6.4. Possible Optimizations . . . . . . . . . . . . . . . . . 18 81 6.4.1. Empty Token . . . . . . . . . . . . . . . . . . . . . 19 82 6.4.2. Further re-authentication . . . . . . . . . . . . . . 19 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 84 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 85 7.2. Cryptographic suite selection . . . . . . . . . . . . . . 19 86 7.3. Freshness of the key material . . . . . . . . . . . . . . 20 87 7.4. Additional Security Consideration . . . . . . . . . . . . 20 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 89 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 92 10.2. Informative References . . . . . . . . . . . . . . . . . 22 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 95 1. Introduction 97 The goal of this document is to describe an authentication service 98 that uses the Extensible Authentication Protocol (EAP) [RFC3748]. 99 The authentication service is built on top of the Constrained 100 Application Protocol (CoAP) [RFC7252] and allows authenticating two 101 CoAP endpoints by using EAP, to establish a security association 102 between them. 104 In particular, this document describes how CoAP can be used as a 105 constrained, link-layer independent, EAP lower layer [RFC3748] to 106 transport EAP messages between a CoAP server (EAP peer) and a CoAP 107 client (EAP authenticator) using CoAP messages. The CoAP client MAY 108 contact with a backend AAA infrastructure to complete the EAP 109 negotiation as described in the EAP specification [RFC3748]. 111 The assumption is that the EAP method transported in CoAP MUST 112 generate cryptographic material [RFC5247]. In this way, the CoAP 113 messages can be protected after the authentication. The general flow 114 of operation of CoAP-EAP establishes an OSCORE security association 115 specifically for the service. In addition, using the key material 116 derived from the authentication, we specify the establishment of 117 other security associations depending on the security requirements of 118 the services: 120 o OSCORE [RFC8613] security association can be established based on 121 the cryptographic material generated from the EAP authentication. 123 o A DTLS security association can be established using the exported 124 cryptographic material after a successful EAP authentication. 126 This document also indicates how to establish a security association 127 for other types of technologies that rely on CoAP. 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 RFC 2119 [RFC2119]. 135 2. General Architecture 137 Figure 1 shows the architecture defined in this document. Basically, 138 a node acting as the EAP peer wants to be authenticated by using EAP. 139 At the time of writing this document, we have considered a model 140 where the entity acting as EAP peer will also act as a CoAP server 141 for this service and the entity acting as EAP authenticator will act 142 as a CoAP client and MAY interact with a backend AAA infrastructure, 143 which will place the EAP server and contain the information required 144 to authenticate the CoAP client. The rationale behind this decision, 145 as we will expand later, is that EAP requests go always from the EAP 146 authenticator to the EAP peer. Accordingly, the EAP responses go 147 from the EAP peer to the EAP authenticator. 149 +------------+ +------------+ 150 | EAP peer/ | | EAP auth./ | 151 | CoAP server|+------+| CoAP client| 152 +------------+ CoAP +------------+ 154 Figure 1: CoAP EAP Architecture 156 3. General Flow Operation 158 The authentication service uses CoAP as transport for EAP. In other 159 words, CoAP becomes an EAP lower layer in EAP terminology. In 160 general, it is assumed that, since the EAP authenticator MAY 161 implement an AAA client to interact with the AAA infrastructure, this 162 endpoint will have more resources or, at least, will not be so 163 constrained device. We show the sequence flow in Figure 2 where we 164 depict the usage of a generic EAP method that we call EAP-X as an 165 authentication mechanism. (NOTE: any EAP method that can export 166 cryptographic material is valid. For example, EAP-MD5 cannot be used 167 since it does not export key material). 169 The first step to run CoAP-EAP is for the IoT device to discover the 170 Controller, and that it implements the CoAP-EAP service. To do so, 171 we rely on the discovery mechanism of CoAP. The URI of the CoAP-EAP 172 service is set to "/b" to save bytes over the air. Alternatively, if 173 the Controller is aware of the presence of the IoT device (e.g., due 174 to a previous authentication) this process can be avoided, and the 175 Controller can directly start the authentication process. 177 The first message is used to trigger the authentication process. 178 This message is sent by the IoT device, acting as a CoAP client. 179 This message uses the No-Response Option [RFC7967] to avoid the 180 response from the Controller to this message. After this, the 181 exchange continues with the Controller acting as a CoAP client and 182 the IoT device acting as a CoAP server. This is because the IoT 183 device could be a constrained node, and following the recommendations 184 of [I-D.ietf-lwig-coap] to simplify the implementation of the IoT 185 device, the Controller takes the responsibility of handling the 186 retransmissions. In the next section, we refer to the IoT device as 187 the EAP peer and the Controller as the EAP authenticator to elaborate 188 the specifics of the flow of operation. 190 3.1. EAP over CoAP flow of operation 192 If the EAP peer discovers the presence of the EAP authenticator and 193 wants to start the authentication, it can send a Non-Confirmable 194 "POST /b" request to the node (Step 0). This message will carry an 195 option developed in the work of [RFC7967] called 'No-Response'. The 196 rationale of this option is to avoid waiting for a response if it is 197 not needed. So the use of this option will allow signalling the 198 intention the EAP peer to start the authentication process. 199 Immediately after that, the EAP authenticator will start 200 authentication service. It is worth noting that the EAP 201 authenticator MAY decide to start the authentication without waiting 202 for the trigger if it knows about the presence of the peer. For 203 instance, through a previous authentication. 205 In any case, to perform the authentication service, the CoAP client 206 (EAP authenticator) sends a Confirmable "POST /b" request to the CoAP 207 Server (Step 1). After receiving the first POST, the CoAP server 208 assigns a resource and answers with an Acknowledgment with the piggy- 209 backed response containing the resource identifier (Location-Path) 210 (Step 2). The name of the resource MAY be represented following the 211 naming "/b/x". Where "b" is the general name of the bootstrapping 212 service; "x" represents the resource established to process the 213 following message of the authentication. This CoAP server can select 214 this value as pleased, as long as, it serves to process the following 215 message adequately. It is assumed that the CoAP server will only 216 have an ongoing authentication with that particular CoAP client and 217 will not process simultaneous EAP authentications in parallel (with 218 the same EAP authenticator) to save resources. 220 In this exchange (Step 1 and 2), the EAP Req/Id and Rep/Id messages 221 are exchanged between the EAP authenticator and the EAP peer. Upon 222 the reception of the EAP Req/Id message, the EAP authenticator 223 forwards this message, when EAP is in pass-through mode, to the local 224 AAA server. The AAA server is in charge of steering the 225 conversation, choosing the EAP method to be used (e.g. EAP-X) if the 226 user is local, or sending the EAP messages to the home AAA of the EAP 227 peer. At this point, the CoAP server has created a resource for the 228 EAP authentication. The resource identifier value will be used to 229 relate the EAP conversation between both CoAP endpoints. 231 NOTE: Since only an ongoing EAP authentication is permitted per EAP 232 authenticator/EAP client, and EAP is a lock-step protocol, a Token of 233 a constant value can be used throughout the authentication process. 234 An empty Token could be considered to reduce bytes. 236 From now on, the EAP authenticator and the EAP peer will exchange EAP 237 packets related to the EAP method, transported in the CoAP message 238 payload (Steps 3,4,5,6). The EAP authenticator will use the POST 239 method to send EAP requests to the EAP peer. The EAP peer will use a 240 Piggy-backed response in the Acknowledgment message to carry the EAP 241 response. When all the message exchange is completed, if everything 242 has gone well, the EAP authenticator can send an EAP Success message, 243 and both CoAP endpoints will share a Master Session Key (MSK) 244 ([RFC5295]) 246 To establish a security association that will confirm to the EAP peer 247 that EAP authenticator received the MSK from the AAA server, as well 248 as to the EAP authenticator that the EAP peer derived the MSK 249 correctly, both entities engage in the establishment of a security 250 association. In the context of constrained devices [RFC7228] and 251 networks, we consider protocols that are designed for these cases. 252 Concretely, we show here in the diagram the establishment of the 253 OSCORE security association (Steps 7 and 8). From that point, any 254 exchange between both CoAP endpoints is protected with OSCORE. 255 Before sending the EAP success to the EAP peer, the EAP authenticator 256 can derive the OSCORE Security Context, to confirm the establishment 257 of the security association. The details of the establishment of the 258 OSCORE Security Context are discussed in Section Section 4.1. The 259 protection of the EAP Success is not a requirement. Here, we specify 260 this exchange as protected by the lower layer with OSCORE. The 261 purpose is double, we can avoid forgery of this message and we are 262 using the exchange to perform the key confirmation through the 263 establishment of the OSCORE security association. Adding to the 264 previous consideration about the EAP Success, this message does not 265 prevent the operation of the device from continuing as long as there 266 is an alternate success indication that both the EAP peer and 267 authentication can rely on to continue [RFC3748]. This indication 268 can happen in two ways: 1) the reception of the CoAP message without 269 EAP and with an OSCORE option (following the normal operational 270 communication between both entities) is an indication that the 271 controller considers the EAP authentication finished. 2) the IoT 272 device knows that the EAP authentication went well if an MSK is 273 available. Both entities need to prove the possession of the MSK as 274 mentioned in the EAP KMF. 276 EAP peer EAP Auth. 277 (CoAP server) (CoAP client) 278 ------------- ------------- 279 | | 280 | NON [0x6af5] POST /b | 281 | Token (0xab) | 282 0) | No-Response | 283 |---------------------------------------->| 284 | | 285 | CON [0x7654] POST /b | 286 | Token (0xac) | 287 | Payload EAP Req/Id | 288 1) |<----------------------------------------| 289 | | 290 | ACK [0x7654] | 291 | Token (0xac) | 292 | 2.01 Created Location-Path [/b/x] | 293 | Payload EAP Rep/Id | 294 2) |---------------------------------------->| 295 | | 296 | CON [0x8694] POST /b/x | 297 | Token (0xac) | 298 | Payload EAP-X MSG 1 | 299 3) |<----------------------------------------| 300 | | 301 | ACK [0x8694] | 302 | Token (0xac) | 303 | 2.01 Created Location-Path [/b/y] | 304 | Payload EAP-X MSG 2 | 305 4) |---------------------------------------->| 306 .... 307 | CON [0x9869] POST /b/y | 308 | Token (0xac) | 309 | Payload EAP-X MSG (n-1) | 310 5) |<----------------------------------------| 311 | | 312 | ACK [0x9869] | 313 | Token (0xac) | 314 | 2.01 Created Location-Path [/b/z] | 315 | Payload EAP-X MSG (n) | MSK 316 6) |---------------------------------------->| | 317 | | V 318 | CON [0x7811] POST /b/z |OSCORE 319 | Token (0xac) |CONTEXT 320 | OSCORE Option | (*) 321 | Payload EAP success | 322 MSK 7) |<----------------------------------------| 323 | | | 324 V (*) | ACK [0x7811] | 325 OSCORE | Token (0xac) | 326 CONTEXT | OSCORE Option | 327 8) |---------------------------------------->| 328 (*) Protected with OSCORE 330 Figure 2: CoAP-EAP flow of operation 332 3.2. Message processing of EAP over CoAP 334 In this section, we introduce how the service is processed by the two 335 entities involved in the exchange. 337 For the CoAP server, each time a new CoAP request arrives, containing 338 the EAP message as payload, does the following: 340 1. Send the EAP message to the EAP state machine 342 2. If the EAP state machine processes the request correctly: 344 A. A new resource is created. (e.g. b/y) 346 B. The current resource is deleted. (e.g. b/x) 348 C. A response is sent back to the client specifying the new 349 resource 351 3. If the EAP state machine returns an error: 353 A. The CoAP service will send an error message. (e.g: 4.00 Bad 354 Request) 356 When the EAP authenticator (CoAP client) receives an EAP message from 357 the EAP peer (CoAP server), it will send it to the EAP server, and 358 vice-versa. In any case, the EAP exchange is initiated by the EAP 359 authenticator, sending the EAP Request/Identity message to the EAP 360 peer and the ongoing authentication will be tracked by a 361 bootstrapping state where all the relevant information for the 362 application is stored, such as the current URI for the exchange (or 363 the expected URI for the next exchange). From that point on, the 364 processing of the messages continues as follows: 366 1. If the ongoing message is an EAP request, is sent to the EAP 367 peer. If it is an EAP response, it is sent to the EAP server. 369 2. If a CoAP response containing the new resource and the EAP 370 response arrives, the new CoAP resource is updated. 372 3. If an error arrives, the CoAP client will rely on CoAP 373 retransmission behavior. 375 3.3. EAP over CoAP operation casuistics 377 In this section, we introduce a couple of cases where a message is 378 lost and retransmitted later, to show how the service will react. 379 The first one shows what would happen if a piggybacked response with 380 a new resource identifier is lost. This case is illustrated in 381 Figure 3. The second shows what would happen if an old request 382 message arrives even though the process of authentication continued 383 due to normal retransmission behaviour. This is illustrated in 384 Figure 4. 386 For the first case, when a piggybacked response message containing 387 the Location-Path of the new resource is lost, the CoAP client will 388 retransmit. This will cause the CoAP server to recognize the message 389 as retransmission due to the MSG-ID, and re-send the lost message. 391 EAP peer EAP Auth. 392 (CoAP server) (CoAP client) 393 ------------- ------------- 394 | | 395 | NON [0x6af5] POST /b | 396 | Token (0xab) | 397 0) | No-Response | 398 |---------------------------------------->| 399 | | 400 | CON [0x7654] POST /b | 401 | Token (0xac) | 402 | Payload EAP Req/Id | 403 1) |<----------------------------------------| 404 | | 405 | ACK [0x7654] | 406 | Token (0xac) | 407 | 2.01 Created Location-Path [/b/x] | 408 | Payload EAP Rep/Id | 409 2) |---------------------------->X | 410 | | 411 | CON [0x7654] POST /b | 412 | Token (0xac) | 413 | Payload EAP Req/Id | 414 1) |<----------------------------------------| 415 | | 416 | ACK [0x7654] | 417 | Token (0xac) | 418 | 2.01 Created Location-Path [/b/x] | 419 | Payload EAP Rep/Id | 420 2) |---------------------------------------->| 422 Figure 3: Casuistic - Response Lost 424 In the second case, when a message is lost, but due to the ongoing 425 workings of CoAP retransmission, the flow of operation continues as 426 expected. If said lost message arrives later, how this message is 427 handled will depend on which layer deals with it. 429 1. If the message is handled by the CoAP messaging layer, which 430 means it will not go up to the service application: 432 A. As the server recognizes the old message, due to internal 433 tracking, it can send a stored copy of the response. 435 B. Then the client would recognize the MSGID as old and that he 436 got the response already, and simply dropping it. 438 2. If the messaging layer does not recognize the message as old, and 439 takes care of it, it will try to send it to the service 440 application: 442 A. This will cause an error, since a resource of a previous step 443 of the authentication is deleted 445 B. The error code (e.g., 4.04 Not Found) with the same MSGID is 446 sent back to the CoAP client. 448 C. The CoAP client would recognize the MSGID as old and simply 449 drop it. 451 EAP peer EAP Auth. 452 (CoAP server) (CoAP client) 453 ------------- ------------- 454 | | 455 | NON [0x6af5] POST /b | 456 | Token (0xab) | 457 0) | No-Response | 458 |---------------------------------------->| 459 | | 460 | CON [0x7654] POST /b | 461 | Token (0xac) | 462 | Payload EAP Req/Id | 463 1) |<----------------------------------------| 464 | | 465 | ACK [0x7654] | 466 | Token (0xac) | 467 | 2.01 Created Location-Path [/b/x] | 468 | Payload EAP Rep/Id | 469 2) |---------------------------------------->| 470 | | 471 | CON [0x8694] POST /b/x | 472 | Token (0xac) | 473 | Payload EAP-X MSG 1 | 474 3) |<----------------------------------------| 475 | | 476 | ACK [0x8694] | 477 | Token (0xac) | 478 | 2.01 Created Location-Path [/b/y] | 479 | Payload EAP-X MSG 2 | 480 4) |---------------------------------------->| 481 | | 482 | CON [0x7654] POST /b | 483 | Token (0xac) | 484 | Payload EAP Req/Id |(Old message) 485 1) |<----------------------------------------| 487 Figure 4: Casuistic - Old message 489 4. Key Derivation for protecting CoAP messages 491 As a result of a successful EAP authentication, both the CoAP server 492 and CoAP client share a Master Key Session (MSK). The assumption is 493 that MSK is a fresh key, so any key derived from the MSK will be also 494 fresh. To complete the CoAP-EAP exchange, as part of the design, it 495 is expected the establishment of an OSCORE security association 496 specifically for the CoAP-EAP service. The security level for the 497 CoAP-EAP exchanges with OSCORE is with integrity. Additionally, we 498 considered the derivation of either the OSCORE Security Context or a 499 pre-shared key that can be used for a DTLS negotiation (DTLS_PSK) for 500 further communications depending on the security requirements of the 501 services provided by the AS. The OSCORE security context generated 502 for CoAP-EAP could be generalized to enable further OSCORE secured 503 communications between the IoT device and the AS services that 504 require the use of OSCORE. 506 4.1. Deriving the OSCORE Security Context 508 Key material needed to derive the OSCORE Security Context, from the 509 MSK can be done as follows: 511 The Master Secret can be derived by using AES-CMAC-PRF-128 [RFC4615], 512 which, in turn, uses AES-CMAC-128 [RFC4493]. The Master Secret can 513 be derived as follows: 515 Master_Secret = KDF(MSK, "IETF_OSCORE_MASTER_SECRET", 64, length) 517 where: 519 o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses 520 AES-CMAC-128 as a building block. 522 o The MSK exported by the EAP method, which by design is a fresh key 523 material. Discussions about the use of the MSK for the key 524 derivation are done in Section Section 7. 526 o "IETF_OSCORE_MASTER_SECRET" is the ASCII code representation of 527 the non-NULL terminated string (excluding the double quotes around 528 it). 530 o 64 is the length of the MSK. 532 o length is the length of the label "IETF_OSCORE_MASTER_SECRET" (25 533 bytes). 535 The Master Salt, similarly to the Master Secret, can be derived as 536 follows: 538 Master_Salt = KDF(MSK, "IETF_OSCORE_MASTER_SALT", 64, length) 540 where: 542 o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses 543 AES-CMAC-128 as a building block. 545 o The MSK exported by the EAP method, which by design is a fresh key 546 material. Discussions about the use of the MSK for the key 547 derivation are done in Section Section 7. 549 o "IETF_OSCORE_MASTER_SALT" is the ASCII code representation of the 550 non-NULL terminated string (excluding the double quotes around 551 it). 553 o 64 is the length of the MSK. 555 o length is the length of the label "IETF_OSCORE_MASTER_SALT" (23 556 bytes). 558 The ID Context can be set to the identity of the EAP peer. 560 4.2. Deriving DTLS_PSK 562 In the second alternative, a DTLS_PSK is derived from the MSK between 563 both CoAP endpoints. The length of the DTLS_PSK will depend on the 564 cipher-suite. For AES-128, the DTLS_PSK will have a 16-byte length 565 and it will be derived as follows: 567 DTLS_PSK = KDF(MSK, "IETF_DTLS_PSK" , 64, length). This value is 568 concatenated with the value of the Token Option value. 570 where: 572 o MSK is exported by the EAP method. 574 o "IETF_DTLS_PSK" is the ASCII code representation of the non-NULL 575 terminated string (excluding the double quotes around it). 577 o 64 is the length of the MSK. 579 o length is the length of the label "IETF_DTLS_PSK" (13 bytes). 581 5. Examples of Use Case Scenario 583 For a device to act as a trustworthy entity within a security domain, 584 certain key material is needed to be shared between the IoT device 585 and AS. In ACE, the process of Client registration and provisioning 586 of credentials to the client is not specified. The process of Client 587 registration and provisioning can be achieved by using CoAP-EAP. 588 Once the process of authentication with EAP is completed, a fresh key 589 material is shared between the IoT device and the AS. 591 Next, we elaborate on examples of different use case scenarios about 592 the usage of CoAP-EAP. Generally, we are dealing with 4 entities: 594 o 2 nodes (A and B), which are constrained devices. They are the 595 EAP peers. 597 o 1 controller (C). The controller manages a domain where nodes can 598 be deployed. It can be considered a more powerful machine than 599 the nodes. In this scenario, the Controller (and EAP 600 Authenticator), can be co-located with the AS. 602 o 1 AAA server (AAA) - Optional. The AAA is an Authentication, 603 Authorization and Accounting Server, which is not constrained. 605 Generally, any node wanting to join the domain managed by the 606 controller MUST perform a CoAP-EAP authentication with the controller 607 C. This authentication MAY involve an external AAA server. This 608 means that A and B, once deployed, will perform this CoAP-EAP once as 609 a bootstrapping phase to establish a security association with 610 controller C. Moreover, any other entity, which wants to join and 611 establish communications with nodes under controller C's domain must 612 also do the same. By using EAP, we can have the flexibility of 613 having different types of credentials. For instance, if we have a 614 device that is not battery dependent, and not very constrained, we 615 could use a heavier authentication method. With very constrained 616 devices and networks we might need to resort to more lightweight 617 authentication methods (e.g., EAP-PSK, EAP-EDHOC, etc.) being able to 618 adapt to different types of devices according to policies or devices 619 capabilities. 621 5.1. Example 1: CoAP-EAP in ACE 623 Next, we exemplify how CoAP-EAP can be used to perform the Client 624 registration in a general way, to allow two IoT devices (A and B) to 625 communicate and interact after a successful client registration. 627 Node A wants to communicate with node B (e.g. to activate a light 628 switch). The overall process is divided into three phases. Let's 629 start with node A. In the first phase, the node A (EAP peer) does 630 not yet belong to controller C's domain. Then, it communicates with 631 controller C (EAP authenticator) and authenticates with CoAP-EAP, 632 which, optionally, communicates with the AAA server to complete the 633 authentication process. If the authentication is successful, key 634 material is distributed to controller C and derived by node A. This 635 key material allows node A to establish a security association with 636 the controller (C). Some authorization information may be also 637 provided in this step. If authentication and authorization are 638 correct, node A is enrolled in controller C's domain for a period of 639 time. In particular, [RFC5247] recommends 8 hours, though the AAA 640 server can establish this lifetime. In the same manner, B needs to 641 perform the same process with CoAP-EAP to be part of the controller 642 C's domain. 644 In the second phase, when node A wants to talk with node B, it 645 contacts controller C for authorization to access node B and obtain 646 all the required information to do that securely (e.g. keys, tokens, 647 authorization information, etc.). This phase does NOT require the 648 usage of CoAP-EAP. The details of this phase are out of the scope of 649 this document, and the ACE framework is used for this purpose 650 [I-D.ietf-ace-oauth-authz]. 652 In the third phase, the node A can access node B with the credentials 653 and information obtained from the controller C in the second phase. 654 This access can be repeated without contacting the controller, while 655 the credentials given to A are still valid. The details of this 656 phase are out of scope of this document. 658 It is worth noting that first phase with CoAP-EAP is ONLY required to 659 join the controller C's domain. Once it is performed with success, 660 the communications are local to the controller C's domain so there is 661 no need to contact the external AAA server nor performing EAP 662 authentication. 664 5.2. Example 2: Multi-domain with AAA infrastructures 666 We assume we have a device (A) of the domain acme.org, which uses a 667 specific kind of credential (e.g., AKA) and intends to join the um.es 668 domain. This user does not belong to this domain, for which first it 669 performs a client registration using CoAP-EAP. For this, it 670 interacts with the Domain Controller acting as EAP authenticator, 671 which in turn communicates with a AAA infrastructure (acting as AAA 672 client). Through the local AAA server to communicate with the home 673 AAA server to complete the authentication and integrate the device as 674 a trustworthy entity into the domain of controller C. In this 675 scenario, the AS under the role of the Controller receives the key 676 material from the AAA infrastructure 678 5.3. Example 3: Single domain with AAA infrastructure 680 A University Campus, we have several Faculty buildings and each one 681 has its own criteria or policies in place to manage IoT devices under 682 an AS. All buildings belong to the same domain (e.g., um.es). All 683 these buildings are managed with a AAA infrastructure. A new device 684 (A) with credentials from the domain (e.g., um.es) will be able to 685 perform the device registration with a Controller (C) of any building 686 as long as they are managed by the same general domain. 688 5.4. Example 4: Single domain without AAA infrastructure 690 In another case, without a AAA infrastructure, we have a Controller 691 that has co-located the EAP server and using EAP standalone mode we 692 can manage all the devices within the same domain locally. Client 693 registration of a node (A) with Controller (C) can also be performed 694 in the same manner, transparent to the IoT device. In this scenario, 695 the communication with a AAA server is not used, nevertheless, we 696 have the capacity of adapting to more complex scenarios such as the 697 ones previously described. 699 5.5. Other use cases 701 5.5.1. CoAP-EAP for network access control 703 One of the first steps for an IoT device life-cycle is to perform the 704 authentication to gain access to the network. To do so, the device 705 first has to be authenticated and granted authorization to gain 706 access to the network. Additionally, security parameters such as 707 credentials can be derived from the authentication process allowing 708 the trustworthy operation of the IoT device in a particular network 709 by joining the security domain. By using EAP, we are able to achieve 710 this with flexibility and scalability, because of the different EAP 711 methods available and the ability to rely on AAA infrastructures if 712 needed to support multi-domain scenarios, which is a key feature when 713 the IoT devices deployed under the same security domain, belong to 714 different organizations. Given that EAP is also used for network 715 access control, we can adapt this service for other technologies. 716 For instance, to provide network access control to very constrained 717 technologies (e.g., LoRa network). In this specific case, we could 718 leverage the compression by SCHC for CoAP. 720 5.5.2. CoAP-EAP for service authentication 722 It is not uncommon that the infrastructure where the device is 723 deployed and the services of the IoT device are managed by different 724 organizations. Therefore, in addition to the authentication for 725 network access control, we have to consider the possibility of a 726 secondary authentication to access different services. This process 727 of authentication, for example, will provide with the necessary key 728 material to establish a secure channel and interact with the entity 729 in charge of granting access to different services. 731 6. Discussion 732 6.1. CoAP as EAP lower layer 734 In this section, we discuss the suitability of the CoAP protocol as 735 EAP lower layer, and review the requisites imposed by the EAP 736 protocol to any protocol that transports EAP. The assumptions EAP 737 makes about its lower layers can be found in section 3.1 of 738 [RFC3748], which are enumerated next: 740 o Unreliable transport. EAP does not assume that lower layers are 741 reliable. 743 o Lower layer error detection. EAP relies on lower layer error 744 detection (e.g., CRC, Checksum, MIC, etc.) 746 o Lower layer security. EAP does not require security services from 747 the lower layers. 749 o Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 750 octets or greater. 752 o Possible duplication. EAP stipulates that, while desirable, it 753 does not require for the lower layers to provide non-duplication. 755 o Ordering guarantees. EAP relies on lower layer ordering 756 guarantees for correct operation. 758 Regarding unreliable transport, although EAP assumes a non-reliable 759 transport, CoAP does provide a reliability mechanism through the use 760 of Confirmable messages. For the error detection, CoAP goes on top 761 of UDP which provides a checksum mechanism over its payload. Lower 762 layer security services are not required. About the minimum MTU of 763 1020 octets, CoAP assumes an upper bound of 1024 for its payload 764 which covers the requirements of EAP. Regarding message ordering, 765 every time a new message arrives at the bootstrapping service hosted 766 by the IoT device, a new resource is created and this is indicated in 767 a 2.01 Created response code along with the name of the new resource 768 via Location-Path or Location-Query. This way the application 769 indicates that its state has advanced. The name of the resource MAY 770 be represented following the naming "/b/x". Where "b" is the general 771 name of the bootstrapping service; "x" represents the resource 772 established to refer to the ongoing authentication exchange. 774 NOTE: This document does not assume any specific naming schema. The 775 only requisite that both CoAP client and server MUST agree, is the 776 establishment of a nomenclature indicates that the next URI used to 777 refer to a resource, univocally points to the next expected EAP 778 exchange. 780 Regarding the Token, we consider the use of a constant value. This 781 is because the EAP server will not send a new EAP request until it 782 has processed the expected EAP response. Additionally, we are under 783 the assumption that there will a single EAP authentication between 784 the constrained device and the same Controller. This would also 785 enable the possibility of using an Empty Token to reduce the number 786 of bytes. 788 As we can see, CoAP can fulfil the requirements of EAP to be 789 considered suitable as lower layer. 791 6.2. Size of the EAP lower layer vs EAP method size 793 Regarding the impact an EAP lower layer will have to the total byte 794 size of the whole exchange, there is a comparison with another 795 network layer based EAP lower layer, PANA [RFC5191] in [coap-eap]. 796 Authors compared focusing EAP lower layer (alone) and taking into 797 account EAP. On the one hand, at the EAP lower layer level, the 798 usage of CoAP gives important benefits. On the other hand, when 799 taking into account the EAP method overload, this reduction is less 800 but still significant if the EAP method is lightweight (we used EAP- 801 PSK as a representative example of a lightweight EAP method). If the 802 EAP method is very taxing the improvement achieved in the EAP lower 803 layer is less significant. This leads to the conclusion that 804 possible next steps in this field could be also improving or 805 designing new EAP methods that can be better adapted to the 806 requirements of constrained devices and networks. However, we cannot 807 ignore the impact of the EAP lower layer itself and try to propose 808 something lightweight as CoAP. We consider that may be other EAP 809 methods such as EAP-AKA or new lightweight EAP methods such as EAP- 810 EDHOC [I-D.ingles-eap-edhoc] that can benefit from a CoAP-based EAP 811 lower layer, as well as new ones that may be proposed in the future 812 with IoT constraints in mind. 814 6.3. Controller as the CoAP Client 816 Due to the constrained capacities of the devices, to relieve them of 817 the retransmission tasks, we set the Controller as the CoAP client, 818 for the main exchange following the recommendations of the 819 [I-D.ietf-lwig-coap] document to simplify the constrained device 820 implementation. 822 6.4. Possible Optimizations 823 6.4.1. Empty Token 825 Assuming that the bootstrapping service runs before any other 826 service, and that no other service will run concurrently until it has 827 finished, we could use an Empty Token value to save resources, since 828 there will be no other endpoint or CoAP exchange. 830 6.4.2. Further re-authentication 832 Since the initial bootstrapping is usually taxing, it is assumed to 833 be done only once over a long period of time. If further re- 834 authentications for refreshing the key material are necessary, there 835 are other methods that can be used to perform these re- 836 authentications. For example, the EAP re-authentication (ERP) 837 [RFC6696] can be used to avoid repeating the entire EAP exchange in 838 few exchanges. 840 7. Security Considerations 842 There are some aspects to be considered such as how authorization is 843 managed, how the cryptographic suite is selected and how the trust in 844 the Controller is established. 846 7.1. Authorization 848 Authorization is part of bootstrapping. It serves to establish 849 whether the node can join and the set of conditions it has to adhere. 850 The authorization data received from the AAA server can be delivered 851 by the AAA protocol (e.g. Diameter). Providing more fine-grained 852 authorization data can be with the transport of SAML in RADIUS 853 [RFC7833]. After bootstrapping, additional authorization to operate 854 in the security domain, e.g., access services offered by other nodes, 855 can be taken care of by the solutions proposed in the ACE WG. 857 7.2. Cryptographic suite selection 859 How the cryptographic suite is selected is also important. To reduce 860 the overhead of the protocol we use a default cryptographic suite. 861 As OSCORE is assumed to run after the EAP authentication, the same 862 default crypto-suite is used in this case as explained in the Key 863 Derivation Section Section 4 The cryptographic suite is not 864 negotiated. If the cryptographic suite to be used by the node is 865 different from the default, the AAA server will send the specific 866 parameters to the Authenticator. If the cryptographic suite is not 867 supported, the key derivation process would result in a security 868 association failure. 870 7.3. Freshness of the key material 872 In this design, we do not exchange nonces to provide freshness to the 873 keys derived from the MSK. This is done under the assumption that 874 the MSK and EMSK keys derived following the EAP KMF [RFC5247] are 875 fresh key material by the specifications of the EAP KMF. Since only 876 one session key is derived from the MSK we do not have to concern 877 ourselves with the generation of additional key material. In case 878 another session has to be established, a re-authentication can be 879 done, by running the process again, or using a more lightweight EAP 880 method to derive additional key material such as ERP [RFC6696]. 882 7.4. Additional Security Consideration 884 Other security-related concerns can be how to ensure that the node 885 joining the security domain can in fact trust the Controller. This 886 issue is elaborated in the EAP KMF [RFC5247]. To summarizing, the 887 node knows it can trust the Controller because the key that is used 888 to establish the security association is derived from the MSK. If 889 the Controller has the MSK, it is clear the AAA Server of the node 890 trusts the Controller, which confirms it is a trusted party. 892 8. IANA Considerations 894 TBD. 896 9. Acknowledgments 898 We would like to thank as the reviewers of this work: Carsten 899 Bormann, Benjamin Kaduk, Alexandre Petrescu, Pedro Moreno-Sanchez and 900 Eduardo Ingles-Sanchez. 902 We would also like to thank Gabriel Lopez-Millan for the first review 903 of this document and we would like to thank Ivan Jimenez-Sanchez for 904 the first proof-of-concept implementation of this idea. 906 And thank for their valuables comments to Alexander Pelov and Laurent 907 Toutain, especially for the potential optimizations of CoAP-EAP. 909 10. References 911 10.1. Normative References 913 [I-D.ietf-ace-oauth-authz] 914 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 915 H. Tschofenig, "Authentication and Authorization for 916 Constrained Environments (ACE) using the OAuth 2.0 917 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36 918 (work in progress), November 2020. 920 [I-D.ietf-lwig-coap] 921 Kovatsch, M., Bergmann, O., and C. Bormann, "CoAP 922 Implementation Guidance", draft-ietf-lwig-coap-06 (work in 923 progress), July 2018. 925 [I-D.ingles-eap-edhoc] 926 Sanchez, E., Garcia-Carrillo, D., and R. Marin-Lopez, "EAP 927 method based on EDHOC Authentication", draft-ingles-eap- 928 edhoc-01 (work in progress), November 2020. 930 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 931 Requirement Levels", BCP 14, RFC 2119, 932 DOI 10.17487/RFC2119, March 1997, 933 . 935 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 936 Levkowetz, Ed., "Extensible Authentication Protocol 937 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 938 . 940 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 941 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 942 2006, . 944 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 945 Advanced Encryption Standard-Cipher-based Message 946 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 947 PRF-128) Algorithm for the Internet Key Exchange Protocol 948 (IKE)", RFC 4615, DOI 10.17487/RFC4615, August 2006, 949 . 951 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 952 and A. Yegin, "Protocol for Carrying Authentication for 953 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 954 May 2008, . 956 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 957 Authentication Protocol (EAP) Key Management Framework", 958 RFC 5247, DOI 10.17487/RFC5247, August 2008, 959 . 961 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 962 "Specification for the Derivation of Root Keys from an 963 Extended Master Session Key (EMSK)", RFC 5295, 964 DOI 10.17487/RFC5295, August 2008, 965 . 967 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., 968 "EAP Extensions for the EAP Re-authentication Protocol 969 (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012, 970 . 972 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 973 Constrained-Node Networks", RFC 7228, 974 DOI 10.17487/RFC7228, May 2014, 975 . 977 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 978 Application Protocol (CoAP)", RFC 7252, 979 DOI 10.17487/RFC7252, June 2014, 980 . 982 [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A 983 RADIUS Attribute, Binding, Profiles, Name Identifier 984 Format, and Confirmation Methods for the Security 985 Assertion Markup Language (SAML)", RFC 7833, 986 DOI 10.17487/RFC7833, May 2016, 987 . 989 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 990 Bose, "Constrained Application Protocol (CoAP) Option for 991 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 992 August 2016, . 994 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 995 "Object Security for Constrained RESTful Environments 996 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 997 . 999 10.2. Informative References 1001 [coap-eap] 1002 Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP- 1003 Based Bootstrapping Service for the Internet of Things - 1004 https://www.mdpi.com/1424-8220/16/3/358", March 2016. 1006 Authors' Addresses 1008 Rafa Marin-Lopez 1009 University of Murcia 1010 Campus de Espinardo S/N, Faculty of Computer Science 1011 Murcia 30100 1012 Spain 1014 Phone: +34 868 88 85 01 1015 Email: rafa@um.es 1017 Dan Garcia-Carrillo 1018 University of Oviedo 1019 Calle Luis Ortiz Berrocal S/N, Edificio Polivalente 1020 Gijon, Asturias 33203 1021 Spain 1023 Email: garciadan@uniovi.es