idnits 2.17.1 draft-marin-ace-wg-coap-eap-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- 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 (January 21, 2021) is 1185 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 842, but not defined == Missing Reference: '0x7654' is mentioned on line 855, but not defined == Missing Reference: '0x8694' is mentioned on line 870, but not defined == Missing Reference: '0x9869' is mentioned on line 886, but not defined == Missing Reference: '0x7811' is mentioned on line 905, but not defined == Unused Reference: 'I-D.kumar-dice-dtls-relay' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'I-D.pelov-core-cosol' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC4279' is defined on line 730, but no explicit reference was found in the text == Unused Reference: 'RFC4493' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'RFC4615' is defined on line 739, but no explicit reference was found in the text == Unused Reference: 'RFC4764' is defined on line 746, but no explicit reference was found in the text == Unused Reference: 'RFC5191' is defined on line 751, but no explicit reference was found in the text == Unused Reference: 'RFC6345' is defined on line 772, but no explicit reference was found in the text == Unused Reference: 'Contiki' is defined on line 816, but no explicit reference was found in the text == 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 draft: draft-pelov-core-cosol (ref. 'I-D.pelov-core-cosol') ** Downref: Normative reference to an Informational RFC: RFC 4493 ** Downref: Normative reference to an Experimental RFC: RFC 4764 ** Downref: Normative reference to an Informational RFC: RFC 5869 ** Downref: Normative reference to an Informational RFC: RFC 7228 ** Downref: Normative reference to an Informational RFC: RFC 7967 Summary: 7 errors (**), 0 flaws (~~), 17 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: July 25, 2021 University of Oviedo 6 January 21, 2021 8 EAP-based Authentication Service for CoAP 9 draft-marin-ace-wg-coap-eap-07 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 against a AAA infrastructure through a domain Controller. 19 o Bootstrap key material to protect CoAP messages exchanged between 20 them. 22 o Enable the establishment of Security Associations between them. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 25, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. General Architecture . . . . . . . . . . . . . . . . . . . . 3 61 3. General Flow Operation . . . . . . . . . . . . . . . . . . . 4 62 3.1. EAP over CoAP: Running an OSCORE Security Association . . 4 63 3.2. The SeqNum Option . . . . . . . . . . . . . . . . . . . . 7 64 4. Key Derivation for protecting CoAP messages . . . . . . . . . 8 65 4.1. Deriving the OSCORE Security Context . . . . . . . . . . 8 66 5. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 10 67 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 6.1. CoAP as EAP lower-layer . . . . . . . . . . . . . . . . . 11 69 6.2. Size of the EAP lower-layer vs EAP method size . . . . . 12 70 6.3. Controller as the CoAP Client . . . . . . . . . . . . . . 12 71 6.4. Possible Optimizations . . . . . . . . . . . . . . . . . 12 72 6.4.1. Empty Token . . . . . . . . . . . . . . . . . . . . . 13 73 6.4.2. Removing SeqNum Option . . . . . . . . . . . . . . . 13 74 6.4.3. Further re-authentication . . . . . . . . . . . . . . 14 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 76 7.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 14 77 7.2. Cryptographic suite selection . . . . . . . . . . . . . . 14 78 7.3. Freshness of the key material . . . . . . . . . . . . . . 15 79 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 81 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 83 10.2. Informative References . . . . . . . . . . . . . . . . . 18 84 Appendix A. CoAP-EAP with DTLS . . . . . . . . . . . . . . . . . 18 85 A.1. Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . . 20 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 The goal of this document is to describe an authentication service 91 that uses the Extensible Authentication Protocol (EAP) [RFC3748]. 92 The authentication service is built on top of the Constrained 93 Application Protocol (CoAP) [RFC7252] and allows authenticating two 94 CoAP endpoints by using EAP without the need of additional protocols 95 to bootstrap a security association between them. 97 In particular, the document describes how CoAP can be used as a 98 constrained link-layer independent EAP lower-layer [RFC3748] to 99 transport EAP between a CoAP server (EAP peer) and the CoAP client 100 (EAP authenticator) using CoAP messages. The CoAP client MAY contact 101 with a backend AAA infrastructure to complete the EAP negotiation as 102 described in the EAP specification [RFC3748]. 104 The assumption is that the EAP method transported in CoAP MUST 105 generate cryptographic material [RFC5247] . In this way, the CoAP 106 messages can be protected. There are two approaches that we have 107 considered in this document: 109 o To define how the OSCORE security association can be established 110 based on the cryptographic material generated from the EAP 111 authentication. 113 o To establish a DTLS security association using the exported 114 cryptographic material after a successful EAP authentication. 115 [I-D.ohba-core-eap-based-bootstrapping] 117 This document also provides some comments about implementation of a 118 proof-of-concept of this preliminary idea 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 2. General Architecture 128 The Figure 1 shows the architecture defined in this document. 129 Basically a node acting as the EAP peer wants to be authenticated by 130 using EAP. At the time of writing this document, we have considered 131 a model where the EAP peer will act as CoAP server for this service 132 and the EAP authenticator will act as CoAP client and MAY interact 133 with a backend AAA infrastructure, which will place the EAP server 134 and contain the information required to authenticate the CoAP client. 135 The rationale behind this decision, as we will expand later, is that 136 EAP requests go always from the EAP authenticator and the EAP peer 137 and the EAP responses from the EAP peer to the EAP authenticator. 138 Nevertheless, a model where the EAP peer act as CoAP client and the 139 EAP authenticator as CoAP server can be also analyzed in the future. 141 +------------+ +------------+ +--------------+ 142 | EAP peer/ | | EAP auth./ | | EAP server/ | 143 | CoAP server|+------+| CoAP client|+-----+| AAA server | 144 +------------+ CoAP +------------+ AAA +--------------+ 146 Figure 1: CoAP EAP Architecture 148 3. General Flow Operation 150 The authentication service uses CoAP as transport layer for EAP. In 151 other words, CoAP becomes an EAP lower-layer (in EAP terminology). 152 In general, it is assumed that, since the EAP authenticator may 153 implement an AAA client to interact with the AAA infrastructure, this 154 endpoint will have more resources or, at least, it is not a so 155 constrained device. We describe two different sequence flow. First, 156 it is shown in Figure 2 where the OSCORE is used at the end of EAP 157 authentication. The diagram in Figure 5 shows the flow when DTLS is 158 used to protect CoAP messages at the end of the EAP authentication. 159 As an example, both diagrams show the usage of a generic EAP method 160 that we call EAP-X as authentication mechanism. (NOTE: any EAP 161 method which is able to export cryptographic material should be 162 valid). 164 3.1. EAP over CoAP: Running an OSCORE Security Association 166 When the EAP peer discovers the presence of the EAP authenticator and 167 wants to start the authentication, it can send a Non-Confirmable 168 "POST /b" request to the node (Step 0). This message, will carry an 169 option developed from the work on [RFC7967] called no response. The 170 rationale of this option is to avoid waiting for a response if it is 171 not needed. So the use of this option will allow signaling the 172 intention of the EAP peer to start the authentication process, as a 173 trigger mechanism. Immediately after that, the EAP authenticator 174 will start the authentication service. It is worth noting that the 175 EAP authenticator MAY decide to start the authentication without 176 waiting for the trigger message if it has knowledge about the 177 presence of the EAP peer, for instance, through a previous 178 authentication (re-authentication). 180 In any case, to perform the authentication service, the CoAP client 181 (EAP authenticator) sends a Confirmable "POST /b" request to the CoAP 182 Server (Step 1). This POST message contains a new option SeqNum that 183 holds a sequence number randomly chosen by the CoAP client. This 184 SeqNum is used to provide ordered and reliable delivery of messages 185 involved during the whole authentication. In general, when a CoAP 186 request with EAP message is received, the CoAP client considers a 187 valid message if only if its sequence number is the expected value. 189 The sequence number is monotonically incremented by 1 so that the 190 CoAP server can know what it is the next expected sequence number. 192 After receiving the first POST, the CoAP server assigns a resource 193 and answers with an Acknowledgment with the piggy-backed resource 194 identifier (Uri-Path) (Step 2). It is assumed that the CoAP server 195 will only have an ongoing authentication and will not process 196 simultaneous EAP authentications in parallel to save resources. In 197 these two messages, the EAP Req/Id and Rep/ID are exchanged between 198 the EAP authenticator and the EAP peer. The EAP Req/Id message is 199 forwarded by the EAP authenticator, when EAP is in pass-through mode, 200 to the local AAA server that is in charge of steering the 201 conversation, choosing the EAP method to be used (e.g. EAP-X) if the 202 user is local or sending the EAP messages to the home AAA of the EAP 203 peer. At this point, the CoAP server has created a resource for the 204 EAP authentication. The resource identifier value will be used 205 together to relate all the EAP conversation between both CoAP 206 endpoints. Since, only an ongoing EAP authentication is permitted 207 and EAP is a lock-step protocol a Token of a constant value and 1 208 byte can be used throughout the authentication process. This also 209 allows to save bytes through the link. 211 From now on, the EAP authenticator and the EAP peer will exchange EAP 212 packets related to the EAP method, transported in the CoAP message 213 payload (Steps 3,4,5,6). The EAP authenticator will use the POST 214 method to send EAP requests to the EAP peer. The EAP peer will use a 215 Piggy-backed response in the Acknowledgment message to carry the EAP 216 response. At the end of the message exchanges, if everything has 217 gone well, the EAP authenticator is able to send an EAP Success 218 message and both CoAP endpoints will share a Master Session Key (MSK) 219 ([RFC5295]) 221 To establish a security association that will confirm to the EAP peer 222 that EAP authenticator received the MSK from the AAA sever, as well 223 as to the EAP authenticator that the EAP peer derived the MSK 224 correctly, both entities engage in the establishment of a security 225 association. In the context of constrained devices [RFC7228] and 226 networks we consider protocols that are designed for these cases. 227 Concretely, we show here in the diagram the establishment of the 228 OSCORE security association. This is shown in Steps 7 and 8. From 229 that point any exchange between both CoAP endpoints are protected 230 with OSCORE. Before sending the EAP success to the EAP peer, the EAP 231 authenticator is able to derive the OSCORE Security Context, to 232 confirm the establishment of the security association. The details 233 of the establishment of the OSCORE Security Context are discussed in 234 Section 4.1 235 On the contrary, if DTLS is used (see Figure 5), a DTLS_PSK is 236 derived from the MSK. Moreover, exchanges between both CoAP 237 endpoints are protected with DTLS from that point. 239 EAP peer EAP Auth. 240 (CoAP server) (CoAP client) 241 ------------- ------------- 242 | | 243 | NON [0x6af5] | 244 | POST /b | 245 | No-Response | 246 0) | Token (0xab) | 247 |---------------------------------------->| 248 | | 249 | CON [0x7654] | 250 | POST /b | 251 | SeqNum(x) | 252 | Token (0xac) | 253 | Payload EAP Req/Id | 254 1) |<----------------------------------------| 255 | | 256 | ACK [0x7654] | 257 | SeqNum(x) | 258 | Token (0xac) | 259 | 2.01 Created | 260 | Uri-Path [/b/5] | 261 | Payload EAP Rep/Id | 262 2) |---------------------------------------->| 263 | | 264 | CON [0x8694] | 265 | POST /b/5 | 266 | SeqNum(x+1) | 267 | Token (0xac) | 268 | Payload EAP-X MSG 1 | 269 3) |<----------------------------------------| 270 | | 271 | ACK [0x8694] | 272 | Token (0xac) | 273 | SeqNum(x+1) | 274 | 2.04 Changed | 275 | Payload EAP-X MSG 2 | 276 4) |---------------------------------------->| 277 .... 279 | | 280 | CON [0x9869] | 281 | POST /b/5 | 282 | SeqNum(x+n/2)| 283 | Token (0xac) | 284 | Payload EAP-X MSG (n-1) | 285 5) |<----------------------------------------| 286 | | 287 | ACK [0x9869] | 288 | SeqNum(x+n/2) | 289 | Token (0xac) | 290 | 2.04 Changed | 291 | Payload EAP-X MSG (n) | MSK 292 6) |---------------------------------------->| | 293 | | V 294 | CON [0x7811] | OSCORE 295 | POST /b/5 | CONTEXT 296 | SeqNum(x+n/2+1) | 297 | Token (0xac) | (*) 298 | OSCORE Option | 299 | EAP success | 300 MSK 7) |<----------------------------------------| 301 | | | 302 V (*) | ACK [0x7811] | 303 OSCORE | SeqNum(x+n/2+1) | 304 CONTEXT | Token (0xac) | 305 | OSCORE Option | 306 | 2.04 Changed | 307 8) |---------------------------------------->| 309 (*) Protected with OSCORE 311 Figure 2: CoAP-EAP with OSCORE option 313 3.2. The SeqNum Option 315 A new SeqNum option is defined in this document for establishing the 316 ordering guarantee of the EAP exchange. Following guidelines in 317 [RFC7252] this option is: 319 1. Format opaque (sequence of bytes). 321 2. Critical 323 3. Safe to Forward 325 4. No cacheable and Not part of the Cache-Key 327 5. Not repeatable 328 The number of the option will be determined by this previous 329 decisions. 331 1. Critical (C = 1) 333 2. Safe to Forward (1) 335 3. NoCacheKey (111) 337 The number of the SeqNum option will fit this pattern: xxx11111 339 0 1 2 3 4 5 6 7 340 +---+---+---+---+---+---+---+---+ 341 | | NoCacheKey| U | C | 342 +---+---+---+---+---+---+---+---+ 344 Figure 3: Auth Option Number Mask 346 The option number is TBD. 348 The resultant SeqNum option is: 350 +-----+---+---+---+---+--------+--------+--------+---------+ 351 | No. | C | U | N | R | Name | Format | Length | Default | 352 +-----+---+---+---+---+--------+--------+--------+---------+ 353 | TBD | x | | x | | SeqNum | uint | 0-16 | (none) | 354 +-----+---+---+---+---+--------+--------+--------+---------+ 356 C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable 358 Figure 4: SeqNum option 360 4. Key Derivation for protecting CoAP messages 362 As a result of a successful EAP authentication, both CoAP server and 363 CoAP client share a Master Key Session (MSK). The assumption is that 364 MSK is a fresh key so any derived key from the MSK will be also 365 fresh. We have considered the derivation of either the OSCORE 366 Security Context or pre-shared key that can be used for a DTLS 367 negotiation (DTLS_PSK) (in the Appendix) 369 4.1. Deriving the OSCORE Security Context 371 Key material needed to derive the OSCORE Security Context, from the 372 MSK can be done as follows. First, HKDF SHA-256 [RFC5869] is 373 mandatory to implement. We assume the use of the default algorithms 374 HKDF SHA-256 and AES-CCM-16-64-128. The extract phase of HKDF 375 produces a pseudo-random key ( that we refer to here as RK) that is 376 used to generate the OSCORE Security Context in the Expand phase. 377 The derivation is done as follows: 379 RK = HMAC-SHA-256(MSK) 381 Where: 383 o MSK is the Master Session Key derived from the EAP method. 385 o RK is the Random Key that is generated from the MSK in the Extract 386 phase. 388 Discussions about the use of the MSK for the key derivation are done 389 in Section Section 7. 391 Based on the RK generated from the MSK, we can now generate the 392 Master Secret and Master Salt. The key derivation is performed as 393 follows: 395 Master_Secret = HKDF(RK, "IETF_OSCORE_MASTER_SECRET", length) 397 where: 399 o The RK is exported in the Extract Phase, previously commented. 401 o "IETF_OSCORE_MASTER_SECRET" is the ASCII code representation of 402 the non-NULL terminated string (excluding the double quotes around 403 it). 405 o length is the length of the Master_Secret. We set the length to 406 32 bytes 408 The Master Salt can be derived as follows: 410 Master_Salt = HKDF(PK, "IETF_OSCORE_MASTER_SALT", length) 412 where: 414 o The RK is exported in the Extract Phase, previously commented. 416 o "IETF_OSCORE_MASTER_SALT" is the ASCII code representation of the 417 non-NULL terminated string (excluding the double quotes around 418 it). 420 o length is the length of the Master Salt. We set the length to 8 421 bytes. 423 The ID Context can be set to the Identity of the EAP peer. 425 5. Use Case Scenario 427 In the following, we explain a basic example about the usage of CoAP- 428 EAP. There are 5 entities involved in the scenario: 430 o 2 nodes (A and B), which are constrained devices. 432 o 1 node D, which is considered a no so constrained device, such a 433 phone, or a tablet or even a laptop. 435 o 1 controller (C). The controller manages a domain where nodes can 436 be deployed. It can be considered a more powerful machine than 437 the nodes. 439 o 1 AAA server (AAA). The AAA is an Authentication, Authorization 440 and Accounting Server, which is not constrained. 442 Any node wanting to join the domain managed by the controller, MUST 443 perform an CoAP-EAP authentication with the controller C. This 444 authentication may involve an external AAA server. This means that A 445 and B, once deployed, will perform this CoAP-EAP once as a 446 bootstrapping phase to establish a security association with the 447 controller C. Moreover, any other entity (i.e. node D) , which wants 448 to join and establish communications with nodes under the controller 449 C's domain must also do the same. 451 Let us assume that the node A wants to communicate with node B (e.g. 452 to active a light switch). The overall process is divided in three 453 phases. Let's start with node A. In the first phase, the node A 454 (EAP peer) does not yet belong to the controller C's domain. Then, 455 it communicates with controller C (EAP authenticator) and 456 authenticates with CoAP-EAP, which, in turn, communicates with the 457 AAA server to complete the authentication process. If the 458 authentication is successful, key material is distributed to the 459 controller C and derived by node A. This key material allows node A 460 to establish a security association with controller C. Some 461 authorization information coming from the AAA infrastructure may be 462 also provided in this step. If authentication and authorization are 463 correct, node A is enrolled in the controller C's domain during a 464 period of time. In particular, [RFC5247] recommends 8 hours, though 465 the AAA server can establish a different lifetime. In the same 466 manner, B needs to perform the same process with CoAP-EAP to be part 467 of the controller C's domain. 469 In the second phase, when node A wants to talk with node B, it 470 contacts the controller C for authorization to access node B and 471 obtain all the required information to do that in a secure manner 472 (e.g. keys, tokens, authorization information, etc.). It does NOT 473 require the usage of CoAP-EAP. The details of this phase are out of 474 scope of this document, but ACE framework can be used for this 475 purpose [I-D.ietf-ace-oauth-authz] 477 In the third phase, the node A can access node B with the credentials 478 and information obtained from the controller C in the second phase. 479 This access can be repeated without contacting the controller, while 480 the credentials given to A are still valid. The details of this 481 phase are out of scope of this document. 483 It is worth noting that first phase with CoAP-EAP is ONLY required to 484 join the controller C's domain. Once it is performed with success, 485 the communications are local to the controller C's domain so there is 486 no need to contact the external AAA server nor performing EAP 487 authentication. 489 6. Discussion 491 6.1. CoAP as EAP lower-layer 493 In this section we discuss the suitability of the CoAP protocol as 494 EAP lower layer, and review the requisites imposed by the EAP 495 protocol to any protocol that transports EAP. The assumptions EAP 496 makes about its lower layers can be found in section 3.1 of the rfc 497 [RFC3748], which are enumerated next: 499 o Unreliable transport. EAP does not assume that lower layers are 500 reliable. 502 o Lower layer error detection. EAP relies on lower layer error 503 detection (e.g., CRC, Checksum, MIC, etc.) 505 o Lower layer security. EAP does not require security services from 506 the lower layers. 508 o Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 509 octets or greater. 511 o Possible duplication. EAP stipulates that, while desirable, it 512 does not require for the lower layers to provide non-duplication. 514 o Ordering guarantees. EAP relies on lower layer ordering 515 guarantees for correct operation. 517 Regarding the unreliable transport, although EAP assumes a non 518 reliable transport, CoAP does provide a reliability mechanism through 519 the use of Confirmable messages. For the error detection, CoAP goes 520 on top of UDP which provides a checksum mechanism over its payload. 521 Lower layer security services are not required. About the minimum 522 MTU of 1020 octets, CoAP assumes an upper bound of 1024 for its 523 payload which covers the requirements for EAP. Regarding message 524 ordering, we propose the use of a new CoAP option, the SeqNum option 525 described in Section (Section 3.2), which will allow keep the order 526 in which the different messages are exchanged. 528 Regarding the Token, we consider the use of a constant value using a 529 small 1 byte Token. In fact, the EAP server will not send a new EAP 530 request until it has processed the expected EAP response. 531 Additionally, we are under the assumption that there will a single 532 EAP authentication between the constrained device and the same 533 Controller. 535 6.2. Size of the EAP lower-layer vs EAP method size 537 Using CoAP as EAP lower layer guarantees a constrained transport for 538 EAP in constrained environments. However, it is a fair to ask about 539 the level of improvement taking into account the overload represented 540 by the EAP method. In fact, if the EAP method is very taxing in the 541 number of messages and the bytes sent over the networks the 542 improvement achieved in the EAP lower-layer may be less significant 543 ([coap-eap]). However, if the EAP method is lightweight and suitable 544 for constrained networks (e.g. EAP-PSK, as a representative example 545 of a lightweight EAP method) a constrained EAP lower-layer brings 546 more benefits. This leads to the conclusion that possible next steps 547 in this field could be also improving or designing new EAP methods 548 that can be better adapted to the requirements of constrained devices 549 and networks. Therefore, others EAP methods such as EAP-AKA or new 550 lightweight EAP methods such as EAP-EDHOC [I-D.ingles-eap-edhoc] may 551 benefit from a CoAP-based EAP lower-layer, as well as any new 552 lightweight EAP method. 554 6.3. Controller as the CoAP Client 556 Due to the constrained capacities of the devices, to relieve them of 557 the retransmission tasks, we set the Controller as the CoAP client, 558 for the main exchange following the recommendations of the 559 [I-D.ietf-lwig-coap] document to simplify the constrained device 560 implementation. 562 6.4. Possible Optimizations 563 6.4.1. Empty Token 565 Assuming that the bootstrapping service runs before any other 566 service, and that no other service will run concurrently until it has 567 finished, we could use an Emtpy Token value to save resources, since 568 there will be no other endpoint or CoAP exchange. 570 6.4.2. Removing SeqNum Option 572 An alternative to consider would be to try to rely on the Message ID 573 values as a way of achieving the order delivery throughout the 574 authentication exchange. Here we have two approximations: 1) 575 Removing the option from the ACKs and 2) removing the option 576 completely. 578 1. Since the ACKs are piggybacked by design, there is only 1 ongoing 579 authentication process and the EAP exchange is done in a lockstep 580 fashion, when we get a response we will get the same Message ID 581 of the request and we can confirm the SeqNum of the Request. 583 2. An alternative to consider would be to try to solely rely on the 584 Message ID values as a way of achieving the order delivery 585 throughout the authentication exchange. Here we also have two 586 approaches: A) To expect randomly generated Message IDs and B) 587 set the Message ID to increase monotonically by 1. 589 A. Regarding the use of the Message ID, their values in the 590 requests sent by the Controller are generated randomly, as 591 suggested by CoAP. The Controller selects a new Message ID 592 value each time a new request is sent to the CoAP server, 593 until the bootstrapping service finishes. Moreover, the 594 Controller stores the last Message ID sent until correctly 595 receiving the corresponding ACK. The CoAP server keeps track 596 of the last received Message ID to identify retransmissions, 597 and the previous Message IDs during the current bootstrapping 598 to identify old messages. In general, a request is 599 considered valid in terms of the Message ID if either this 600 value matches the last value received, which means a 601 retransmission of the last response is required, or the 602 arrival of a new Message ID, which therefore represents a new 603 message. If these rules do not apply (i.e., an old Message 604 ID has been received), the CoAP server silently discards the 605 request. This is possible because the bootstrapping service 606 is designed as lockstep, i.e. the Controller will not send a 607 new request until it has received the expected response. 608 When the bootstrapping exchange finishes successfully, the 609 CoAP server can free the tracked Message IDs, except for the 610 last received Message ID at the end of the bootstrapping, 611 just in case a retransmission is required. 613 B. This case would avoid having to keep track of the already 614 used Message IDs, monotonically increasing by 1 the message 615 ID value once the first is randomly picked by the Controller. 617 6.4.3. Further re-authentication 619 Since the initial bootstrapping is usually taxing, it is assumed to 620 be done only once over a long period of time. If further re- 621 authentications for refreshing the key material are necessary, there 622 are other methods that can be used to perform these re- 623 authentications. For example, the EAP re-authentication (EAP-ERP) 624 [RFC6696] can be used to avoid repeating the entire EAP exchange in 625 few exchanges. 627 7. Security Considerations 629 There are some aspects to be considered such as how authorization is 630 managed, how the cryptographic suite is selected and how the trust in 631 the Controller is established. 633 7.1. Authorization 635 Authorization is part of the bootstrapping. It serves to establish 636 whether the node can join and the set of conditions it has to adhere. 637 The authorization data received from the AAA server can be delivered 638 by the AAA protocol (e.g. Diameter). Providing more fine grained 639 authorization data can be with the transport of SAML in RADIUS 640 [RFC7833] After bootstrapping, additional authorization to operate in 641 the security domain, e.g., access services offered by other nodes, 642 can be taken care of by the solutions proposed in the ACE WG. 644 7.2. Cryptographic suite selection 646 How the cryptographic suit is selected is also important. To reduce 647 the overhead of the protocol we use a default cryptographic suite. 648 As OSCORE is assumed to run after the EAP authentication, the same 649 default crypto-suite is used in this case as explained in the Key 650 Derivation Section Section 4 The cryptographic suite is not 651 negotiated. If the cryptographic suite to be used by the node is 652 different from default, the AAA server will send the specific 653 parameters to the Authenticator. If the cryptographic suite is not 654 supported, the key derivation process would result in a security 655 association failure. 657 7.3. Freshness of the key material 659 In this design, we do not exchange nonces to provide freshness to the 660 keys derived from the MSK. This is done under the assumption that 661 the MSK and EMSK keys derived are fresh key material by the 662 specifications of the EAP KMF. Since only one session key is derived 663 from the MSK we do not have to concern ourselves with the generation 664 of additional key material. In case we need to refresh the MSK, a 665 re-authentication can be done, by running process again, using a more 666 lightweight mechanism to derive additional key material such as ERP 667 [RFC6696]. 669 8. IANA Considerations 671 This document has no actions for IANA. 673 9. Acknowledgments 675 We would like to thank Pedro Moreno-Sanchez and Gabriel Lopez-Millan 676 for the first review of this document. Also, we would like to thank 677 Ivan Jimenez-Sanchez for the first proof-of-concept implementation of 678 this idea. 680 We also thank for their valuables comments to Alexander Pelov and 681 Laurent Toutain, specially for the potential optimizations of CoAP- 682 EAP. 684 10. References 686 10.1. Normative References 688 [I-D.ietf-ace-oauth-authz] 689 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 690 H. Tschofenig, "Authentication and Authorization for 691 Constrained Environments (ACE) using the OAuth 2.0 692 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-36 693 (work in progress), November 2020. 695 [I-D.ietf-lwig-coap] 696 Kovatsch, M., Bergmann, O., and C. Bormann, "CoAP 697 Implementation Guidance", draft-ietf-lwig-coap-06 (work in 698 progress), July 2018. 700 [I-D.ingles-eap-edhoc] 701 Sanchez, E., Garcia-Carrillo, D., and R. Marin-Lopez, "EAP 702 method based on EDHOC Authentication", draft-ingles-eap- 703 edhoc-01 (work in progress), November 2020. 705 [I-D.kumar-dice-dtls-relay] 706 Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay 707 for Constrained Environments", draft-kumar-dice-dtls- 708 relay-02 (work in progress), October 2014. 710 [I-D.ohba-core-eap-based-bootstrapping] 711 Das, S. and Y. Ohba, "Provisioning Credentials for CoAP 712 Applications using EAP", draft-ohba-core-eap-based- 713 bootstrapping-01 (work in progress), March 2012. 715 [I-D.pelov-core-cosol] 716 Pelov, A., Toutain, L., and Y. Delibie, "Constrained 717 Signaling Over LP-WAN", draft-pelov-core-cosol-01 (work in 718 progress), February 2016. 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, 723 . 725 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 726 Levkowetz, Ed., "Extensible Authentication Protocol 727 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 728 . 730 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 731 Ciphersuites for Transport Layer Security (TLS)", 732 RFC 4279, DOI 10.17487/RFC4279, December 2005, 733 . 735 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 736 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 737 2006, . 739 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 740 Advanced Encryption Standard-Cipher-based Message 741 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 742 PRF-128) Algorithm for the Internet Key Exchange Protocol 743 (IKE)", RFC 4615, DOI 10.17487/RFC4615, August 2006, 744 . 746 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 747 Pre-Shared Key Extensible Authentication Protocol (EAP) 748 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 749 . 751 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 752 and A. Yegin, "Protocol for Carrying Authentication for 753 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 754 May 2008, . 756 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 757 Authentication Protocol (EAP) Key Management Framework", 758 RFC 5247, DOI 10.17487/RFC5247, August 2008, 759 . 761 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 762 "Specification for the Derivation of Root Keys from an 763 Extended Master Session Key (EMSK)", RFC 5295, 764 DOI 10.17487/RFC5295, August 2008, 765 . 767 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 768 Key Derivation Function (HKDF)", RFC 5869, 769 DOI 10.17487/RFC5869, May 2010, 770 . 772 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and 773 A. Yegin, "Protocol for Carrying Authentication for 774 Network Access (PANA) Relay Element", RFC 6345, 775 DOI 10.17487/RFC6345, August 2011, 776 . 778 [RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., Ed., and G. Zorn, Ed., 779 "EAP Extensions for the EAP Re-authentication Protocol 780 (ERP)", RFC 6696, DOI 10.17487/RFC6696, July 2012, 781 . 783 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 784 Constrained-Node Networks", RFC 7228, 785 DOI 10.17487/RFC7228, May 2014, 786 . 788 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 789 Application Protocol (CoAP)", RFC 7252, 790 DOI 10.17487/RFC7252, June 2014, 791 . 793 [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A 794 RADIUS Attribute, Binding, Profiles, Name Identifier 795 Format, and Confirmation Methods for the Security 796 Assertion Markup Language (SAML)", RFC 7833, 797 DOI 10.17487/RFC7833, May 2016, 798 . 800 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 801 Bose, "Constrained Application Protocol (CoAP) Option for 802 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 803 August 2016, . 805 10.2. Informative References 807 [cantcoap] 808 Mills, A., "Cantcoap implementation of CoAP", January 809 2013. 811 [coap-eap] 812 Garcia-Carrillo, D. and R. Marin-Lopez, "Lightweight CoAP- 813 Based Bootstrapping Service for the Internet of Things - 814 https://www.mdpi.com/1424-8220/16/3/358", March 2016. 816 [Contiki] Contiki, "Contiki: The Open Source OS for the Internet of 817 Things", March 2014. 819 [hostapd] hostapd, "hostapd: IEEE 802.11 AP, IEEE 820 802.1X/WPA/WPA2/EAP/RADIUS Authenticator", March 2014. 822 Appendix A. CoAP-EAP with DTLS 824 Other possibility at our disposal is to do a DTLS handshake after the 825 MSKs generation and continue the communication between endpoints 826 using CoAP through DTLS as we can see at Figure 5. The Steps 0-6 are 827 the same as the case with OSCORE, however, before continuing with 828 Steps 7 and 8, the EAP authenticator starts the DTLS handshake with 829 the EAP peer (Step 6'). To establish a DTLS Security Association, a 830 key named DTLS-PSK is derived from MSK (see Section 4 ). In this 831 case the CoAP client can start DTLS before sending the last message 832 containing the EAP Success. Once DTLS is established, any posterior 833 CoAP exchange is protected. Thus, OSCORE in this instance is not 834 needed for key confirmation, since a successful DTLS negotiation 835 confirms the possession of DTLS_PSK that, in turn, corroborates that 836 both entities participated in the EAP authentication. 838 EAP peer EAP Auth. 839 (COAP server) (COAP client) 840 ------------- ------------- 841 | | 842 | NON [0x6af5] | 843 | POST /b | 844 | No-Response | 845 0) | Token (0xab) | 846 |---------------------------------------->| 847 | | 848 | CON [0x7654] | 849 | POST /b | 850 | SeqNum(x) | 851 | Token (0xac) | 852 | Payload EAP Req/Id | 853 1) |<----------------------------------------| 854 | | 855 | ACK [0x7654] | 856 | SeqNum(x) | 857 | Token (0xac) | 858 | 2.01 Created | 859 | Uri-Path [/b/5] | 860 | Payload EAP Rep/Id | 861 2) |---------------------------------------->| 862 | | 863 | CON [0x8694] | 864 | POST /b/5 | 865 | SeqNum(x+1) | 866 | Token (0xac) | 867 | Payload EAP-X MSG 1 | 868 3) |<----------------------------------------| 869 | | 870 | ACK [0x8694] | 871 | Token (0xac) | 872 | SeqNum(x+1) | 873 | 2.04 Changed | 874 | Payload EAP-X MSG 2 | 875 4) |---------------------------------------->| 876 .... 878 | | 879 | CON [0x9869] | 880 | POST /b/5 | 881 | SeqNum(x+n/2)| 882 | Token (0xac) | 883 | Payload EAP-X MSG (n-1) | 884 5) |<----------------------------------------| 885 | | 886 | ACK [0x9869] | 887 | SeqNum(x+n/2) | 888 | Token (0xac) | 889 | 2.04 Changed | 890 | Payload EAP-X MSG (n) | 891 MSK 6)|---------------------------------------->| MSK 892 | | | | 893 DTLS_PSK| | DTLS_PSK 894 | | 895 | DTLS HANDSHAKE | 896 | (Initiated by EAP Auth.) | 897 6') |<--------------------------------------->| 898 | | 899 | CON [0x7811] | 900 | POST /b/5 | 901 | Token (0xac) | 902 | Payload EAP Success | (*) 903 7) |<----------------------------------------| 904 | | 905 | ACK [0x7811] | 906 (*) | Token (0xac) | 907 | 2.04 Changed | 908 8) |---------------------------------------->| 910 (*) Protected with DTLS 912 Figure 5: EAP over CoAP with DTLS 914 A.1. Deriving DTLS_PSK 916 In the second alternative, a DTLS_PSK is derived from the MSK between 917 both CoAP endpoints. So far, DTLS_PSK will have also 16 byte length 918 and it will derived from the RK (generated as done in 919 Section Section 4) as follows: 921 DTLS_PSK = HKDF(RK, "IETF_DTLS_PSK" , length). This value is 922 concatenated with the value of the Token Option value. 924 where: 926 o RK is the Random Key generated in the Extract phase, from the MSK. 928 o "IETF_DTLS_PSK" is the ASCII code representation of the non-NULL 929 terminated string (excluding the double quotes around it). 931 o length is the length of the DTLS_PSK (16 bytes). 933 Authors' Addresses 934 Rafa Marin-Lopez 935 University of Murcia 936 Campus de Espinardo S/N, Faculty of Computer Science 937 Murcia 30100 938 Spain 940 Phone: +34 868 88 85 01 941 Email: rafa@um.es 943 Dan Garcia Carrillo 944 University of Oviedo 945 Calle Luis Ortiz Berrocal S/N, Edificio Polivalente 946 Gijon, Asturias 33203 947 Spain 949 Email: garciadan@uniovi.es