idnits 2.17.1 draft-ietf-ace-wg-coap-eap-00.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 (February 22, 2021) is 1153 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 289, but not defined == Missing Reference: '0x7654' is mentioned on line 302, but not defined == Missing Reference: '0x8694' is mentioned on line 317, but not defined == Missing Reference: '0x9869' is mentioned on line 331, but not defined == Missing Reference: '0x7811' is mentioned on line 346, 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 3 Internet-Draft University of Murcia 4 Intended status: Standards Track D. Garcia 5 Expires: August 26, 2021 University of Oviedo 6 February 22, 2021 8 EAP-based Authentication Service for CoAP 9 draft-ietf-ace-wg-coap-eap-00 11 Abstract 13 This document describes an authentication service that uses EAP 14 transported by means of CoAP messages with the following purposes: 16 o Authenticate a CoAP-enabled device that enters a new security 17 domain managed by a domain Controller. 19 o Derive key material to protect CoAP messages exchanged between 20 them, enabling the establishment of a security association between 21 them. 23 o Optionally, to generate key material for other types of Security 24 Associations. 26 Generally speaking, this document is specifying an EAP lower layer 27 based on CoAP, to bring the benefits of EAP to IoT. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 26, 2021. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. General Architecture . . . . . . . . . . . . . . . . . . . . 4 66 3. General Flow Operation . . . . . . . . . . . . . . . . . . . 4 67 3.1. EAP over CoAP flow of operation . . . . . . . . . . . . . 5 68 3.2. The SeqNum Option . . . . . . . . . . . . . . . . . . . . 8 69 4. Key Derivation for protecting CoAP messages . . . . . . . . . 9 70 4.1. Deriving the OSCORE Security Context . . . . . . . . . . 9 71 4.2. Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . . 11 72 5. Examples of Use Case Scenario . . . . . . . . . . . . . . . . 11 73 5.1. Example 1: CoAP-EAP in ACE . . . . . . . . . . . . . . . 12 74 5.2. Example 2: Multi-domain with AAA infrastructures . . . . 13 75 5.3. Example 3: Single domain with AAA infrastructure . . . . 13 76 5.4. Example 4: Single domain without AAA infrastructure . . . 13 77 5.5. Other use cases . . . . . . . . . . . . . . . . . . . . . 13 78 5.5.1. CoAP-EAP for network access control . . . . . . . . . 13 79 5.5.2. CoAP-EAP for service authentication . . . . . . . . . 14 80 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 6.1. CoAP as EAP lower-layer . . . . . . . . . . . . . . . . . 14 82 6.2. Need for SeqNum Option . . . . . . . . . . . . . . . . . 15 83 6.3. Size of the EAP lower-layer vs EAP method size . . . . . 15 84 6.4. Controller as the CoAP Client . . . . . . . . . . . . . . 16 85 6.5. Possible Optimizations . . . . . . . . . . . . . . . . . 16 86 6.5.1. Empty Token . . . . . . . . . . . . . . . . . . . . . 16 87 6.5.2. Removing SeqNum Option . . . . . . . . . . . . . . . 16 88 6.5.3. Further re-authentication . . . . . . . . . . . . . . 17 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 90 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 18 91 7.2. Cryptographic suite selection . . . . . . . . . . . . . . 18 92 7.3. Freshness of the key material . . . . . . . . . . . . . . 18 93 7.4. Additional Security Consideration . . . . . . . . . . . . 18 95 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 96 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 97 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 99 10.2. Informative References . . . . . . . . . . . . . . . . . 21 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 102 1. Introduction 104 The goal of this document is to describe an authentication service 105 that uses the Extensible Authentication Protocol (EAP) [RFC3748]. 106 The authentication service is built on top of the Constrained 107 Application Protocol (CoAP) [RFC7252] and allows authenticating two 108 CoAP endpoints by using EAP without the need of additional protocols 109 to establish a security association between them. 111 In particular, the document describes how CoAP can be used as a 112 constrained, link-layer independent, EAP lower-layer [RFC3748] to 113 transport EAP between a CoAP server (EAP peer) and a CoAP client (EAP 114 authenticator) using CoAP messages. The CoAP client MAY contact with 115 a backend AAA infrastructure to complete the EAP negotiation as 116 described in the EAP specification [RFC3748]. 118 The assumption is that the EAP method transported in CoAP MUST 119 generate cryptographic material [RFC5247]. In this way, the CoAP 120 messages can be protected. The general flow of operation of CoAP-EAP 121 establishes an OSCORE security association specifically for the 122 service. In addition, using the key material derived from the 123 authentication we specify the establishment of other security 124 associations depending on the security requirements of the services: 126 o OSCORE [RFC8613] security association can be established based on 127 the cryptographic material generated from the EAP authentication. 129 o A DTLS security association can be established using the exported 130 cryptographic material after a successful EAP authentication. 131 [I-D.ohba-core-eap-based-bootstrapping] 133 This document also provides comments on how to establish a security 134 association for other types of technologies that rely on CoAP. 136 1.1. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in RFC 2119 [RFC2119]. 142 2. General Architecture 144 Figure 1 shows the architecture defined in this document. Basically, 145 a node acting as the EAP peer wants to be authenticated by using EAP. 146 At the time of writing this document, we have considered a model 147 where the EAP peer will act as CoAP server for this service and the 148 EAP authenticator will act as CoAP client and MAY interact with a 149 backend AAA infrastructure, which will place the EAP server and 150 contain the information required to authenticate the CoAP client. 151 The rationale behind this decision, as we will expand later, is that 152 EAP requests go always from the EAP authenticator to the EAP peer. 153 Accordingly, the EAP responses go from the EAP peer to the EAP 154 authenticator. Nevertheless, a model where the EAP peer acts as CoAP 155 client and the EAP authenticator as CoAP server can be also analyzed 156 in the future. 158 +------------+ +------------+ 159 | EAP peer/ | | EAP auth./ | 160 | CoAP server|+------+| CoAP client| 161 +------------+ CoAP +------------+ 163 Figure 1: CoAP EAP Architecture 165 3. General Flow Operation 167 The authentication service uses CoAP as transport layer for EAP. In 168 other words, CoAP becomes an EAP lower-layer (in EAP terminology). 169 In general, it is assumed that, since the EAP authenticator MAY 170 implement an AAA client to interact with the AAA infrastructure, this 171 endpoint will have more resources or, at least, be a not so 172 constrained device. We show the sequence flow in Figure 2 where we 173 depict the usage of a generic EAP method that we call EAP-X as 174 authentication mechanism. (NOTE: any EAP method which is able to 175 export cryptographic material is be valid. For example EAP-MD5 176 cannot be used since it does not export key material). 178 The first step to run CoAP-EAP is for the IoT device to discover the 179 Controller, and that it implements the CoAP-EAP service. To do so, 180 we rely on the discovery mechanism of CoAP. The URI of the CoAP-EAP 181 service, is set to "/b" to save bytes over the air. Alternatively, 182 the if the Controller is aware of the presence of the IoT device 183 (e.g., due to a previous authentication) this process can be avoided, 184 and the Controller can directly start the authentication process. 186 The first message that is used to trigger the authentication process 187 is sent by the IoT device, acting as CoAP client. This message uses 188 the No-Response Option [RFC7967] to avoid the response from the 189 Controller to this message. After this, the exchange continues with 190 the Controller acting as CoAP client and the IoT device acting as 191 CoAP server. This is due to the fact that the IoT could be a 192 constrained node, and following the recommendations of 193 [I-D.ietf-lwig-coap] to simplify the implementation of the IoT 194 device, having the Controller the responsibility of handling the 195 retransmissions. In the next section, we refer to the IoT device as 196 the EAP peer and the Controller as the EAP authenticator to elaborate 197 the specifics of the flow of operation. 199 3.1. EAP over CoAP flow of operation 201 If the EAP peer discovers the presence of the EAP authenticator and 202 wants to start the authentication, it can send a Non-Confirmable 203 "POST /b" request to the node (Step 0). This message, will carry an 204 option developed from the work on [RFC7967] called no response. The 205 rationale of this option is to avoid waiting for a if it is not 206 needed. So the use of this option will allow signaling the intention 207 the EAP peer to start the authentication process, as a mechanism. 208 Immediately after that, the EAP authenticator will start 209 authentication service. It is worth noting that the EAP 210 authenticator MAY decide start the authentication without waiting for 211 the trigger if it has knowledge about the presence of the peer, for 212 instance, through a previous authentication. 214 In any case, to perform the authentication service, the CoAP client 215 (EAP authenticator) sends a Confirmable "POST /b" request to the CoAP 216 Server (Step 1). This POST message contains a new option SeqNum that 217 holds a sequence number randomly chosen by the CoAP client. This 218 SeqNum is used to provide ordered and reliable delivery of messages 219 involved during the whole authentication. In general, when a CoAP 220 request with EAP message is received, the CoAP client considers a 221 valid message if only if its sequence number is the expected value. 222 The sequence number is monotonically incremented by 1 so that the 223 CoAP server can know what it is the next expected sequence number. 224 After receiving the first POST, the CoAP server assigns a resource 225 and answers with an Acknowledgment with the piggy-backed resource 226 identifier (Uri-Path) (Step 2). It is assumed that the CoAP server 227 will only have an ongoing authentication and will not process 228 simultaneous EAP authentications in parallel to save resources. In 229 these two messages, the EAP Req/Id and Rep/ID are exchanged between 230 the EAP authenticator and the EAP peer. The EAP Req/Id message is 231 forwarded by the EAP authenticator, when EAP is in pass-through mode, 232 to the local AAA server that is in charge of steering the 233 conversation, choosing the EAP method to be used (e.g. EAP-X) if the 234 user is local or sending the EAP messages to the home AAA of the EAP 235 peer. At this point, the CoAP server has created a resource for the 236 EAP authentication. The resource identifier value will be used 237 together to relate all the EAP conversation between both CoAP 238 endpoints. Since, only an ongoing EAP authentication is permitted 239 and EAP is a lock-step protocol a Token of a constant value and 1 240 byte can be used throughout the authentication process. This also 241 allows to save bytes through the link. 243 From now on, the EAP authenticator and the EAP peer will exchange EAP 244 packets related to the EAP method, transported in the CoAP message 245 payload (Steps 3,4,5,6). The EAP authenticator will use POST method 246 to send EAP requests to the EAP peer. The EAP peer will use a Piggy- 247 backed response in the Acknowledgment message to carry the EAP 248 response. At the end of the message exchanges, if everything has 249 gone well, the EAP authenticator is able to send an EAP Success 250 message and both CoAP endpoints will share a Master Session Key (MSK) 251 ([RFC5295]) 253 To establish a security association that will confirm to the EAP peer 254 that EAP authenticator received the MSK from the AAA sever, as well 255 as to the EAP authenticator that the EAP peer derived the MSK 256 correctly, both entities engage in the establishment of a security 257 association. In the context of constrained devices [RFC7228] and 258 networks we consider protocols that are designed for these cases. 259 Concretely, we show here in the diagram the establishment of the 260 OSCORE security association. This is shown in Steps 7 and 8. From 261 that point any exchange between both CoAP endpoints are protected 262 with OSCORE. Before sending the EAP success to the EAP peer, the EAP 263 authenticator is able to derive the OSCORE Security Context, to 264 confirm the establishment of the security association. The details 265 of the establishment of the OSCORE Security Context are discussed in 266 Section Section 4.1 The protection of the EAP Success is not a 267 requirement. In our case, we specify this exchange as protected by 268 the lower layer in this scenario with OSCORE. The purpose is double, 269 we can avoid forgery of this message and at the same time we are 270 using the exchange to perform the key confirmation through the 271 establishment of the OSCORE security association. Adding to the 272 previous consideration about the EAP Success, this message does not 273 preclude the operation of the device from continuing as long as there 274 is an alternate success indication that both the EAP peer and 275 authentication can rely on to continue [RFC3748]. This indication 276 can happen in two ways: 1) the reception of the a CoAP message 277 without EAP and with an OSCORE option (following the normal 278 operational communication between the both entities) is an indication 279 that the controller considers the EAP authentication finished. 2) the 280 IoT device is aware that the EAP authentication went well if an MSK 281 is available. In any case, both entities need to prove the 282 possession of the MSK as mentioned in the EAP KMF. 284 EAP peer EAP Auth. 286 (CoAP server) (CoAP client) 287 ------------- ------------- 288 | | 289 | NON [0x6af5] | 290 | POST /b | 291 | No-Response | 292 0) | Token (0xab) | 293 |---------------------------------------->| 294 | | 295 | CON [0x7654] | 296 | POST /b | 297 | SeqNum(x) | 298 | Token (0xac) | 299 | Payload EAP Req/Id | 300 1) |<----------------------------------------| 301 | | 302 | ACK [0x7654] | 303 | SeqNum(x) | 304 | Token (0xac) | 305 | 2.01 Created | 306 | Uri-Path [/b/5] | 307 | Payload EAP Rep/Id | 308 2) |---------------------------------------->| 309 | | 310 | CON [0x8694] | 311 | POST /b/5 | 312 | SeqNum(x+1) | 313 | Token (0xac) | 314 | Payload EAP-X MSG 1 | 315 3) |<----------------------------------------| 316 | | 317 | ACK [0x8694] | 318 | Token (0xac) | 319 | SeqNum(x+1) | 320 | 2.04 Changed | 321 | Payload EAP-X MSG 2 | 322 4) |---------------------------------------->| 323 .... 325 | POST /b/5 | 326 | SeqNum(x+n/2)| 327 | Token (0xac) | 328 | Payload EAP-X MSG (n-1) | 329 5) |<----------------------------------------| 330 | | 331 | ACK [0x9869] | 332 | SeqNum(x+n/2) | 333 | Token (0xac) | 334 | 2.04 Changed | 335 | Payload EAP-X MSG (n) | MSK 336 6) |---------------------------------------->| | 337 | | V 338 | CON [0x7811] |OSCORE 339 | POST /b/5 |CONTEXT 340 | SeqNum(x+n/2+1) | 341 | Token (0xac) | (*) 342 | OSCORE Option | 343 | EAP success | 344 MSK 7) |<----------------------------------------| 345 | | | 346 V (*) | ACK [0x7811] | 347 OSCORE | SeqNum(x+n/2+1) | 348 CONTEXT | Token (0xac) | 349 | OSCORE Option | 350 | 2.04 Changed | 351 8) |---------------------------------------->| 353 (*) Protected with OSCORE 355 Figure 2: CoAP-EAP flow of operation 357 3.2. The SeqNum Option 359 A new SeqNum option is defined in this document for establishing the 360 ordering guarantee of the EAP exchange. Following guidelines in 361 [RFC7252] this option is: 363 1. Format opaque (sequence of bytes). 365 2. Critical 367 3. Safe to Forward 369 4. No cacheable and Not part of the Cache-Key 371 5. Not repeatable 373 The number of the option will be determined by this previous 374 decisions. 376 1. Critical (C = 1) 378 2. Safe to Forward (1) 379 3. NoCacheKey (111) 381 The number of the SeqNum option will fit this pattern: xxx11111 383 0 1 2 3 4 5 6 7 384 +---+---+---+---+---+---+---+---+ 385 | | NoCacheKey| U | C | 386 +---+---+---+---+---+---+---+---+ 388 Figure 3: SeqNum Option Number Mask 390 The option number is TBD. 392 The resultant SeqNum option is: 394 +-----+---+---+---+---+--------+--------+--------+---------+ 395 | No. | C | U | N | R | Name | Format | Length | Default | 396 +-----+---+---+---+---+--------+--------+--------+---------+ 397 | TBD | x | | x | | SeqNum | uint | 0-16 | (none) | 398 +-----+---+---+---+---+--------+--------+--------+---------+ 400 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 401 (*) See below. 403 Figure 4: SeqNum option 405 4. Key Derivation for protecting CoAP messages 407 As a result of a successful EAP authentication, both CoAP server and 408 CoAP client share a Master Key Session (MSK). The assumption is that 409 MSK is a fresh key so any derived key from the MSK will be also 410 fresh. To complete the CoAP-EAP exchange, as part of the design, the 411 establishment of an OSCORE security association specifically for the 412 CoAP-EAP service is expected. The security level for the CoAP-EAP 413 exchanges with OSCORE is with integrity. Additionally, we considered 414 the derivation of either the OSCORE Security Context or a pre-shared 415 key that can be used for a DTLS negotiation (DTLS_PSK) for further 416 communications depending of the security requirements of the services 417 provided by the AS. The CoAP-EAP OSCORE security context could be 418 generalized to enable further OSCORE secured communications between 419 the IoT device and the AS services that require the use of OSCORE. 421 4.1. Deriving the OSCORE Security Context 423 Key material needed to derive the OSCORE Security Context, from the 424 MSK can be done as follows. In this case, rest of CoAP exchanges 425 between both entities can be protected with OSCORE. 427 The Master Secret can be derived by using AES-CMAC-PRF-128 [RFC4615], 428 which, in turn, uses AES-CMAC-128 [RFC4493]. The Master Secret can 429 be derived as follows: 431 Master_Secret = KDF(MSK, "IETF_OSCORE_MASTER_SECRET", 64, length) 433 where: 435 o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses 436 AES-CMAC-128 as building block. 438 o The MSK exported by the EAP method, which by design is a fresh key 439 material. Discussions about the use of the MSK for the key 440 derivation are done in Section Section 7. 442 o "IETF_OSCORE_MASTER_SECRET" is the ASCII code representation of 443 the non-NULL terminated string (excluding the double quotes around 444 it). 446 o 64 is the length of the MSK. 448 o length is the length of the label "IETF_OSCORE_MASTER_SECRET" (25 449 bytes). 451 The Master Salt can be derived similarly to the Master Secret. The 452 Master Salt can be derived as follows: 454 Master_Salt = KDF(MSK, "IETF_OSCORE_MASTER_SALT", 64, length) 456 where: 458 o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses 459 AES-CMAC-128 as building block. 461 o The MSK exported by the EAP method, which by design is a fresh key 462 material. Discussions about the use of the MSK for the key 463 derivation are done in Section Section 7. 465 o "IETF_OSCORE_MASTER_SALT" is the ASCII code representation of the 466 non-NULL terminated string (excluding the double quotes around 467 it). 469 o 64 is the length of the MSK. 471 o length is the length of the label "IETF_OSCORE_MASTER_SALT" (23 472 bytes). 474 The ID Context can be set to the Identity of the EAP peer. 476 4.2. Deriving DTLS_PSK 478 In the second alternative, a DTLS_PSK is derived from the MSK between 479 both CoAP endpoints. So far, DTLS_PSK will have also 16 byte length 480 and it will derived as follows: 482 DTLS_PSK = KDF(MSK, "IETF_DTLS_PSK" , 64, length). This value is 483 concatenated with the value of the Token Option value. 485 where: 487 o MSK is exported by the EAP method. 489 o "IETF_DTLS_PSK" is the ASCII code representation of the non-NULL 490 terminated string (excluding the double quotes around it). 492 o 64 is the length of the MSK. 494 o length is the length of the label "IETF_DTLS_PSK" (13 bytes). 496 5. Examples of Use Case Scenario 498 For a device to act as a trustworthy entity within a security domain, 499 certain key material is needed to be shared between the IoT device 500 and AS. In ACE, the process of Client registration and provisioning 501 of credentials to the client is not specified. The process of Client 502 registration and provisioning can be achieved by using CoAP-EAP. 503 Once the process of authentication with EAP is completed, fresh key 504 material is shared between the IoT device and the AS. 506 Next, we elaborate examples of different use case scenarios about the 507 usage of CoAP-EAP. Generally, we are dealing with 4 entities: 509 o 2 nodes (A and B), which are constrained devices. They are the 510 EAP peers. 512 o 1 controller (C). The controller manages a domain where nodes can 513 be deployed. It can be considered a more powerful machine than 514 the nodes. In this scenario, the Controller (and EAP 515 Authenticator), can be co-located with the AS. 517 o 1 AAA server (AAA) - Optional. The AAA is an Authentication, 518 Authorization and Accounting Server, which is not constrained. 520 Generally, any node wanting to join the domain managed by the 521 controller, MUST perform a CoAP-EAP authentication with the 522 controller C. This authentication MAY involve an external AAA 523 server. This means that A and B, once deployed, will perform this 524 CoAP-EAP once as a bootstrapping phase to establish a security 525 association with the controller C. Moreover, any other entity, which 526 wants to join and establish communications with nodes under the 527 controller C's domain must also do the same. By using EAP, we can 528 have the flexibility of having different types of credentials. For 529 instance, if we have a device that is not battery dependent, and not 530 very constrained a we could be using a heavier authentication method. 531 With very constrained devices we might need to go to other 532 authentication methods (e.g., EAP-PSK, EAP-EDHOC, etc.) being able to 533 adapt to different types of devices according to policies or devices 534 capabilities. 536 5.1. Example 1: CoAP-EAP in ACE 538 Next, we exemplify how CoAP-EAP can be used to perform the Client 539 registration in a general way, to allow two IoT devices (A and B) to 540 communicate and interact after a successful client registration. 542 Node A wants to communicate with node B (e.g. to active a light 543 switch). The overall process is divided in three phases. Let's 544 start with node A. In the first phase, the node A (EAP peer) does 545 not yet belong to the controller C's domain. Then, it communicates 546 with controller C (EAP authenticator) and authenticates with CoAP- 547 EAP, which, optionally, communicates with the AAA server to complete 548 the authentication process. If the authentication is successful, key 549 material is distributed to the controller C and derived by node A. 550 This key material allows node A to establish a security association 551 with the controller (C). Some authorization information may be also 552 provided in this step. If authentication and authorization are 553 correct, node A is enrolled in the controller C's domain during a 554 period of time. In particular, [RFC5247] recommends 8 hours, though 555 the AAA server can establish this lifetime. In the same manner, B 556 needs to perform the same process with CoAP-EAP to be part of the 557 controller C's domain. 559 In the second phase, when node A wants to talk with node B, it 560 contacts the controller C for authorization to access node B and 561 obtain all the required information to do that in a secure manner 562 (e.g. keys, tokens, authorization information, etc.). This phase 563 does NOT require the usage of CoAP-EAP. The details of this phase 564 are out of scope of this document, and the ACE framework is used for 565 this purpose [I-D.ietf-ace-oauth-authz]. 567 In the third phase, the node A can access node B with the credentials 568 and information obtained from the controller C in the second phase. 569 This access can be repeated without contacting the controller, while 570 the credentials given to A are still valid. The details of this 571 phase are out of scope of this document. 573 It is worth noting that first phase with CoAP-EAP is ONLY required to 574 join the controller C's domain. Once it is performed with success, 575 the communications are local to the controller C's domain so there is 576 no need to contact the external AAA server nor performing EAP 577 authentication. 579 5.2. Example 2: Multi-domain with AAA infrastructures 581 We assume we have a device (A) of the domain acme.org, which uses a 582 specific kind of credential (e.g., AKA) and intends to join the um.es 583 domain. This user does not belong to this domain, for which first it 584 performs a client registration using CoAP-EAP. For this it interacts 585 with the domain Controller acting as EAP authenticator, which in turn 586 communicates with a AAA infrastructure (acting as AAA client). 587 Through the local AAA server to communicate with the home AAA server 588 to complete the authentication and integrate the device as a 589 trustworthy entity into the domain of the controller C. In this 590 scenario the AS under the role of the Controller, receives the key 591 material from the AAA infrastructure 593 5.3. Example 3: Single domain with AAA infrastructure 595 A University Campus, we have several Faculty buildings and each one 596 has its own criteria or policies in place to manage IoT devices under 597 an AS. All buildings belong to the same domain (e.g., um.es). All 598 these buildings are managed with a AAA infrastructure. A new device 599 (A) with credentials from the domain (e.g., um.es) will be able to 600 perform the device registration with a Controller (C) of any building 601 as long as they are managed by the same general domain. 603 5.4. Example 4: Single domain without AAA infrastructure 605 Another case, without a AAA infrastructure, we have a Controller that 606 has co-located the AAA server and using EAP standalone mode we are 607 able to manage all the devices within the same domain locally. 608 Client registration of a node (A) with Controller (C) can also be 609 performed in the same manner, transparent to the IoT device. In this 610 scenario the AAA server is co-located within the Controller (C)- 612 5.5. Other use cases 614 5.5.1. CoAP-EAP for network access control 616 One of the first steps for an IoT device life-cycle is to perform the 617 authentication to gain access to the network. To do so, the device 618 first has to be authenticated and granted authorization to gain 619 access to the network. Additionally, security parameters such as 620 credentials can be derived from the authentication process allowing 621 the trustworthy operation of the IoT device in a particular network 622 by joining the security domain. By using EAP, we are able to achieve 623 this with flexibility and scalability, because of the different EAP 624 methods available and the ability relying in AAA infrastructures if 625 needed to support multi-domain scenarios, which is a key feature when 626 the IoT devices deployed under the same security domain, belong to 627 different organizations. Given that EAP is also used for network 628 access control, it is possible that this service can be used to 629 provide network access control service (e.g., LoRa network). In this 630 specific case, we could leverage the compression by SCHC for CoAP. 632 5.5.2. CoAP-EAP for service authentication 634 It is not uncommon that the infrastructure where the device is 635 deployed and the services the IoT device are managed by different 636 organizations. Therefore, in addition to the authentication for 637 network access control, we have to consider the possibility of a 638 secondary authentication to access different services. This process 639 of authentication, for example, will provide with the necessary key 640 material to establish a secure channel and interact with the entity 641 in charge of granting access to different services. 643 6. Discussion 645 6.1. CoAP as EAP lower-layer 647 In this section we discuss the suitability of the CoAP protocol as 648 EAP lower layer, and review the requisites imposed by the EAP 649 protocol to any protocol that transports EAP. The assumptions EAP 650 makes about its lower layers can be found in section 3.1 of 651 [RFC3748], which are enumerated next: 653 o Unreliable transport. EAP does not assume that lower layers are 654 reliable. 656 o Lower layer error detection. EAP relies on lower layer error 657 detection (e.g., CRC, Checksum, MIC, etc.) 659 o Lower layer security. EAP does not require security services from 660 the lower layers. 662 o Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 663 octets or greater. 665 o Possible duplication. EAP stipulates that, while desirable, it 666 does not require for the lower layers to provide non-duplication. 668 o Ordering guarantees. EAP relies on lower layer ordering 669 guarantees for correct operation. 671 Regarding the unreliable transport, although EAP assumes a non 672 reliable transport, CoAP does provide a reliability mechanism through 673 the use of Confirmable messages. For the error detection, CoAP goes 674 on top of UDP which provides a checksum mechanism over its payload. 675 Lower layer security services are not required. About the minimum 676 MTU of 1020 octets, CoAP assumes an upper bound of 1024 for its 677 payload which covers the requirements of EAP. Regarding message 678 ordering, we propose the use of a new CoAP option, the SeqNum option 679 described in Section (Section 3.2), which will allow us to determine 680 the order in which the different messages are exchanged. Regarding 681 the Token, we consider the use of a constant value using a small 1 682 byte Token. In fact, the EAP server will not send a new EAP request 683 until it has processed the expected EAP response. Additionally, we 684 are under the assumption that there will a single EAP authentication 685 between the constrained device and the same Controller. 687 As we can see, CoAP can fulfil the requirements of EAP to be 688 considered suitable as lower-layer. 690 6.2. Need for SeqNum Option 692 We consider the use of the SeqNum Option due to the independence of 693 how the CoAP engine is implemented. Since we do not know before hand 694 if the implementation will allow us to pre-establish the MSG-ID or 695 the Token from the application perspective, we need to be sure we are 696 able to provide order delivery. If the implementation of CoAP allows 697 us to pre-establish the MSD-ID and Token, we could avoid using this 698 option, due to the characteristics of the CoAP-EAP exchange, i.e., 699 the EAP exchange is done in lock-step and only one session is 700 considered at a time. Another consideration regarding the workings 701 of the SeqOption, is that since the initial number from which is 702 monotonically increased by 1, could cause the overflow of the number. 703 To manage this scenario, the SeqNum Option performs rounding, going 704 to zero and continue from there. 706 6.3. Size of the EAP lower-layer vs EAP method size 708 Regarding the impact an EAP lower layer will have to the total byte 709 size of the whole exchange, there is a comparison with another 710 network layer based EAP lower-layer, PANA [RFC5191] in [coap-eap]. 711 Authors compared focusing EAP lower-layer (alone) and taking into 712 account EAP. On the one hand, at EAP lower-layer level, the usage of 713 CoAP gives us an important benefits. On the other hand, when taking 714 into account the EAP method overload, this reduction is less but 715 still significant if the EAP method is lightweight (we used EAP-PSK 716 as a representative example of a lightweight EAP method). If the EAP 717 method is very taxing the improvement achieved in the EAP lower-layer 718 is less significant. This leads to the conclusion that possible next 719 steps in this field could be also improving or designing new EAP 720 methods that can be better adapted to the requirements of constrained 721 devices and networks. However, we cannot ignore the impact of the 722 EAP lower-layer itself and try to propose something light as we do 723 proposing CoAP. We consider that may be others EAP methods such as 724 EAP-AKA or new lightweight EAP methods such as EAP-EDHOC 725 [I-D.ingles-eap-edhoc] that can benefit from a CoAP-based EAP lower- 726 layer, as well as new ones that may be proposed in the future with 727 IoT constraints in mind. 729 6.4. Controller as the CoAP Client 731 Due to the constrained capacities of the devices, to relieve them of 732 the retransmission tasks, we set the Controller as the CoAP client, 733 for the main exchange following the recommendations of the 734 [I-D.ietf-lwig-coap] document to simplify the constrained device 735 implementation. 737 6.5. Possible Optimizations 739 6.5.1. Empty Token 741 Assuming that the bootstrapping service runs before any other 742 service, and that no other service will run concurrently until it has 743 finished, we could use an Empty Token value to save resources, since 744 there will be no other endpoint or CoAP exchange. 746 6.5.2. Removing SeqNum Option 748 An alternative to consider would be to try to rely on the Message ID 749 values as a way of achieving the order delivery throughout the 750 authentication exchange. Here we have two approximations: 1) 751 Removing the option from the ACKs and 2) removing the option 752 completely. 754 1. Since the ACKs are piggybacked by design, there is only 1 ongoing 755 authentication process and the EAP exchange is done in a lockstep 756 fashion, when we get a response we will get the same Message ID 757 of the request and we can confirm the SeqNum of the Request. 759 2. An alternative to consider would be to try to solely rely on the 760 Message ID values as a way of achieving the order delivery 761 throughout the authentication exchange. Here we also have two 762 approaches: A) To expect randomly generated Message IDs and B) 763 set the Message ID to increase monotonically by 1. 765 A. Regarding the use of the Message ID, their values in the 766 requests sent by the Controller are generated randomly, as 767 suggested by CoAP. The Controller selects a new Message ID 768 value each time a new request is sent to the CoAP server, 769 until the bootstrapping service finishes. Moreover, the 770 Controller stores the last Message ID sent until correctly 771 receiving the corresponding ACK. The CoAP server keeps track 772 of the last received Message ID to identify retransmissions, 773 and the previous Message IDs during the current bootstrapping 774 to identify old messages. In general, a request is 775 considered valid in terms of the Message ID if either this 776 value matches the last value received, which means a 777 retransmission of the last response is required, or the 778 arrival of a new Message ID, which therefore represents a new 779 message. If these rules do not apply (i.e., an old Message 780 ID has been received), the CoAP server silently discards the 781 request. This is possible because the bootstrapping service 782 is designed as lockstep, i.e. the Controller will not send a 783 new request until it has received the expected response. 784 When the bootstrapping exchange finishes successfully, the 785 CoAP server can free the tracked Message IDs, except for the 786 last received Message ID at the end of the bootstrapping, 787 just in case a retransmission is required. 789 B. This case would avoid having to keep track of the already 790 used Message IDs, monotonically increasing by 1 the message 791 ID value once the first is randomly picked by the Controller. 793 6.5.3. Further re-authentication 795 Since the initial bootstrapping is usually taxing, it is assumed to 796 be done only once over a long period of time. If further re- 797 authentications for refreshing the key material are necessary, there 798 are other methods that can be used to perform these re- 799 authentications. For example, the EAP re-authentication (EAP-ERP) 800 [RFC6696] can be used to avoid repeating the entire EAP exchange in 801 few exchanges. 803 7. Security Considerations 805 There are some aspects to be considered such as how authorization is 806 managed, how the cryptographic suite is selected and how the trust in 807 the Controller is established. 809 7.1. Authorization 811 Authorization is part of the bootstrapping. It serves to establish 812 whether the node can join and the set of conditions it has to adhere. 813 The authorization data received from the AAA server can be delivered 814 by the AAA protocol (e.g. Diameter). Providing more fine grained 815 authorization data can be with the transport of SAML in RADIUS 816 [RFC7833]. After bootstrapping, additional authorization to operate 817 in the security domain, e.g., access services offered by other nodes, 818 can be taken care of by the solutions proposed in the ACE WG. 820 7.2. Cryptographic suite selection 822 How the cryptographic suit is selected is also important. To reduce 823 the overhead of the protocol we use a default cryptographic suite. 824 As OSCORE is assumed to run after the EAP authentication, the same 825 default crypto-suite is used in this case as explained in the Key 826 Derivation Section Section 4 The cryptographic suite is not 827 negotiated. If the cryptographic suite to be used by the node is 828 different from default, the AAA server will send the specific 829 parameters to the Authenticator. If the cryptographic suite is not 830 supported, the key derivation process would result in a security 831 association failure. 833 7.3. Freshness of the key material 835 In this design, we do not exchange nonces to provide freshness to the 836 keys derived from the MSK. This is done under the assumption that 837 the MSK and EMSK keys derived following the EAP KMF [RFC5247] are 838 fresh key material by the specifications of the EAP KMF. Since only 839 one session key is derived from the MSK we do not have to concern 840 ourselves with the generation of additional key material. In case 841 another session has to be established, a re-authentication can be 842 done, by running process again, or using a more lightweight EAP 843 method to derive additional key material such as EAP-ERP. 845 7.4. Additional Security Consideration 847 Other security related concerns can be how to ensure that the node 848 joining the security domain can in fact trust the Controller. This 849 issue is elaborated in the EAP KMF [RFC5247]. Summarizing, the node 850 knows it can trust the Controller, because the key that is used to 851 establish the security association is derived from the MSK. If the 852 Controller has the MSK, it is clear the AAA Server of the node trusts 853 the Controller, which confirms it is a trusted party. 855 8. IANA Considerations 857 This document has no actions for IANA. 859 9. Acknowledgments 861 We would like to thank Pedro Moreno-Sanchez and Gabriel Lopez-Millan 862 for the first review of this document. Also, we would like to thank 863 Ivan Jimenez-Sanchez for the first proof-of-concept implementation of 864 this idea. 866 We also thank for their valuables comments to Alexander Pelov and 867 Laurent Toutain, specially for the potential optimizations of CoAP- 868 EAP. 870 As well as the reviewers of this work, Alexandre Petrescu, Pedro 871 Moreno-Sanchez, Eduardo Ingles-Sanchez and Benjamin Kaduk. 873 10. References 875 10.1. Normative References 877 [I-D.ietf-ace-oauth-authz] 878 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 879 H. Tschofenig, "Authentication and Authorization for 880 Constrained Environments (ACE) using the OAuth 2.0 881 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36 882 (work in progress), November 2020. 884 [I-D.ietf-lwig-coap] 885 Kovatsch, M., Bergmann, O., and C. Bormann, "CoAP 886 Implementation Guidance", draft-ietf-lwig-coap-06 (work in 887 progress), July 2018. 889 [I-D.ingles-eap-edhoc] 890 Sanchez, E., Garcia-Carrillo, D., and R. Marin-Lopez, "EAP 891 method based on EDHOC Authentication", draft-ingles-eap- 892 edhoc-01 (work in progress), November 2020. 894 [I-D.ohba-core-eap-based-bootstrapping] 895 Das, S. and Y. Ohba, "Provisioning Credentials for CoAP 896 Applications using EAP", draft-ohba-core-eap-based- 897 bootstrapping-01 (work in progress), March 2012. 899 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 900 Requirement Levels", BCP 14, RFC 2119, 901 DOI 10.17487/RFC2119, March 1997, 902 . 904 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 905 Levkowetz, Ed., "Extensible Authentication Protocol 906 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 907 . 909 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 910 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 911 2006, . 913 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 914 Advanced Encryption Standard-Cipher-based Message 915 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 916 PRF-128) Algorithm for the Internet Key Exchange Protocol 917 (IKE)", RFC 4615, DOI 10.17487/RFC4615, August 2006, 918 . 920 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 921 and A. Yegin, "Protocol for Carrying Authentication for 922 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 923 May 2008, . 925 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 926 Authentication Protocol (EAP) Key Management Framework", 927 RFC 5247, DOI 10.17487/RFC5247, August 2008, 928 . 930 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 931 "Specification for the Derivation of Root Keys from an 932 Extended Master Session Key (EMSK)", RFC 5295, 933 DOI 10.17487/RFC5295, August 2008, 934 . 936 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., 937 "EAP Extensions for the EAP Re-authentication Protocol 938 (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012, 939 . 941 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 942 Constrained-Node Networks", RFC 7228, 943 DOI 10.17487/RFC7228, May 2014, 944 . 946 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 947 Application Protocol (CoAP)", RFC 7252, 948 DOI 10.17487/RFC7252, June 2014, 949 . 951 [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A 952 RADIUS Attribute, Binding, Profiles, Name Identifier 953 Format, and Confirmation Methods for the Security 954 Assertion Markup Language (SAML)", RFC 7833, 955 DOI 10.17487/RFC7833, May 2016, 956 . 958 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 959 Bose, "Constrained Application Protocol (CoAP) Option for 960 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 961 August 2016, . 963 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 964 "Object Security for Constrained RESTful Environments 965 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 966 . 968 10.2. Informative References 970 [coap-eap] 971 Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP- 972 Based Bootstrapping Service for the Internet of Things - 973 https://www.mdpi.com/1424-8220/16/3/358", March 2016. 975 Authors' Addresses 977 Rafa Marin-Lopez 978 University of Murcia 979 Campus de Espinardo S/N, Faculty of Computer Science 980 Murcia 30100 981 Spain 983 Phone: +34 868 88 85 01 984 Email: rafa@um.es 986 Dan Garcia-Carrillo 987 University of Oviedo 988 Calle Luis Ortiz Berrocal S/N, Edificio Polivalente 989 Gijon, Asturias 33203 990 Spain 992 Email: garciadan@uniovi.es