idnits 2.17.1 draft-ietf-ace-wg-coap-eap-02.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 (June 14, 2021) is 1037 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 456, but not defined == Missing Reference: '0x7654' is mentioned on line 483, but not defined == Missing Reference: '0x8694' is mentioned on line 477, but not defined == Missing Reference: '0x9869' is mentioned on line 313, but not defined == Missing Reference: '0x7811' is mentioned on line 325, 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: December 16, 2021 University of Oviedo 6 June 14, 2021 8 EAP-based Authentication Service for CoAP 9 draft-ietf-ace-wg-coap-eap-02 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 December 16, 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. Managing the State of the Service . . . . . . . . . . . . . . 11 66 4.1. Deleting the state . . . . . . . . . . . . . . . . . . . 12 67 4.2. Renewing the state . . . . . . . . . . . . . . . . . . . 12 68 5. Key Derivation for protecting CoAP messages . . . . . . . . . 13 69 5.1. Deriving the OSCORE Security Context . . . . . . . . . . 13 70 5.2. Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . . 14 71 6. Examples of Use Case Scenario . . . . . . . . . . . . . . . . 14 72 6.1. Example 1: CoAP-EAP in ACE . . . . . . . . . . . . . . . 15 73 6.2. Example 2: Multi-domain with AAA infrastructures . . . . 16 74 6.3. Example 3: Single domain with AAA infrastructure . . . . 17 75 6.4. Example 4: Single domain without AAA infrastructure . . . 17 76 6.5. Other use cases . . . . . . . . . . . . . . . . . . . . . 17 77 6.5.1. CoAP-EAP for network access control . . . . . . . . . 17 78 6.5.2. CoAP-EAP for service authentication . . . . . . . . . 17 79 7. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 18 80 7.1. CoAP as EAP lower layer . . . . . . . . . . . . . . . . . 18 81 7.2. Size of the EAP lower layer vs EAP method size . . . . . 19 82 7.3. Controller as the CoAP Client . . . . . . . . . . . . . . 19 83 7.4. Possible Optimizations . . . . . . . . . . . . . . . . . 20 84 7.4.1. Empty Token . . . . . . . . . . . . . . . . . . . . . 20 85 7.4.2. Further re-authentication . . . . . . . . . . . . . . 20 86 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 87 8.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 20 88 8.2. Cryptographic suite selection . . . . . . . . . . . . . . 20 89 8.3. Freshness of the key material . . . . . . . . . . . . . . 21 90 8.4. Additional Security Consideration . . . . . . . . . . . . 21 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 92 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 95 11.2. Informative References . . . . . . . . . . . . . . . . . 23 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 98 1. Introduction 100 The goal of this document is to describe an authentication service 101 that uses the Extensible Authentication Protocol (EAP) [RFC3748]. 102 The authentication service is built on top of the Constrained 103 Application Protocol (CoAP) [RFC7252] and allows authenticating two 104 CoAP endpoints by using EAP, to establish a security association 105 between them. 107 In particular, this document describes 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 (EAP peer) and a CoAP 110 client (EAP authenticator) using CoAP messages. The CoAP client MAY 111 contact with a backend AAA infrastructure to complete the EAP 112 negotiation as described in the EAP specification [RFC3748]. 114 The assumption is that the EAP method transported in CoAP MUST 115 generate cryptographic material [RFC5247]. In this way, the CoAP 116 messages can be protected after the authentication. The general flow 117 of operation of CoAP-EAP establishes an OSCORE security association 118 specifically for the service. In addition, using the key material 119 derived from the authentication, we specify the establishment of 120 other security associations depending on the security requirements of 121 the services: 123 o OSCORE [RFC8613] security association can be established based on 124 the cryptographic material generated from the EAP authentication. 126 o A DTLS security association can be established using the exported 127 cryptographic material after a successful EAP authentication. 129 This document also indicates how to establish a security association 130 for other types of technologies that rely on CoAP. 132 1.1. Requirements Language 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 138 2. General Architecture 140 Figure 1 shows the architecture defined in this document. Basically, 141 a node acting as the EAP peer wants to be authenticated by using EAP. 142 At the time of writing this document, we have considered a model 143 where the entity acting as EAP peer will also act as a CoAP server 144 for this service and the entity acting as EAP authenticator will act 145 as a CoAP client and MAY interact with a backend AAA infrastructure, 146 which will place the EAP server and contain the information required 147 to authenticate the CoAP client. The rationale behind this decision, 148 as we will expand later, is that EAP requests go always from the EAP 149 authenticator to the EAP peer. Accordingly, the EAP responses go 150 from the EAP peer to the EAP authenticator. 152 +------------+ +------------+ 153 | EAP peer/ | | EAP auth./ | 154 | CoAP server|+------+| CoAP client| 155 +------------+ CoAP +------------+ 157 Figure 1: CoAP EAP Architecture 159 3. General Flow Operation 161 The authentication service uses CoAP as transport for EAP. In other 162 words, CoAP becomes an EAP lower layer in EAP terminology. In 163 general, it is assumed that, since the EAP authenticator MAY 164 implement an AAA client to interact with the AAA infrastructure, this 165 endpoint will have more resources or, at least, will not be so 166 constrained device. We show the sequence flow in Figure 2 where we 167 depict the usage of a generic EAP method that we call EAP-X as an 168 authentication mechanism. (NOTE: any EAP method that can export 169 cryptographic material is valid. For example, EAP-MD5 cannot be used 170 since it does not export key material). 172 The first step to run CoAP-EAP is for the IoT device to discover the 173 Controller, and that it implements the CoAP-EAP service. To do so, 174 we rely on the discovery mechanism of CoAP. The URI of the CoAP-EAP 175 service CAN be set to "/b" to save bytes over the air. The IoT 176 device will always start the conversation sending the first message, 177 acting as CoAP client only on this instance, to implement a trigger 178 mechanism to let the Controller know it is ready for an 179 authentication process to start. 181 The first message is used to trigger the authentication process. 182 This message is sent by the IoT device, acting as a CoAP client. 183 This message uses the No-Response Option [RFC7967] to avoid the 184 response from the Controller to this message. After this, the 185 exchange continues with the Controller acting as a CoAP client and 186 the IoT device acting as a CoAP server. This is because the IoT 187 device could be a constrained node, and following the recommendations 188 of [I-D.ietf-lwig-coap] to simplify the implementation of the IoT 189 device, the Controller takes the responsibility of handling the 190 retransmissions. In the next section, we refer to the IoT device as 191 the EAP peer and the Controller as the EAP authenticator to elaborate 192 the specifics of the flow of operation. 194 3.1. EAP over CoAP flow of operation 196 If the EAP peer discovers the presence of the EAP authenticator and 197 wants to start the authentication, it can send a Non-Confirmable 198 "POST /b" request to the node (Step 0). This message will carry an 199 option developed in the work of [RFC7967] called 'No-Response'. The 200 rationale of this option is to avoid waiting for a response if it is 201 not needed. So the use of this option will allow signalling the 202 intention the EAP peer to start the authentication process. 203 Immediately after that, the EAP authenticator will start 204 authentication service. 206 In any case, to perform the authentication service, the CoAP client 207 (EAP authenticator) sends a Confirmable "POST /b" request to the CoAP 208 Server (Step 1). After receiving the first POST, the CoAP server 209 assigns a resource and answers with an Acknowledgment with the piggy- 210 backed response containing the resource identifier (Location-Path) 211 (Step 2). The name of the resource MAY be represented following the 212 naming "/b/x". Where "b" is the general name of the bootstrapping 213 service; "x" represents the resource established to process the 214 following message of the authentication. This CoAP server can select 215 this value as pleased, as long as, it serves to process the following 216 message adequately. It is assumed that the CoAP server will only 217 have an ongoing authentication with that particular CoAP client and 218 will not process simultaneous EAP authentications in parallel (with 219 the same EAP authenticator) to save resources. 221 In this exchange (Step 1 and 2), the EAP Req/Id and Rep/Id messages 222 are exchanged between the EAP authenticator and the EAP peer. Upon 223 the reception of the EAP Req/Id message, the EAP authenticator 224 forwards this message, when EAP is in pass-through mode, to the local 225 AAA server. The AAA server is in charge of steering the 226 conversation, choosing the EAP method to be used (e.g. EAP-X) if the 227 user is local, or sending the EAP messages to the home AAA of the EAP 228 peer. At this point, the CoAP server has created a resource for the 229 EAP authentication. The resource identifier value will be used to 230 relate the EAP conversation between both CoAP endpoints. 232 NOTE: Since only an ongoing EAP authentication is permitted per EAP 233 authenticator/EAP client, and EAP is a lock-step protocol, a Token of 234 a constant value can be used throughout the authentication process. 235 An empty Token could be considered to reduce bytes. 237 From now on, the EAP authenticator and the EAP peer will exchange EAP 238 packets related to the EAP method, transported in the CoAP message 239 payload (Steps 3,4,5,6). The EAP authenticator will use the POST 240 method to send EAP requests to the EAP peer. The EAP peer will use a 241 Piggy-backed response in the Acknowledgment message to carry the EAP 242 response. When all the message exchange is completed, if everything 243 has gone well, the EAP authenticator can send an EAP Success message, 244 and both CoAP endpoints will share a Master Session Key (MSK) 245 ([RFC5295]) 247 To establish a security association that will confirm to the EAP peer 248 that EAP authenticator received the MSK from the AAA server, as well 249 as to the EAP authenticator that the EAP peer derived the MSK 250 correctly, both entities engage in the establishment of a security 251 association. In the context of constrained devices [RFC7228] and 252 networks, we consider protocols that are designed for these cases. 253 Concretely, we show here in the diagram the establishment of the 254 OSCORE security association (Steps 7 and 8). From that point, any 255 exchange between both CoAP endpoints is protected with OSCORE. 256 Before sending the EAP success to the EAP peer, the EAP authenticator 257 can derive the OSCORE Security Context, to confirm the establishment 258 of the security association. The details of the establishment of the 259 OSCORE Security Context are discussed in Section Section 5.1. The 260 protection of the EAP Success is not a requirement. Here, we specify 261 this exchange as protected by the lower layer with OSCORE. The 262 purpose is double, we can avoid forgery of this message and we are 263 using the exchange to perform the key confirmation through the 264 establishment of the OSCORE security association. Adding to the 265 previous consideration about the EAP Success, this message does not 266 prevent the operation of the device from continuing as long as there 267 is an alternate success indication that both the EAP peer and 268 authentication can rely on to continue [RFC3748]. This indication 269 can happen in two ways: 1) the reception of the CoAP message without 270 EAP and with an OSCORE option (following the normal operational 271 communication between both entities) is an indication that the 272 controller considers the EAP authentication finished. 2) the IoT 273 device knows that the EAP authentication went well if an MSK is 274 available. Both entities need to prove the possession of the MSK as 275 mentioned in the EAP KMF. 277 EAP peer EAP Auth. 278 (CoAP server) (CoAP client) 279 ------------- ------------- 280 | | 281 | NON [0x6af5] POST /b | 282 | Token (0xab) | 283 0) | No-Response | 284 |---------------------------------------->| 285 | | 286 | CON [0x7654] POST /b | 287 | Token (0xac) | 288 | Payload EAP Req/Id | 289 1) |<----------------------------------------| 290 | | 291 | ACK [0x7654] | 292 | Token (0xac) | 293 | 2.01 Created Location-Path [/b/x] | 294 | Payload EAP Rep/Id | 295 2) |---------------------------------------->| 296 | | 297 | CON [0x8694] POST /b/x | 298 | Token (0xac) | 299 | Payload EAP-X MSG 1 | 300 3) |<----------------------------------------| 301 | | 302 | ACK [0x8694] | 303 | Token (0xac) | 304 | 2.01 Created Location-Path [/b/y] | 305 | Payload EAP-X MSG 2 | 306 4) |---------------------------------------->| 307 .... 308 | CON [0x9869] POST /b/y | 309 | Token (0xac) | 310 | Payload EAP-X MSG (n-1) | 311 5) |<----------------------------------------| 312 | | 313 | ACK [0x9869] | 314 | Token (0xac) | 315 | 2.01 Created Location-Path [/b/z] | 316 | Payload EAP-X MSG (n) | MSK 317 6) |---------------------------------------->| | 318 | | V 319 | CON [0x7811] POST /b/z |OSCORE 320 | Token (0xac) |CONTEXT 321 | OSCORE Option | (*) 322 | Payload EAP success | 323 MSK 7) |<----------------------------------------| 324 | | | 325 V (*) | ACK [0x7811] | 326 OSCORE | Token (0xac) | 327 CONTEXT | OSCORE Option | 328 8) |---------------------------------------->| 329 (*) Protected with OSCORE 331 Figure 2: CoAP-EAP flow of operation 333 3.2. Message processing of EAP over CoAP 335 In this section, we introduce how the service is processed by the two 336 entities involved in the exchange. 338 For the CoAP server, each time a new CoAP request arrives, containing 339 the EAP message as payload, does the following: 341 1. Send the EAP message to the EAP state machine 343 2. If the EAP state machine processes the request correctly: 345 A. A new resource is created. (e.g. b/y) 347 B. The current resource is deleted. (e.g. b/x) 349 C. A response is sent back to the client specifying the new 350 resource 352 3. If the EAP state machine returns an error: 354 A. The CoAP service will send an error message. (e.g: 4.00 Bad 355 Request) 357 When the EAP authenticator (CoAP client) receives an EAP message from 358 the EAP peer (CoAP server), it will send it to the EAP server, and 359 vice-versa. In any case, the EAP exchange is initiated by the EAP 360 authenticator, sending the EAP Request/Identity message to the EAP 361 peer and the ongoing authentication will be tracked by a 362 bootstrapping state where all the relevant information for the 363 application is stored, such as the current URI for the exchange (or 364 the expected URI for the next exchange). From that point on, the 365 processing of the messages continues as follows: 367 1. If the ongoing message is an EAP request, is sent to the EAP 368 peer. If it is an EAP response, it is sent to the EAP server. 370 2. If a CoAP response containing the new resource and the EAP 371 response arrives, the new CoAP resource is updated. 373 3. If an error arrives, the CoAP client will rely on CoAP 374 retransmission behavior. 376 3.3. EAP over CoAP operation casuistics 378 In this section, we introduce a couple of cases where a message is 379 lost and retransmitted later, to show how the service will react. 380 The first one shows what would happen if a piggybacked response with 381 a new resource identifier is lost. This case is illustrated in 382 Figure 3. The second shows what would happen if an old request 383 message arrives even though the process of authentication continued 384 due to normal retransmission behaviour. This is illustrated in 385 Figure 4. 387 For the first case, when a piggybacked response message containing 388 the Location-Path of the new resource is lost, the CoAP client will 389 retransmit. This will cause the CoAP server to recognize the message 390 as retransmission due to the MSG-ID, and re-send the lost message. 392 EAP peer EAP Auth. 393 (CoAP server) (CoAP client) 394 ------------- ------------- 395 | | 396 | NON [0x6af5] POST /b | 397 | Token (0xab) | 398 0) | No-Response | 399 |---------------------------------------->| 400 | | 401 | CON [0x7654] POST /b | 402 | Token (0xac) | 403 | Payload EAP Req/Id | 404 1) |<----------------------------------------| 405 | | 406 | ACK [0x7654] | 407 | Token (0xac) | 408 | 2.01 Created Location-Path [/b/x] | 409 | Payload EAP Rep/Id | 410 2) |---------------------------->X | 411 | | 412 | CON [0x7654] POST /b | 413 | Token (0xac) | 414 | Payload EAP Req/Id | 415 1) |<----------------------------------------| 416 | | 417 | ACK [0x7654] | 418 | Token (0xac) | 419 | 2.01 Created Location-Path [/b/x] | 420 | Payload EAP Rep/Id | 421 2) |---------------------------------------->| 423 Figure 3: Casuistic - Response Lost 425 In the second case, when a message is lost, but due to the ongoing 426 workings of CoAP retransmission, the flow of operation continues as 427 expected. If said lost message arrives later, how this message is 428 handled will depend on which layer deals with it. 430 1. If the message is handled by the CoAP messaging layer, which 431 means it will not go up to the service application: 433 A. As the server recognizes the old message, due to internal 434 tracking, it can send a stored copy of the response. 436 B. Then the client would recognize the MSGID as old and that he 437 got the response already, and simply dropping it. 439 2. If the messaging layer does not recognize the message as old, and 440 takes care of it, it will try to send it to the service 441 application: 443 A. This will cause an error, since a resource of a previous step 444 of the authentication is deleted 446 B. The error code (e.g., 4.04 Not Found) with the same MSGID is 447 sent back to the CoAP client. 449 C. The CoAP client would recognize the MSGID as old and simply 450 drop it. 452 EAP peer EAP Auth. 453 (CoAP server) (CoAP client) 454 ------------- ------------- 455 | | 456 | NON [0x6af5] POST /b | 457 | Token (0xab) | 458 0) | No-Response | 459 |---------------------------------------->| 460 | | 461 | CON [0x7654] POST /b | 462 | Token (0xac) | 463 | Payload EAP Req/Id | 464 1) |<----------------------------------------| 465 | | 466 | ACK [0x7654] | 467 | Token (0xac) | 468 | 2.01 Created Location-Path [/b/x] | 469 | Payload EAP Rep/Id | 470 2) |---------------------------------------->| 471 | | 472 | CON [0x8694] POST /b/x | 473 | Token (0xac) | 474 | Payload EAP-X MSG 1 | 475 3) |<----------------------------------------| 476 | | 477 | ACK [0x8694] | 478 | Token (0xac) | 479 | 2.01 Created Location-Path [/b/y] | 480 | Payload EAP-X MSG 2 | 481 4) |---------------------------------------->| 482 | | 483 | CON [0x7654] POST /b | 484 | Token (0xac) | 485 | Payload EAP Req/Id |(Old message) 486 1) |<----------------------------------------| 488 Figure 4: Casuistic - Old message 490 4. Managing the State of the Service 492 This document establishes the generation of a resource under the 493 service identified by the URI '/b'. Once the authentication process 494 is completed and the final representation of the bootstrapping state 495 is returned to the CoAP client (e.g., /b/z in Figure 2) there are 496 different interactions that may be of interest with regard to the 497 bootstrapping state. 499 4.1. Deleting the state 501 There are situations where the current bootstrapping state might need 502 to be removed. For instance due to its expiration or a forced 503 removal if the device needs to be expelled from the security domain. 504 If the Controller, which implements the CoAP client in this exchange, 505 deems necessary the removal of the state, it can send a DELETE 506 command to the CoAP server, referencing the boostrapping state 507 resource. The identifier will be the last one received with the ACK 508 of the EAP success message (/b/z in Figure 2) This message will be 509 protected with the OSCORE security association to prevent forgery. 510 Upon reception of this message, the CoAP server sends a piggybacked 511 response to the client with the Code 2.02 Deleted. In the case, 512 there is no ACK and response from the CoAP server, after the maximum 513 retransmission attempts, the CoAP client will remove the state from 514 its side. The repercussion in this case will translate in 515 unauthorized communications from the IoT device towards the 516 Controller within the security domain. 518 4.2. Renewing the state 520 When the state is close to expire the state might be renewed. This 521 situation causes the possible duplication of states until the new 522 state is generated and the previous one can be deleted. This re- 523 authentication can be done using again the same EAP method, or a more 524 lightweight (e.g., ERP [RFC6696]) could be used, if available. The 525 exchange will be done in this case maintaining ongoing OSCORE 526 security association as long as it is still valid. In other case, 527 the exchange will be done as if it were new (see Figure 2). The re- 528 authentication will be initiated by the IoT device (CoAP server), 529 which is the interested party in maintaining a security association 530 active. This is purposely done this way to avoid unnecessary or 531 unwanted authentication messages, unless the IoT device is ready to 532 start the process. This means, the IoT device will send the trigger 533 message and will only process messages related to a re-authentication 534 after it has sent the trigger message. The exchange will be very 535 similar to the one in Figure 2. In fact, if everything goes well, 536 there will be indistinguishable, up to the final exchange of the EAP 537 success message and its response, which will be protected with the 538 new OSCORE security association, using keys derived from the new EAP 539 exchange. The difference will be in the case an EAP failure is 540 generated. In the initial exchange, since no key material is derived 541 due to a failed authentication, this message is not protected with 542 OSCORE. In the reauthentication scenario, the EAP failure will be 543 protected with the ongoing OSCORE security association. In case of 544 failure by any reason, the old state will be valid until its 545 expiration. 547 5. Key Derivation for protecting CoAP messages 549 As a result of a successful EAP authentication, both the CoAP server 550 and CoAP client share a Master Key Session (MSK). The assumption is 551 that MSK is a fresh key, so any key derived from the MSK will be also 552 fresh. To complete the CoAP-EAP exchange, as part of the design, it 553 is expected the establishment of an OSCORE security association 554 specifically for the CoAP-EAP service. The security level for the 555 CoAP-EAP exchanges with OSCORE is with integrity. Additionally, we 556 considered the derivation of either the OSCORE Security Context or a 557 pre-shared key that can be used for a DTLS negotiation (DTLS_PSK) for 558 further communications depending on the security requirements of the 559 services provided by the AS. The OSCORE security context generated 560 for CoAP-EAP could be generalized to enable further OSCORE secured 561 communications between the IoT device and the AS services that 562 require the use of OSCORE. 564 5.1. Deriving the OSCORE Security Context 566 Key material needed to derive the OSCORE Security Context, from the 567 MSK can be done as follows: 569 The Master Secret can be derived by using AES-CMAC-PRF-128 [RFC4615], 570 which, in turn, uses AES-CMAC-128 [RFC4493]. The Master Secret can 571 be derived as follows: 573 Master_Secret = KDF(MSK, "IETF_OSCORE_MASTER_SECRET", 64, length) 575 where: 577 o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses 578 AES-CMAC-128 as a building block. 580 o The MSK exported by the EAP method, which by design is a fresh key 581 material. Discussions about the use of the MSK for the key 582 derivation are done in Section Section 8. 584 o "IETF_OSCORE_MASTER_SECRET" is the ASCII code representation of 585 the non-NULL terminated string (excluding the double quotes around 586 it). 588 o 64 is the length of the MSK. 590 o length is the length of the label "IETF_OSCORE_MASTER_SECRET" (25 591 bytes). 593 The Master Salt, similarly to the Master Secret, can be derived as 594 follows: 596 Master_Salt = KDF(MSK, "IETF_OSCORE_MASTER_SALT", 64, length) 598 where: 600 o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses 601 AES-CMAC-128 as a building block. 603 o The MSK exported by the EAP method, which by design is a fresh key 604 material. Discussions about the use of the MSK for the key 605 derivation are done in Section Section 8. 607 o "IETF_OSCORE_MASTER_SALT" is the ASCII code representation of the 608 non-NULL terminated string (excluding the double quotes around 609 it). 611 o 64 is the length of the MSK. 613 o length is the length of the label "IETF_OSCORE_MASTER_SALT" (23 614 bytes). 616 The ID Context can be set to the identity of the EAP peer. 618 5.2. Deriving DTLS_PSK 620 In the second alternative, a DTLS_PSK is derived from the MSK between 621 both CoAP endpoints. The length of the DTLS_PSK will depend on the 622 cipher-suite. For AES-128, the DTLS_PSK will have a 16-byte length 623 and it will be derived as follows: 625 DTLS_PSK = KDF(MSK, "IETF_DTLS_PSK" , 64, length). This value is 626 concatenated with the value of the Token Option value. 628 where: 630 o MSK is exported by the EAP method. 632 o "IETF_DTLS_PSK" is the ASCII code representation of the non-NULL 633 terminated string (excluding the double quotes around it). 635 o 64 is the length of the MSK. 637 o length is the length of the label "IETF_DTLS_PSK" (13 bytes). 639 6. Examples of Use Case Scenario 641 For a device to act as a trustworthy entity within a security domain, 642 certain key material is needed to be shared between the IoT device 643 and AS. In ACE, the process of Client registration and provisioning 644 of credentials to the client is not specified. The process of Client 645 registration and provisioning can be achieved by using CoAP-EAP. 646 Once the process of authentication with EAP is completed, a fresh key 647 material is shared between the IoT device and the AS. 649 Next, we elaborate on examples of different use case scenarios about 650 the usage of CoAP-EAP. Generally, we are dealing with 4 entities: 652 o 2 nodes (A and B), which are constrained devices. They are the 653 EAP peers. 655 o 1 controller (C). The controller manages a domain where nodes can 656 be deployed. It can be considered a more powerful machine than 657 the nodes. In this scenario, the Controller (and EAP 658 Authenticator), can be co-located with the AS. 660 o 1 AAA server (AAA) - Optional. The AAA is an Authentication, 661 Authorization and Accounting Server, which is not constrained. 663 Generally, any node wanting to join the domain managed by the 664 controller MUST perform a CoAP-EAP authentication with the controller 665 C. This authentication MAY involve an external AAA server. This 666 means that A and B, once deployed, will perform this CoAP-EAP once as 667 a bootstrapping phase to establish a security association with 668 controller C. Moreover, any other entity, which wants to join and 669 establish communications with nodes under controller C's domain must 670 also do the same. By using EAP, we can have the flexibility of 671 having different types of credentials. For instance, if we have a 672 device that is not battery dependent, and not very constrained, we 673 could use a heavier authentication method. With very constrained 674 devices and networks we might need to resort to more lightweight 675 authentication methods (e.g., EAP-PSK, EAP-EDHOC, etc.) being able to 676 adapt to different types of devices according to policies or devices 677 capabilities. 679 6.1. Example 1: CoAP-EAP in ACE 681 Next, we exemplify how CoAP-EAP can be used to perform the Client 682 registration in a general way, to allow two IoT devices (A and B) to 683 communicate and interact after a successful client registration. 685 Node A wants to communicate with node B (e.g. to activate a light 686 switch). The overall process is divided into three phases. Let's 687 start with node A. In the first phase, the node A (EAP peer) does 688 not yet belong to controller C's domain. Then, it communicates with 689 controller C (EAP authenticator) and authenticates with CoAP-EAP, 690 which, optionally, communicates with the AAA server to complete the 691 authentication process. If the authentication is successful, key 692 material is distributed to controller C and derived by node A. This 693 key material allows node A to establish a security association with 694 the controller (C). Some authorization information may be also 695 provided in this step. If authentication and authorization are 696 correct, node A is enrolled in controller C's domain for a period of 697 time. In particular, [RFC5247] recommends 8 hours, though the AAA 698 server can establish this lifetime. In the same manner, B needs to 699 perform the same process with CoAP-EAP to be part of the controller 700 C's domain. 702 In the second phase, when node A wants to talk with node B, it 703 contacts controller C for authorization to access node B and obtain 704 all the required information to do that securely (e.g. keys, tokens, 705 authorization information, etc.). This phase does NOT require the 706 usage of CoAP-EAP. The details of this phase are out of the scope of 707 this document, and the ACE framework is used for this purpose 708 [I-D.ietf-ace-oauth-authz]. 710 In the third phase, the node A can access node B with the credentials 711 and information obtained from the controller C in the second phase. 712 This access can be repeated without contacting the controller, while 713 the credentials given to A are still valid. The details of this 714 phase are out of scope of this document. 716 It is worth noting that first phase with CoAP-EAP is ONLY required to 717 join the controller C's domain. Once it is performed with success, 718 the communications are local to the controller C's domain so there is 719 no need to contact the external AAA server nor performing EAP 720 authentication. 722 6.2. Example 2: Multi-domain with AAA infrastructures 724 We assume we have a device (A) of the domain acme.org, which uses a 725 specific kind of credential (e.g., AKA) and intends to join the um.es 726 domain. This user does not belong to this domain, for which first it 727 performs a client registration using CoAP-EAP. For this, it 728 interacts with the Domain Controller acting as EAP authenticator, 729 which in turn communicates with a AAA infrastructure (acting as AAA 730 client). Through the local AAA server to communicate with the home 731 AAA server to complete the authentication and integrate the device as 732 a trustworthy entity into the domain of controller C. In this 733 scenario, the AS under the role of the Controller receives the key 734 material from the AAA infrastructure 736 6.3. Example 3: Single domain with AAA infrastructure 738 A University Campus, we have several Faculty buildings and each one 739 has its own criteria or policies in place to manage IoT devices under 740 an AS. All buildings belong to the same domain (e.g., um.es). All 741 these buildings are managed with a AAA infrastructure. A new device 742 (A) with credentials from the domain (e.g., um.es) will be able to 743 perform the device registration with a Controller (C) of any building 744 as long as they are managed by the same general domain. 746 6.4. Example 4: Single domain without AAA infrastructure 748 In another case, without a AAA infrastructure, we have a Controller 749 that has co-located the EAP server and using EAP standalone mode we 750 can manage all the devices within the same domain locally. Client 751 registration of a node (A) with Controller (C) can also be performed 752 in the same manner, transparent to the IoT device. In this scenario, 753 the communication with a AAA server is not used, nevertheless, we 754 have the capacity of adapting to more complex scenarios such as the 755 ones previously described. 757 6.5. Other use cases 759 6.5.1. CoAP-EAP for network access control 761 One of the first steps for an IoT device life-cycle is to perform the 762 authentication to gain access to the network. To do so, the device 763 first has to be authenticated and granted authorization to gain 764 access to the network. Additionally, security parameters such as 765 credentials can be derived from the authentication process allowing 766 the trustworthy operation of the IoT device in a particular network 767 by joining the security domain. By using EAP, we are able to achieve 768 this with flexibility and scalability, because of the different EAP 769 methods available and the ability to rely on AAA infrastructures if 770 needed to support multi-domain scenarios, which is a key feature when 771 the IoT devices deployed under the same security domain, belong to 772 different organizations. Given that EAP is also used for network 773 access control, we can adapt this service for other technologies. 774 For instance, to provide network access control to very constrained 775 technologies (e.g., LoRa network). In this specific case, we could 776 leverage the compression by SCHC for CoAP. 778 6.5.2. CoAP-EAP for service authentication 780 It is not uncommon that the infrastructure where the device is 781 deployed and the services of the IoT device are managed by different 782 organizations. Therefore, in addition to the authentication for 783 network access control, we have to consider the possibility of a 784 secondary authentication to access different services. This process 785 of authentication, for example, will provide with the necessary key 786 material to establish a secure channel and interact with the entity 787 in charge of granting access to different services. 789 7. Discussion 791 7.1. CoAP as EAP lower layer 793 In this section, we discuss the suitability of the CoAP protocol as 794 EAP lower layer, and review the requisites imposed by the EAP 795 protocol to any protocol that transports EAP. The assumptions EAP 796 makes about its lower layers can be found in section 3.1 of 797 [RFC3748], which are enumerated next: 799 o Unreliable transport. EAP does not assume that lower layers are 800 reliable. 802 o Lower layer error detection. EAP relies on lower layer error 803 detection (e.g., CRC, Checksum, MIC, etc.) 805 o Lower layer security. EAP does not require security services from 806 the lower layers. 808 o Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 809 octets or greater. 811 o Possible duplication. EAP stipulates that, while desirable, it 812 does not require for the lower layers to provide non-duplication. 814 o Ordering guarantees. EAP relies on lower layer ordering 815 guarantees for correct operation. 817 Regarding unreliable transport, although EAP assumes a non-reliable 818 transport, CoAP does provide a reliability mechanism through the use 819 of Confirmable messages. For the error detection, CoAP goes on top 820 of UDP which provides a checksum mechanism over its payload. Lower 821 layer security services are not required. About the minimum MTU of 822 1020 octets, CoAP assumes an upper bound of 1024 for its payload 823 which covers the requirements of EAP. Regarding message ordering, 824 every time a new message arrives at the bootstrapping service hosted 825 by the IoT device, a new resource is created and this is indicated in 826 a 2.01 Created response code along with the name of the new resource 827 via Location-Path or Location-Query. This way the application 828 indicates that its state has advanced. The name of the resource MAY 829 be represented following the naming "/b/x". Where "b" is the general 830 name of the bootstrapping service; "x" represents the resource 831 established to refer to the ongoing authentication exchange. 833 NOTE: This document does not assume any specific naming schema. The 834 only requisite that both CoAP client and server MUST agree, is the 835 establishment of a nomenclature indicates that the next URI used to 836 refer to a resource, univocally points to the next expected EAP 837 exchange. 839 Regarding the Token, we consider the use of a constant value. This 840 is because the EAP server will not send a new EAP request until it 841 has processed the expected EAP response. Additionally, we are under 842 the assumption that there will a single EAP authentication between 843 the constrained device and the same Controller. This would also 844 enable the possibility of using an Empty Token to reduce the number 845 of bytes. 847 As we can see, CoAP can fulfil the requirements of EAP to be 848 considered suitable as lower layer. 850 7.2. Size of the EAP lower layer vs EAP method size 852 Regarding the impact an EAP lower layer will have to the total byte 853 size of the whole exchange, there is a comparison with another 854 network layer based EAP lower layer, PANA [RFC5191] in [coap-eap]. 855 Authors compared focusing EAP lower layer (alone) and taking into 856 account EAP. On the one hand, at the EAP lower layer level, the 857 usage of CoAP gives important benefits. On the other hand, when 858 taking into account the EAP method overload, this reduction is less 859 but still significant if the EAP method is lightweight (we used EAP- 860 PSK as a representative example of a lightweight EAP method). If the 861 EAP method is very taxing the improvement achieved in the EAP lower 862 layer is less significant. This leads to the conclusion that 863 possible next steps in this field could be also improving or 864 designing new EAP methods that can be better adapted to the 865 requirements of constrained devices and networks. However, we cannot 866 ignore the impact of the EAP lower layer itself and try to propose 867 something lightweight as CoAP. We consider that may be other EAP 868 methods such as EAP-AKA or new lightweight EAP methods such as EAP- 869 EDHOC [I-D.ingles-eap-edhoc] that can benefit from a CoAP-based EAP 870 lower layer, as well as new ones that may be proposed in the future 871 with IoT constraints in mind. 873 7.3. Controller as the CoAP Client 875 Due to the constrained capacities of the devices, to relieve them of 876 the retransmission tasks, we set the Controller as the CoAP client, 877 for the main exchange following the recommendations of the 878 [I-D.ietf-lwig-coap] document to simplify the constrained device 879 implementation. 881 7.4. Possible Optimizations 883 7.4.1. Empty Token 885 Assuming that the bootstrapping service runs before any other 886 service, and that no other service will run concurrently until it has 887 finished, we could use an Empty Token value to save resources, since 888 there will be no other endpoint or CoAP exchange. 890 7.4.2. Further re-authentication 892 Since the initial bootstrapping is usually taxing, it is assumed to 893 be done only once over a long period of time. If further re- 894 authentications for refreshing the key material are necessary, there 895 are other methods that can be used to perform these re- 896 authentications. For example, the EAP re-authentication (ERP) 897 [RFC6696] can be used to avoid repeating the entire EAP exchange in 898 few exchanges. 900 8. Security Considerations 902 There are some aspects to be considered such as how authorization is 903 managed, how the cryptographic suite is selected and how the trust in 904 the Controller is established. 906 8.1. Authorization 908 Authorization is part of bootstrapping. It serves to establish 909 whether the node can join and the set of conditions it has to adhere. 910 The authorization data received from the AAA server can be delivered 911 by the AAA protocol (e.g. Diameter). Providing more fine-grained 912 authorization data can be with the transport of SAML in RADIUS 913 [RFC7833]. After bootstrapping, additional authorization to operate 914 in the security domain, e.g., access services offered by other nodes, 915 can be taken care of by the solutions proposed in the ACE WG. 917 8.2. Cryptographic suite selection 919 How the cryptographic suite is selected is also important. To reduce 920 the overhead of the protocol we use a default cryptographic suite. 921 As OSCORE is assumed to run after the EAP authentication, the same 922 default crypto-suite is used in this case as explained in the Key 923 Derivation Section Section 5 The cryptographic suite is not 924 negotiated. If the cryptographic suite to be used by the node is 925 different from the default, the AAA server will send the specific 926 parameters to the Authenticator. If the cryptographic suite is not 927 supported, the key derivation process would result in a security 928 association failure. 930 8.3. Freshness of the key material 932 In this design, we do not exchange nonces to provide freshness to the 933 keys derived from the MSK. This is done under the assumption that 934 the MSK and EMSK keys derived following the EAP KMF [RFC5247] are 935 fresh key material by the specifications of the EAP KMF. Since only 936 one session key is derived from the MSK we do not have to concern 937 ourselves with the generation of additional key material. In case 938 another session has to be established, a re-authentication can be 939 done, by running the process again, or using a more lightweight EAP 940 method to derive additional key material such as ERP [RFC6696]. 942 8.4. Additional Security Consideration 944 Other security-related concerns can be how to ensure that the node 945 joining the security domain can in fact trust the Controller. This 946 issue is elaborated in the EAP KMF [RFC5247]. To summarizing, the 947 node knows it can trust the Controller because the key that is used 948 to establish the security association is derived from the MSK. If 949 the Controller has the MSK, it is clear the AAA Server of the node 950 trusts the Controller, which confirms it is a trusted party. 952 9. IANA Considerations 954 TBD. 956 10. Acknowledgments 958 We would like to thank as the reviewers of this work: Carsten 959 Bormann, Benjamin Kaduk, Alexandre Petrescu, Pedro Moreno-Sanchez and 960 Eduardo Ingles-Sanchez. 962 We would also like to thank Gabriel Lopez-Millan for the first review 963 of this document and we would like to thank Ivan Jimenez-Sanchez for 964 the first proof-of-concept implementation of this idea. 966 And thank for their valuables comments to Alexander Pelov and Laurent 967 Toutain, especially for the potential optimizations of CoAP-EAP. 969 11. References 971 11.1. Normative References 973 [I-D.ietf-ace-oauth-authz] 974 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 975 H. Tschofenig, "Authentication and Authorization for 976 Constrained Environments (ACE) using the OAuth 2.0 977 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36 978 (work in progress), November 2020. 980 [I-D.ietf-lwig-coap] 981 Kovatsch, M., Bergmann, O., and C. Bormann, "CoAP 982 Implementation Guidance", draft-ietf-lwig-coap-06 (work in 983 progress), July 2018. 985 [I-D.ingles-eap-edhoc] 986 Sanchez, E., Garcia-Carrillo, D., and R. Marin-Lopez, "EAP 987 method based on EDHOC Authentication", draft-ingles-eap- 988 edhoc-01 (work in progress), November 2020. 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, 992 DOI 10.17487/RFC2119, March 1997, 993 . 995 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 996 Levkowetz, Ed., "Extensible Authentication Protocol 997 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 998 . 1000 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 1001 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 1002 2006, . 1004 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 1005 Advanced Encryption Standard-Cipher-based Message 1006 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 1007 PRF-128) Algorithm for the Internet Key Exchange Protocol 1008 (IKE)", RFC 4615, DOI 10.17487/RFC4615, August 2006, 1009 . 1011 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 1012 and A. Yegin, "Protocol for Carrying Authentication for 1013 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 1014 May 2008, . 1016 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 1017 Authentication Protocol (EAP) Key Management Framework", 1018 RFC 5247, DOI 10.17487/RFC5247, August 2008, 1019 . 1021 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 1022 "Specification for the Derivation of Root Keys from an 1023 Extended Master Session Key (EMSK)", RFC 5295, 1024 DOI 10.17487/RFC5295, August 2008, 1025 . 1027 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., 1028 "EAP Extensions for the EAP Re-authentication Protocol 1029 (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012, 1030 . 1032 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 1033 Constrained-Node Networks", RFC 7228, 1034 DOI 10.17487/RFC7228, May 2014, 1035 . 1037 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 1038 Application Protocol (CoAP)", RFC 7252, 1039 DOI 10.17487/RFC7252, June 2014, 1040 . 1042 [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A 1043 RADIUS Attribute, Binding, Profiles, Name Identifier 1044 Format, and Confirmation Methods for the Security 1045 Assertion Markup Language (SAML)", RFC 7833, 1046 DOI 10.17487/RFC7833, May 2016, 1047 . 1049 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 1050 Bose, "Constrained Application Protocol (CoAP) Option for 1051 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 1052 August 2016, . 1054 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 1055 "Object Security for Constrained RESTful Environments 1056 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 1057 . 1059 11.2. Informative References 1061 [coap-eap] 1062 Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP- 1063 Based Bootstrapping Service for the Internet of Things - 1064 https://www.mdpi.com/1424-8220/16/3/358", March 2016. 1066 Authors' Addresses 1068 Rafa Marin-Lopez 1069 University of Murcia 1070 Campus de Espinardo S/N, Faculty of Computer Science 1071 Murcia 30100 1072 Spain 1074 Phone: +34 868 88 85 01 1075 Email: rafa@um.es 1077 Dan Garcia-Carrillo 1078 University of Oviedo 1079 Calle Luis Ortiz Berrocal S/N, Edificio Polivalente 1080 Gijon, Asturias 33203 1081 Spain 1083 Email: garciadan@uniovi.es