idnits 2.17.1 draft-marin-ace-wg-coap-eap-05.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 : ---------------------------------------------------------------------------- ** There are 19 instances of too long lines in the document, the longest one being 19 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 21, 2017) is 2552 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '0x6af5' is mentioned on line 336, but not defined == Missing Reference: '0x73DE' is mentioned on line 348, but not defined == Missing Reference: '0x7654' is mentioned on line 373, but not defined == Missing Reference: '0x9869' is mentioned on line 385, but not defined == Missing Reference: '0x7811' is mentioned on line 404, but not defined == Missing Reference: '0x7511' is mentioned on line 417, but not defined == Missing Reference: '0x7600' is mentioned on line 425, but not defined == Missing Reference: '0x7500' is mentioned on line 430, but not defined Summary: 1 error (**), 0 flaws (~~), 9 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 D. Garcia 4 Intended status: Experimental University of Murcia 5 Expires: October 23, 2017 April 21, 2017 7 EAP-based Authentication Service for CoAP 8 draft-marin-ace-wg-coap-eap-05 10 Abstract 12 This document describes an authentication service that uses EAP 13 transported by means of CoAP messages with two purposes: 15 o Authenticate two CoAP endpoints. 17 o Bootstrap key material to protect CoAP messages exchanged between 18 them. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 23, 2017. 37 Copyright Notice 39 Copyright (c) 2017 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. General Architecture . . . . . . . . . . . . . . . . . . . . 3 57 3. General Flow Operation . . . . . . . . . . . . . . . . . . . 3 58 3.1. EAP in CoAP with AUTH option . . . . . . . . . . . . . . 4 59 3.2. CoAP-EAP with DTLS . . . . . . . . . . . . . . . . . . . 7 60 3.3. CoAP as EAP lower-layer . . . . . . . . . . . . . . . . . 10 61 3.4. Optimization Considerations . . . . . . . . . . . . . . . 11 62 4. Key Derivation for protecting CoAP messages . . . . . . . . . 11 63 4.1. Deriving COAP_PSK . . . . . . . . . . . . . . . . . . . . 11 64 4.2. Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . . 12 65 5. Generating AUTH option . . . . . . . . . . . . . . . . . . . 13 66 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 14 67 7. Future Work: CoAP Intermediaries . . . . . . . . . . . . . . 15 68 8. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 16 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 10.1. Authorization . . . . . . . . . . . . . . . . . . . . . 18 72 10.2. Cryptographic suite selection . . . . . . . . . . . . . 18 73 10.3. Additional Security Consiederation . . . . . . . . . . . 18 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 75 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 77 12.2. Informative References . . . . . . . . . . . . . . . . . 20 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 80 1. Introduction 82 The goal of this document is to describe an authentication service 83 that uses the Extensible Authentication Protocol (EAP) [RFC3748]. 84 The authentication service is built on top of the Constrained 85 Application Protocol (CoAP) [RFC7252] and allows authenticating two 86 CoAP endpoints by using EAP without the need of additional protocols 87 to bootstrap a security association between them. 89 In particular, the document describes how CoAP can be used as EAP 90 lower-layer [RFC3748] to transport EAP between a CoAP server (EAP 91 peer) and the CoAP client (EAP authenticator) using CoAP messages. 92 The CoAP client may contact with a backend AAA infrastructure to 93 complete the EAP negotiation as described in the EAP specification 94 [RFC3748]. 96 The assumption is that the EAP method transported in CoAP MUST 97 generate cryptographic material [RFC5247] . In this way, the CoAP 98 messages can be protected. There are two approaches that we have 99 considered in this document: 101 o To define a new AUTH option that includes an authentication tag 102 generated with the cryptographic material exported during an EAP 103 authentication. This new option is used to protect the integrity 104 of the CoAP message that carries the AUTH option. (NOTE: 105 Encryption will be considered in the future). 107 o To establish a DTLS security association using the exported 108 cryptographic material after a successful EAP authentication. 109 [I-D.ohba-core-eap-based-bootstrapping] 111 This document also provides some comments about implementation of a 112 proof-of-concept of this preliminary idea 114 1.1. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 2. General Architecture 122 The Figure 1 shows the architecture defined in this document. 123 Basically a node acting as the EAP peer wants to be authenticated by 124 using EAP. At the time of writing this document, we have considered 125 a model where the EAP peer will act as CoAP server for this service 126 and the EAP authenticator will act as CoAP client and may interact 127 with a backend AAA infrastructure. Nevertheless, a model where the 128 EAP peer act as CoAP client and the EAP authenticator as CoAP server 129 will be also analyzed in the future. 131 +------------+ +------------+ +--------------+ 132 | EAP peer/ | | EAP auth./ | | EAP server/ | 133 | CoAP server|+------+| CoAP client|+-----+| AAA server | 134 +------------+ CoAP +------------+ AAA +--------------+ 136 Figure 1: CoAP EAP Architecture 138 3. General Flow Operation 140 The authentication service uses the CoAP protocol as transport layer 141 for EAP. CoAP becomes an EAP lower-layer (in EAP terminology). In 142 general, it is assumed that, since the EAP authenticator may need to 143 implement an AAA client to interact with the AAA infrastructure, this 144 endpoint will have more resources. We describe two different 145 sequence flow. First, it is shown in Figure 2 where the AUTH option 146 is used at the end of EAP authentication. Second diagram (see 147 Figure 3) shows the flow when DTLS is used to protect CoAP messages 148 at the end of the EAP authentication. As an example, both diagrams 149 show the usage of the EAP-PSK method [RFC4764] as authentication 150 mechanism. (NOTE: any EAP method which is able to export 151 cryptographic material should be valid). 153 3.1. EAP in CoAP with AUTH option 155 If the EAP peer discovers the presence of the EAP authenticator and 156 wants to start the authentication, it can send a Non-Confirmable 157 "POST /auth" request to the node (Step 0). This message, will carry 158 an option developed from this work [RFC7967] called no response. The 159 rationale of these options is avoiding having to listen to a response 160 if is not needed. So the use of this option will allow us to signal 161 the intention of the EAP-Peer to start the authentication process. 162 Immediately after that, the EAP authenticator will start the 163 authentication service. It is worth noting that the EAP 164 authenticator may decide to start the authentication without waiting 165 for a "POST /auth" message. 167 In any case, to perform the authentication service, the CoAP client 168 (EAP authenticator) sends a Confirmable "POST /auth" request to the 169 CoAP Server (Step 1). POST message indicates to the CoAP server the 170 creation of a resource for the EAP-based authentication service. The 171 CoAP server assigns a resource and answers with an Acknowledgment 172 with the piggy-backed resource identifier (Uri-Path) (Step 2). It is 173 assumed that the CoAP server will only have an ongoing authentication 174 and will not process simultaneous EAP authentications in parallel to 175 save resources. Moreover if after a period of time (TBD) no further 176 message is received from the CoAP client, the CoAP server will free 177 the created state. In this moment, the CoAP server has started a 178 resource for the EAP authentication, whose resource identifier value 179 will be used together with the Token option value to relate all the 180 EAP conversation between both CoAP endpoints. 182 From now on, the EAP authenticator and the EAP peer will exchange EAP 183 packets transported in the CoAP message payload (Steps 184 3,4,5,6,7,8,9). The EAP authenticator will use POST method to send 185 EAP requests to the EAP peer. The EAP peer will use a Piggy-backed 186 response in the Acknowledgement message to carry the EAP response. 187 At the end of the message exchanges, if everything has gone well, the 188 EAP authenticator is able to send an EAP Success message and both 189 CoAP endpoints will share a Master Session Key (MSK) ([RFC5295]) 190 If the new defined AUTH option is used, an authentication tag is 191 generated with a new key named COAP_PSK, derived from the MSK. The 192 Acknowledgment message from the CoAP server will also include an AUTH 193 option so that the CoAP client can verify that the CoAP server 194 obtained the MSK. This is shown in Steps 9 and 10. From that point 195 any exchange (for example, Steps 11 and 12) between both CoAP 196 endpoints are protected with the AUTH option. Finally, the CoAP 197 client MAY send a Confirmable DELETE request to remove all the state 198 related with the authentication service in the CoAP server (Steps 13 199 and 14). The CoAP server may decide to remove the state after period 200 of time in case not receiving a DELETE request. This may be easier 201 if the EAP authenticator sends a session lifetime option (TBD) in the 202 Step 9 (where the EAP Success is sent). 204 On the contrary, if DTLS is used (see Figure 3), a DTLS_PSK is 205 derived from the MSK. Moreover, exchanges between both CoAP 206 endpoints are protected with DTLS from that point. 208 EAP peer EAP Auth. 209 (COAP server) (COAP client) 210 ------------- ------------- 211 | | 212 | NON [0x6af5] | 213 | No-Response (0x1A) | 214 0) | (Token 0xFA5B45FF4723BB43) | 215 | POST /auth | 216 |---------------------------------------->| 217 | | 218 | | 219 | CON [0x73DE] | 220 | (Token 0x78728FD4AC3190FF) | 221 | POST /auth | 222 | Payload nonce_c | 223 1) |<----------------------------------------| 224 | | 225 | ACK [0x73DE] | 226 | (Token 0x78728FD4AC3190FF) | 227 | 2.01 Created | 228 | Uri-Path [auth/5] | 229 | Payload nonce_s | 230 2) |---------------------------------------->| 231 | | 232 | CON [0x7654] | 233 | (Token 0x78728FD4AC3190FF) | 234 | Payload EAP Req/Id | 235 | POST /auth/5 | 237 3) |<----------------------------------------| 238 | | 239 | ACK [0x7654] | 240 | (Token 0x78728FD4AC3190FF) | 241 | 2.04 Changed | 242 | Payload EAP Res/Id | 243 4) |---------------------------------------->| 244 | | 245 | CON [0x7654] | 246 | (Token 0x78728FD4AC3190FF) | 247 | Payload EAP-PSK MSG 1 | 248 | POST /auth/5 | 249 5) |<----------------------------------------| 250 | | 251 | ACK [0x7654] | 252 | (Token 0x78728FD4AC3190FF) | 253 | 2.04 Changed | 254 | Payload EAP-PSK MSG 2 | 255 6) |---------------------------------------->| 256 | | 257 | CON [0x9869] | 258 | (Token 0x78728FD4AC3190FF) | 259 | Payload EAP-PSK MSG 3 | 260 | POST /auth/5 | 261 7) |<----------------------------------------| 262 | | 263 | ACK [0x9869] | 264 | (Token 0x78728FD4AC3190FF) | 265 | 2.04 Changed | 266 | Payload EAP-PSK MSG 4 | 267 8) |---------------------------------------->| 268 MSK | | MSK 269 | | CON [0x7811] | | 270 COAP_PSK| (Token 0x78728FD4AC3190FF) |COAP_PSK 271 | AUTH option | 272 | Payload EAP Success | (*) 273 | POST /auth/5 | 274 9) |<----------------------------------------| 275 | | 276 (*) | ACK [0x7811] | 277 | (Token 0x78728FD4AC3190FF) | 278 | AUTH option | 279 | 2.04 Changed | 280 10) |---------------------------------------->| 282 ............. 284 | | 285 | CON [0x7511] | 286 | (Token 0x55566AF7464646BC) | (*) 287 | AUTH option | 288 | GET /temp | 289 11) |<----------------------------------------| 290 | | 291 | ACK [0x7511] | 292 (*) | (Token 0x55566AF7464646BC) | 293 | AUTH option | 294 | 2.05 Content | 295 | "22.5C" | 296 12) |---------------------------------------->| 297 ................ 299 | | 300 | CON [0x7600] | 301 | (Token 0x678443AA678BC690) | (*) 302 | AUTH option | 303 | DELETE /auth/5 | 304 13) |<----------------------------------------| 305 | | 306 | ACK [0x7500] | 307 (*) | (Token 0x678443AA678BC690) | 308 | AUTH option | 309 | 2.02 Deleted | 310 14) |---------------------------------------->| 312 (*) Protected with AUTH option 314 Figure 2: CoAP-EAP with AUTH option 316 3.2. CoAP-EAP with DTLS 318 Other possibility at our disposal is to do a DTLS handshake after the 319 MSKs generation and continue the communication between endpoints 320 using CoAP through DTLS as we can see at Figure 3. The Steps 0-8 are 321 the same as the case with AUTH option, however, before continuing 322 with Steps 10 and 11, the EAP authenticator starts the DTLS handshake 323 with the EAP peer (Step 9'). To establish a DTLS Security 324 Association, a key named DTLS-PSK is derived from MSK (see Section 4 325 ). In this case the CoAP client can start DTLS before sending the 326 last message containing the EAP Success. Once DTLS is established, 327 any posterior CoAP exchange is protected. Thus, new AUTH option is 328 not needed. A successful DTLS negotiation confirms the possession of 329 DTLS_PSK that, in turn, corroborates that both entities participated 330 in the EAP authentication. 332 EAP peer EAP Auth. 333 (COAP server) (COAP client) 334 ------------- ------------- 335 | | 336 | NON [0x6af5] | 337 | No-Response (0x1A) | 338 0) | (Token 0xFA5B45FF4723BB43) | 339 | POST /auth | 340 |---------------------------------------->| 341 | | 342 | CON [0x73DE] | 343 | (Token 0x78728FD4AC3190FF) | 344 | POST /auth | 345 | Payload nonce_c | 346 1) |<----------------------------------------| 347 | | 348 | ACK [0x73DE] | 349 | (Token 0x78728FD4AC3190FF) | 350 | 2.01 Created | 351 | Uri-Path [auth/5] | 352 | Payload nonce_s | 353 2) |---------------------------------------->| 354 | | 355 | CON [0x7654] | 356 | (Token 0x78728FD4AC3190FF) | 357 | Payload EAP Req/Id | 358 | POST /auth/5 | 359 3) |<----------------------------------------| 360 | | 361 | ACK [0x7654] | 362 | (Token 0x78728FD4AC3190FF) | 363 | 2.04 Changed | 364 | Payload EAP Res/Id | 365 4) |---------------------------------------->| 366 | | 367 | CON [0x7654] | 368 | (Token 0x78728FD4AC3190FF) | 369 | Payload EAP-PSK MSG 1 | 370 | POST /auth/5 | 371 5) |<----------------------------------------| 372 | | 373 | ACK [0x7654] | 374 | (Token 0x78728FD4AC3190FF) | 375 | 2.04 Changed | 376 | Payload EAP-PSK MSG 2 | 377 6) |---------------------------------------->| 378 | | 379 | CON [0x9869] | 380 | (Token 0x78728FD4AC3190FF) | 381 | Payload EAP-PSK MSG 3 | 382 | POST /auth/5 | 383 7) |<----------------------------------------| 384 | | 385 | ACK [0x9869] | 386 | (Token 0x78728FD4AC3190FF) | 387 | 2.04 Changed | 388 | Payload EAP-PSK MSG 4 | 389 8) |---------------------------------------->| 390 MSK | | MSK 391 | | | | 392 DTLS_PSK| | DTLS_PSK 393 | | 394 | DTLS HANDSHAKE | 395 | (Initiated by EAP Auth.) | 396 9') |<--------------------------------------->| 397 | | 398 | CON [0x7811] | 399 | (Token 0x78728FD4AC3190FF) | 400 | Payload EAP Success | (*) 401 | POST /auth/5 | 402 10) |<----------------------------------------| 403 | | 404 | ACK [0x7811] | 405 (*) | (Token 0x78728FD4AC3190FF) | 406 | 2.04 Changed | 407 11) |---------------------------------------->| 409 ............. 411 | | 412 | CON [0x7511] | 413 | (Token 0xAA763D82F623B7FF) | (*) 414 | GET /temp | 415 12) |<----------------------------------------| 416 | | 417 | ACK [0x7511] | 418 (*) | (Token 0xAA763D82F623B7FF) | 419 | 2.05 Content | 420 | "22.5C" | 421 13) |---------------------------------------->| 422 ................ 424 | | 425 | CON [0x7600] | 426 | (Token 0x678443AA678BC690) | (*) 427 | DELETE /auth/5 | 428 14) |<----------------------------------------| 429 | | 430 | ACK [0x7500] | 431 (*) | (Token 0x678443AA678BC690) | 432 | 2.02 Deleted | 433 15) |---------------------------------------->| 435 (*) Protected with DTLS 437 Figure 3: EAP over CoAP with DTLS 439 3.3. CoAP as EAP lower-layer 441 In this section we discuss the suitability of the CoAP protocol as 442 EAP lower layer, and review the requisites imposed by the EAP 443 protocol to any protocol that transports EAP. The assumptions EAP 444 makes about its lower layers can be found in section 3.1 of the rfc 445 [RFC3748], which are enumerated next: 447 o Unreliable transport. EAP does lower layers are not assumed 448 reliable. 450 o Lower layer error detection. EAP relies on lower layer error 451 detection (e.g., CRC, Checksum, MIC, etc.) 453 o Lower layer security. EAP does not require security services from 454 the lower layers. 456 o Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 457 octets or greater. 459 o Possible duplication. EAP stipulates that, while desirable, it 460 does not require for the lower layers to provide non-duplication. 462 o Ordering guarantees. EAP relies on lower layer ordering 463 guarantees for correct operation. 465 Next we go over the previous points to verify that CoAP does fits the 466 EAP lower layer requirements. Regarding the unreliable transport, 467 although EAP assumes a non reliable transport, CoAP does provide a 468 reliability mechanism through the use of Confirmable messages. For 469 the error detection, CoAP goes on top of UDP which provides a 470 checksum mechanism over its payload. Lower layer security services 471 are not required. About the minimum MTU of 1020 octets, CoAP assumes 472 an upper bound of 1024 for its payload which covers the requirements 473 of EAP. About possible duplication, although not required, CoAP 474 provides a message-ID value for deduplication purposes. Finally for 475 the ordering guarantees needed by EAP, CoAP message-ID can be used 476 for this purpose. 478 As we can see, CoAP does fulfill the requirements of EAP to be 479 considered suitable as lower-layer. 481 3.4. Optimization Considerations 483 Here we consider two possible optimizations for reducing the message 484 length: 486 o A first optimization would be to reduce the URI of the 487 bootstrapping service. For example, the /auth URI could be 488 reduced to /a. 490 o Another optimization would be to use a zero length CoAP token in 491 the exchange. 493 Some use cases as LoRA Networks [I-D.pelov-core-cosol] might take 494 advantage of these reductions to improve the performance of the 495 bootstrapping process. 497 4. Key Derivation for protecting CoAP messages 499 As a result of a successful EAP authentication, both CoAP server and 500 CoAP client share a Master Key Session (MSK). The assumption is that 501 MSK is a fresh key so any derived key from the MSK will be also 502 fresh. We have considered the derivation of either COAP_PSK or 503 DTLS_PSK. 505 4.1. Deriving COAP_PSK 507 A key COAP_PSK is derived from the MSK to generate the authentication 508 tag included in the AUTH option. COAP_PSK is derived by using AES- 509 CMAC-PRF-128 [RFC4615], which, in turn, uses AES-CMAC-128 [RFC4493]. 510 In this case, rest of CoAP exchanges between both entities can be 511 protected with integrity (NOTE: encryption will be considered in the 512 future) with AUTH option without the need of using DTLS. Thus, all 513 CoAP messages MUST include AUTH option from that point. (NOTE: We 514 understand that this would not be the standard way of protecting CoAP 515 but instead a new way of protecting CoAP messages). 517 COAP_PSK is a 16-byte length key which is computed in the following 518 way: 520 COAP_PSK = KDF(MSK, "IETF_COAP_PSK" || nonce_c || nonce_s, 64, 521 length) 523 where: 525 o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses 526 AES-CMAC-128 as building block. 528 o The MSK exported by the EAP method. 530 o "IETF_COAP_PSK" is the ASCII code representation of the non-NULL 531 terminated string (excluding the double quotes around it). This 532 value is concatenated with the value of the Token Option value. 534 o nonce_c is the random value sent by the EAP Authenticator to the 535 EAP Peer in the POST Message. 537 o nonce_s is the random value sent by the EAP Peer to the EAP 538 Authenticator in the Acknowledgment to the POST Message. 540 o 64 is the length of the MSK. 542 o length is the length of the label "IETF_COAP_PSK" (13 bytes). 544 4.2. Deriving DTLS_PSK 546 In the second alternative, a DTLS_PSK is derived from the MSK between 547 both CoAP endpoints. So far, DTLS_PSK will have also 16 byte length 548 and it will derived as follows: 550 DTLS_PSK = KDF(MSK, "IETF_DTLS_PSK" || nonce_c || nonce_s, 64, 551 length). This value is concatenated with the value of the Token 552 Option value. 554 where: 556 o MSK is exported by the EAP method. 558 o "IETF_DTLS_PSK" is the ASCII code representation of the non-NULL 559 terminated string (excluding the double quotes around it). 561 o nonce_c is the random value sent by the EAP Authenticator to the 562 EAP Peer in the POST Message. 564 o nonce_s is the random value sent by the EAP Peer to the EAP 565 Authenticator in the Acknowledgment to the POST Message. 567 o 64 is the length of the MSK. 569 o length is the length of the label "IETF_DTLS_PSK" (13 bytes). 571 As mentioned in [RFC4279], a PSK identity is needed. We are 572 considering the usage of the Token Option value chosen during the EAP 573 authentication as identity. In any case, this still needs further 574 investigation. 576 5. Generating AUTH option 578 A new AUTH option is defined in this document for authentication 579 purposes. Following guidelines in [RFC7252] this option is: 581 1. Format opaque (sequence of bytes). 583 2. Elective. 585 3. Unsafe to Forward. 587 4. No cacheable. 589 The number of the option will be determined by this previous 590 decisions. 592 1. Elective (C = 0) 594 2. Unsafe to Forward (0) 596 3. NoCacheKey (111) 598 The number of the AUTH option will fit this pattern: xxx11100 600 0 1 2 3 4 5 6 7 601 +---+---+---+---+---+---+---+---+ 602 | | NoCacheKey| U | C | 603 +---+---+---+---+---+---+---+---+ 605 Figure 4: Auth Option Number Mask 607 First available option number is 01011100 (92). 609 The resultant AUTH option is: 611 +-----+----+---+---+---+-----------+--------+--------+---------+ 612 | No. | C | U | N | R | Name | Format | Length | Default | 613 +-----+----+---+---+---+-----------+--------+--------+---------+ 614 | 92 | | | x | | AUTH | opaque | 128 | (none) | 615 +-----+----+---+---+---+-----------+--------+--------+---------+ 617 Figure 5: AUTH Option 619 C, U, N and R columns indicate the properties, Critical, UnSafe, 620 NoCacheKey and Repeatable, respectively. 622 To generate the value of the AUTH option, we use AES-CMAC-128 as 623 authentication algorithm. Thus, the AUTH option content will have an 624 authentication tag of 16 bytes. 626 AUTH Option value = AES-CMAC-128(COAP_PSK, MSG, MSG_LENGTH) 628 where: 630 o COAP_PSK is the key derived in the CoAP Security Association 631 process. 633 o MSG is the CoAP message including AUTH option filled with zeros. 635 o MSG_LENGTH. Length of the CoAP message. 637 After applying AES-CMAC-128 function, the AUTH option value will be 638 set in the AUTH option replacing the zeros. 640 6. Implementation 642 At the time of writing this document, we have developed a proof-of- 643 concept based on libcoap ([libCoAP]) in PC platform and started the 644 development of a simulation with COOJA network simulator for Contiki 645 ([Contiki]). 647 So far, we have implemented an authentication tag by using AES-CMAC- 648 128. However this authentication tag has been included in the 649 payload of two final messages after sending the EAP Success. The 650 implementation of the AUTH option will come soon. Moreover, we have 651 used AES-CMAC-128 for COAP_PSK. Since this function does not allow a 652 key longer than 16 bytes, we have used the most significative 16 653 bytes of the MSK as input key. Since AES-CMAC-PRF-128 eliminates 654 this limitation, we will implement this version instead. 656 We are using (for the PC version) libeap in wpa-supplicant and 657 hostapd open source software ([hostapd]) to implement the EAP stack 658 and, in particular, the EAP-PSK method. 660 7. Future Work: CoAP Intermediaries 662 Architecture explained in Figure 1 assumes that EAP peer can 663 communicate with the EAP authenticator. In certain scenarios, EAP 664 authenticator may not be reachable from the EAP peer if the EAP 665 authenticator is placed several hops-away. In this scenario, 666 described in Figure 6, we are considering the usage a new service 667 that assists the authentication. This service acts as a intermediary 668 of CoAP messages between the EAP peer and EAP authenticator. 669 Currently we have a design of three different variants of this 670 entity. 672 o CoAP relay 674 o CoAP proxy 676 o CoAP stateless proxy 678 A proof-of-concept of the CoAP relay and CoAP proxy is evaluated and 679 a CoAP stateless proxy implementation is planned next. The strategy 680 is similar to the one described in PANA Relay ([RFC6345]) or DTLS 681 Relay ([I-D.kumar-dice-dtls-relay]). Unlike CoAP proxy, the CoAP 682 relay is not intended to keep any state (stateless behavior) and the 683 EAP peer is not assumed to be aware of the presence of the CoAP 684 relay. The CoAP stateless proxy provides an approach between the 685 previous two. It behaves as a proxy, but avoid generating any state 686 related to the ongoing exchange. 688 +------------+ +------------+ +--------------+ 689 | EAP peer/ | | CoAP | | EAP auth | 690 | CoAP server|+------+|intermediary|+------+| CoaP client | 691 +------------+ CoAP +------------+ CoAP +--------------+ 692 | 693 AAA | 694 | 695 +--------------+ 696 | EAP server/ | 697 | AAA server | 698 +--------------+ 700 Figure 6: CoAP EAP Intermediary Architecture 702 Once the EAP peer has been authenticated, CoAP intermediary should 703 not be needed anymore for this EAP peer. 705 Development of this new service may modify the "Unsafe to Forward" 706 flag of the AUTH option. 708 8. Use Case Scenario 710 In the following, we explain a basic example about the usage of CoAP- 711 EAP. There are 5 entities involved in the scenario: 713 o 2 nodes (A and B), which are constrained devices. 715 o 1 node D, which is considered a no so constrained device, such as 716 a phone, or a tablet or even a laptop. 718 o 1 controller (C). The controller manages a domain where nodes can 719 be deployed. It can be considered a more powerful machine than 720 the nodes, however it may have some constrained resources. 722 o 1 AAA server (AAA). The AAA is an Authentication, Authorization 723 and Accounting Server, which is not constrained. 725 Any node wanting to join the domain managed by the controller, must 726 perform an CoAP-EAP authentication with the controller C. This 727 authentication, as depicted in Figure 6, may involve an external AAA 728 server. This means that A and B, once deployed, will perform this 729 CoAP-EAP once as a bootstrapping phase to establish a security 730 association with the controller C. Moreover, any other entity (i.e. 731 node D) , which wants to join and establish communications with nodes 732 under the controller C's domain must also do the same. 734 One use case is the following. The node A wants to communicate with 735 node B (e.g. to active a light switch). The overall process is 736 divided in three phases. Let's start with node A. In the first 737 phase, the node A (EAP peer) does not yet belong to the controller 738 C's domain. Then, it communicates with controller C (EAP 739 authenticator) and authenticates with CoAP-EAP, which, in turn, 740 communicates with the AAA server to complete the authentication 741 process. If the authentication is successful, key material is 742 distributed to the controller C and derived by node A. This key 743 material allows node A to establish a security association with 744 controller C. Some authorization information may be also provided in 745 this step. If authentication and authorization are correct, node A 746 is enrolled in the controller C's domain during a period of time. In 747 particular, [RFC5247] recommends 8 hours, though the AAA server can 748 establish this lifetime. In the same manner, B needs to perform the 749 same process with CoAP-EAP to be part of the controller C's domain. 751 In the second phase, when node A wants to talk with node B, it 752 contacts the controller C for authorization to access node B and 753 obtain all the required information to do that in a secure manner 754 (e.g. keys, tokens, authorization information, etc.). It does not 755 require the usage of CoAP-EAP. The details of this phase are out of 756 scope of this document. 758 In the third phase, the node A can access node B with the credentials 759 and information obtained from the controller C in the second phase. 760 This access can be repeated without contacting the controller, while 761 the credentials given to A are still valid. The details of this 762 phase are out of scope of this document. 764 It is worth noting that first phase with CoAP-EAP is only required to 765 join the controller C's domain. Once it is performed with success, 766 the communications are local to the controller C's domain so there is 767 no need to contact the external AAA server. 769 Another use case is the following. Node D wants to communicate with 770 node A (e.g. to obtain a temperature measurement). To do that, first 771 of all, node D must join the controller C's domain. To do that it 772 performs a CoAP-EAP authentication and authorization with the 773 controller C (first phase). If everything ends with success, the 774 node D can request access to node A to C (second phase). Then if 775 node D is authorized can access to node A (third phase). So, in the 776 end, node D also implements CoAP-EAP as any other constrained node. 778 9. Acknowledgments 780 We would like to thank Pedro Moreno-Sanchez and Gabriel Lopez-Millan 781 for the first review of this document. Also, we would like to thank 782 Ivan Jimenez-Sanchez for the first proof-of-concept implementation of 783 this idea. 785 We also thank for their valuables comments to Alexander Pelov and 786 Laurent Toutain, specially for the potential optimizations of CoAP- 787 EAP. 789 This work has been partly funded by European Commission through the 790 FP7-SMARTIE-609062 EU Project. 792 10. Security Considerations 794 There are some aspects to be considered such as how authorization is 795 managed, how the cryptographic suite is selected and how the trust in 796 the Controller is established. 798 10.1. Authorization 800 Authorization is part of the bootstrapping. It serves to establish 801 whether the node can join and the set of conditions it has to adhere. 802 The authorization data received from the AAA server (RADIUS in this 803 case) can be delivered in RADIUS attributes such as NAS-Filter-Rules, 804 Framed-MTU, Session-Timeout, etc. Providing more fine grained 805 authorization data can be with the transport of SAML in RADIUS 806 [RFC7833] After bootstrapping, additional authorization to operate in 807 the security domain, e.g., access services offered by other nodes, 808 can be taken care of by the solutions proposed in the ACE WG. 810 10.2. Cryptographic suite selection 812 How the cryptographic suit is selected is also important. To reduce 813 the overhead of the protocol we use a default cryptographic suite. 814 To support the protocol all implementations MUST at least support 815 AES-CMAC-PRF-128 as the KDF and AES-CMAC-128 as default. The 816 cryptographic suite is not negotiated. If the cryptographic suite to 817 be used by the node is different from default, the AAA server will 818 send the specific parameters to the Authenticator. If the 819 cryptographic suite is not supported, the key derivation process 820 would result in a security association failure. 822 10.3. Additional Security Consiederation 824 Other security related concerns can be how to ensure that the node 825 joining the security domain can in fact trust the Controller. This 826 issue is elaborated in the EAP KMF[RFC5247] . Summarizing, the node 827 knows it can trust the Controller, because the key that is used to 828 establish the security association is derived from the MSK. If the 829 Controller has the MSK, it is clear the AAA Server of the node trusts 830 the Controller, which confirms it is a trusted party. 832 11. IANA Considerations 834 This document has no actions for IANA. 836 12. References 838 12.1. Normative References 840 [I-D.kumar-dice-dtls-relay] 841 Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay 842 for Constrained Environments", draft-kumar-dice-dtls- 843 relay-02 (work in progress), October 2014. 845 [I-D.ohba-core-eap-based-bootstrapping] 846 Das, S. and Y. Ohba, "Provisioning Credentials for CoAP 847 Applications using EAP", draft-ohba-core-eap-based- 848 bootstrapping-01 (work in progress), March 2012. 850 [I-D.pelov-core-cosol] 851 Pelov, A., Toutain, L., and Y. Delibie, "Constrained 852 Signaling Over LP-WAN", draft-pelov-core-cosol-01 (work in 853 progress), February 2016. 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, 857 DOI 10.17487/RFC2119, March 1997, 858 . 860 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 861 Levkowetz, Ed., "Extensible Authentication Protocol 862 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 863 . 865 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 866 Ciphersuites for Transport Layer Security (TLS)", 867 RFC 4279, DOI 10.17487/RFC4279, December 2005, 868 . 870 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 871 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 872 2006, . 874 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 875 Advanced Encryption Standard-Cipher-based Message 876 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 877 PRF-128) Algorithm for the Internet Key Exchange Protocol 878 (IKE)", RFC 4615, DOI 10.17487/RFC4615, August 2006, 879 . 881 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 882 Pre-Shared Key Extensible Authentication Protocol (EAP) 883 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 884 . 886 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 887 Authentication Protocol (EAP) Key Management Framework", 888 RFC 5247, DOI 10.17487/RFC5247, August 2008, 889 . 891 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 892 "Specification for the Derivation of Root Keys from an 893 Extended Master Session Key (EMSK)", RFC 5295, 894 DOI 10.17487/RFC5295, August 2008, 895 . 897 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and 898 A. Yegin, "Protocol for Carrying Authentication for 899 Network Access (PANA) Relay Element", RFC 6345, 900 DOI 10.17487/RFC6345, August 2011, 901 . 903 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 904 Application Protocol (CoAP)", RFC 7252, 905 DOI 10.17487/RFC7252, June 2014, 906 . 908 [RFC7833] Howlett, J., Hartman, S., and A. Perez-Mendez, Ed., "A 909 RADIUS Attribute, Binding, Profiles, Name Identifier 910 Format, and Confirmation Methods for the Security 911 Assertion Markup Language (SAML)", RFC 7833, 912 DOI 10.17487/RFC7833, May 2016, 913 . 915 [RFC7967] Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 916 Bose, "Constrained Application Protocol (CoAP) Option for 917 No Server Response", RFC 7967, DOI 10.17487/RFC7967, 918 August 2016, . 920 12.2. Informative References 922 [Contiki] "Contiki: The Open Source OS for the Internet of Things", 923 March 2014. 925 [hostapd] "hostapd: IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS 926 Authenticator", March 2014. 928 [libCoAP] "C-Implementation of CoAP", January 2013. 930 Authors' Addresses 931 Rafa Marin-Lopez 932 University of Murcia 933 Campus de Espinardo S/N, Faculty of Computer Science 934 Murcia 30100 935 Spain 937 Phone: +34 868 88 85 01 938 Email: rafa@um.es 940 Dan Garcia Carrillo 941 University of Murcia 942 Campus de Espinardo S/N, Faculty of Computer Science 943 Murcia 30100 944 Spain 946 Phone: +34 868 88 78 82 947 Email: dan.garcia@um.es