idnits 2.17.1 draft-marin-ace-wg-coap-eap-04.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 (October 21, 2016) is 2744 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '0x6af5' is mentioned on line 333, but not defined == Missing Reference: '0x73DE' is mentioned on line 345, but not defined == Missing Reference: '0x7654' is mentioned on line 370, but not defined == Missing Reference: '0x9869' is mentioned on line 382, but not defined == Missing Reference: '0x7811' is mentioned on line 401, but not defined == Missing Reference: '0x7511' is mentioned on line 414, but not defined == Missing Reference: '0x7600' is mentioned on line 422, but not defined == Missing Reference: '0x7500' is mentioned on line 428, but not defined == Outdated reference: A later version (-17) exists of draft-tcs-coap-no-response-option-16 Summary: 1 error (**), 0 flaws (~~), 10 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: April 24, 2017 October 21, 2016 7 EAP-based Authentication Service for CoAP 8 draft-marin-ace-wg-coap-eap-04 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 April 24, 2017. 37 Copyright Notice 39 Copyright (c) 2016 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 Relay . . . . . . . . . . . . . . . . . . . 14 68 8. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 15 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 72 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 74 12.2. Informative References . . . . . . . . . . . . . . . . . 19 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 77 1. Introduction 79 The goal of this document is to describe an authentication service 80 that uses the Extensible Authentication Protocol (EAP) [RFC3748]. 81 The authentication service is built on top of the Constrained 82 Application Protocol (CoAP) [RFC7252] and allows authenticating two 83 CoAP endpoints by using EAP without the need of additional protocols 84 to bootstrap a security association between them. 86 In particular, the document describes how CoAP can be used as EAP 87 lower-layer [RFC3748] to transport EAP between a CoAP server (EAP 88 peer) and the CoAP client (EAP authenticator) using CoAP messages. 89 The CoAP client may contact with a backend AAA infrastructure to 90 complete the EAP negotiation as described in the EAP specification 91 [RFC3748]. 93 The assumption is that the EAP method transported in CoAP MUST 94 generate cryptographic material [RFC5247] . In this way, the CoAP 95 messages can be protected. There are two approaches that we have 96 considered in this document: 98 o To define a new AUTH option that includes an authentication tag 99 generated with the cryptographic material exported during an EAP 100 authentication. This new option is used to protect the integrity 101 of the CoAP message that carries the AUTH option. (NOTE: 102 Encryption will be considered in the future). 104 o To establish a DTLS security association using the exported 105 cryptographic material after a successful EAP authentication. 106 [I-D.ohba-core-eap-based-bootstrapping] 108 This document also provides some comments about implementation of a 109 proof-of-concept of this preliminary idea 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. General Architecture 119 The Figure 1 shows the architecture defined in this document. 120 Basically a node acting as the EAP peer wants to be authenticated by 121 using EAP. At the time of writing this document, we have considered 122 a model where the EAP peer will act as CoAP server for this service 123 and the EAP authenticator will act as CoAP client and may interact 124 with a backend AAA infrastructure. Nevertheless, a model where the 125 EAP peer act as CoAP client and the EAP authenticator as CoAP server 126 will be also analyzed in the future. 128 +------------+ +------------+ +--------------+ 129 | EAP peer/ | | EAP auth./ | | EAP server/ | 130 | CoAP server|+------+| CoAP client|+-----+| AAA server | 131 +------------+ CoAP +------------+ AAA +--------------+ 133 Figure 1: CoAP EAP Architecture 135 3. General Flow Operation 137 The authentication service uses the CoAP protocol as transport layer 138 for EAP. CoAP becomes an EAP lower-layer (in EAP terminology). In 139 general, it is assumed that, since the EAP authenticator may need to 140 implement an AAA client to interact with the AAA infrastructure, this 141 endpoint will have more resources. We describe two different 142 sequence flow. First, it is shown in Figure 2 where the AUTH option 143 is used at the end of EAP authentication. Second diagram (see 144 Figure 3) shows the flow when DTLS is used to protect CoAP messages 145 at the end of the EAP authentication. As an example, both diagrams 146 show the usage of the EAP-PSK method [RFC4764] as authentication 147 mechanism. (NOTE: any EAP method which is able to export 148 cryptographic material should be valid). 150 3.1. EAP in CoAP with AUTH option 152 If the EAP peer discovers the presence of the EAP authenticator and 153 wants to start the authentication, it can send a Non-Confirmable 154 "POST /auth" request to the node (Step 0). This message, will carry 155 an option developed from this work [I-D.tcs-coap-no-response-option] 156 called no response. The rationale of these options is avoiding 157 having to listen to a response if is not needed. So the use of this 158 option will allow us to signal the intention of the EAP-Peer to start 159 the authentication process. Immediately after that, the EAP 160 authenticator will start the authentication service. It is worth 161 noting that the EAP authenticator may decide to start the 162 authentication without waiting for a "POST /auth" message. 164 In any case, to perform the authentication service, the CoAP client 165 (EAP authenticator) sends a Confirmable "POST /auth" request to the 166 CoAP Server (Step 1). POST message indicates to the CoAP server the 167 creation of a resource for the EAP-based authentication service. The 168 CoAP server assigns a resource and answers with an Acknowledgment 169 with the piggy-backed resource identifier (Uri-Path) (Step 2). It is 170 assumed that the CoAP server will only have an ongoing authentication 171 and will not process simultaneous EAP authentications in parallel to 172 save resources. Moreover if after a period of time (TBD) no further 173 message is received from the CoAP client, the CoAP server will free 174 the created state. In this moment, the CoAP server has started a 175 resource for the EAP authentication, whose resource identifier value 176 will be used together with the Token option value to relate all the 177 EAP conversation between both CoAP endpoints. 179 From now on, the EAP authenticator and the EAP peer will exchange EAP 180 packets transported in the CoAP message payload (Steps 181 3,4,5,6,7,8,9). The EAP authenticator will use POST method to send 182 EAP requests to the EAP peer. The EAP peer will use a Piggy-backed 183 response in the Acknowledgement message to carry the EAP response. 184 At the end of the message exchanges, if everything has gone well, the 185 EAP authenticator is able to send an EAP Success message and both 186 CoAP endpoints will share a Master Session Key (MSK) ([RFC5295]) 188 If the new defined AUTH option is used, an authentication tag is 189 generated with a new key named COAP_PSK, derived from the MSK. The 190 Acknowledgment message from the CoAP server will also include an AUTH 191 option so that the CoAP client can verify that the CoAP server 192 obtained the MSK. This is shown in Steps 9 and 10. From that point 193 any exchange (for example, Steps 11 and 12) between both CoAP 194 endpoints are protected with the AUTH option. Finally, the CoAP 195 client MAY send a Confirmable DELETE request to remove all the state 196 related with the authentication service in the CoAP server (Steps 13 197 and 14). The CoAP server may decide to remove the state after period 198 of time in case not receiving a DELETE request. This may be easier 199 if the EAP authenticator sends a session lifetime option (TBD) in the 200 Step 9 (where the EAP Success is sent). 202 On the contrary, if DTLS is used (see Figure 3), a DTLS_PSK is 203 derived from the MSK. Moreover, exchanges between both CoAP 204 endpoints are protected with DTLS from that point. 206 EAP peer EAP Auth. 207 (COAP server) (COAP client) 208 ------------- ------------- 209 | | 210 | NON [0x6af5] | 211 | No-Response (0x1A) | 212 0) | (Token 0xFA5B45FF4723BB43) | 213 | POST /auth | 214 |---------------------------------------->| 215 | | 216 | | 217 | CON [0x73DE] | 218 | (Token 0x78728FD4AC3190FF) | 219 | POST /auth | 220 | Payload nonce_c | 221 1) |<----------------------------------------| 222 | | 223 | ACK [0x73DE] | 224 | (Token 0x78728FD4AC3190FF) | 225 | 2.01 Created | 226 | Uri-Path [auth/5] | 227 | Payload nonce_s | 228 2) |---------------------------------------->| 229 | | 230 | CON [0x7654] | 231 | (Token 0x78728FD4AC3190FF) | 232 | Payload EAP Req/Id | 233 | POST /auth/5 | 234 3) |<----------------------------------------| 235 | | 236 | ACK [0x7654] | 237 | (Token 0x78728FD4AC3190FF) | 238 | 2.04 Changed | 239 | Payload EAP Res/Id | 240 4) |---------------------------------------->| 241 | | 242 | CON [0x7654] | 243 | (Token 0x78728FD4AC3190FF) | 244 | Payload EAP-PSK MSG 1 | 245 | POST /auth/5 | 246 5) |<----------------------------------------| 247 | | 248 | ACK [0x7654] | 249 | (Token 0x78728FD4AC3190FF) | 250 | 2.04 Changed | 251 | Payload EAP-PSK MSG 2 | 252 6) |---------------------------------------->| 253 | | 254 | CON [0x9869] | 255 | (Token 0x78728FD4AC3190FF) | 256 | Payload EAP-PSK MSG 3 | 257 | POST /auth/5 | 258 7) |<----------------------------------------| 259 | | 260 | ACK [0x9869] | 261 | (Token 0x78728FD4AC3190FF) | 262 | 2.04 Changed | 263 | Payload EAP-PSK MSG 4 | 264 8) |---------------------------------------->| 265 MSK | | MSK 266 | | CON [0x7811] | | 267 COAP_PSK| (Token 0x78728FD4AC3190FF) |COAP_PSK 268 | AUTH option | 269 | Payload EAP Success | (*) 270 | POST /auth/5 | 271 9) |<----------------------------------------| 272 | | 273 (*) | ACK [0x7811] | 274 | (Token 0x78728FD4AC3190FF) | 275 | AUTH option | 276 | 2.04 Changed | 277 10) |---------------------------------------->| 279 ............. 281 | | 282 | CON [0x7511] | 283 | (Token 0x55566AF7464646BC) | (*) 284 | AUTH option | 285 | GET /temp | 286 11) |<----------------------------------------| 287 | | 288 | ACK [0x7511] | 289 (*) | (Token 0x55566AF7464646BC) | 290 | AUTH option | 291 | 2.05 Content | 292 | "22.5C" | 293 12) |---------------------------------------->| 294 ................ 296 | | 297 | CON [0x7600] | 298 | (Token 0x678443AA678BC690) | (*) 299 | AUTH option | 300 | DELETE /auth/5 | 301 13) |<----------------------------------------| 302 | | 303 | ACK [0x7500] | 304 (*) | (Token 0x678443AA678BC690) | 305 | AUTH option | 306 | 2.02 Deleted | 307 14) |---------------------------------------->| 309 (*) Protected with AUTH option 311 Figure 2: CoAP-EAP with AUTH option 313 3.2. CoAP-EAP with DTLS 315 Other possibility at our disposal is to do a DTLS handshake after the 316 MSKs generation and continue the communication between endpoints 317 using CoAP through DTLS as we can see at Figure 3. The Steps 0-8 are 318 the same as the case with AUTH option, however, before continuing 319 with Steps 10 and 11, the EAP authenticator starts the DTLS handshake 320 with the EAP peer (Step 9'). To establish a DTLS Security 321 Association, a key named DTLS-PSK is derived from MSK (see Section 4 322 ). In this case the CoAP client can start DTLS before sending the 323 last message containing the EAP Success. Once DTLS is established, 324 any posterior CoAP exchange is protected. Thus, new AUTH option is 325 not needed. A successful DTLS negotiation confirms the possession of 326 DTLS_PSK that, in turn, corroborates that both entities participated 327 in the EAP authentication. 329 EAP peer EAP Auth. 330 (COAP server) (COAP client) 331 ------------- ------------- 332 | | 333 | NON [0x6af5] | 334 | No-Response (0x1A) | 335 0) | (Token 0xFA5B45FF4723BB43) | 336 | POST /auth | 337 |---------------------------------------->| 338 | | 339 | CON [0x73DE] | 340 | (Token 0x78728FD4AC3190FF) | 341 | POST /auth | 342 | Payload nonce_c | 343 1) |<----------------------------------------| 344 | | 345 | ACK [0x73DE] | 346 | (Token 0x78728FD4AC3190FF) | 347 | 2.01 Created | 348 | Uri-Path [auth/5] | 349 | Payload nonce_s | 350 2) |---------------------------------------->| 351 | | 352 | CON [0x7654] | 353 | (Token 0x78728FD4AC3190FF) | 354 | Payload EAP Req/Id | 355 | POST /auth/5 | 356 3) |<----------------------------------------| 357 | | 358 | ACK [0x7654] | 359 | (Token 0x78728FD4AC3190FF) | 360 | 2.04 Changed | 361 | Payload EAP Res/Id | 362 4) |---------------------------------------->| 363 | | 364 | CON [0x7654] | 365 | (Token 0x78728FD4AC3190FF) | 366 | Payload EAP-PSK MSG 1 | 367 | POST /auth/5 | 368 5) |<----------------------------------------| 369 | | 370 | ACK [0x7654] | 371 | (Token 0x78728FD4AC3190FF) | 372 | 2.04 Changed | 373 | Payload EAP-PSK MSG 2 | 374 6) |---------------------------------------->| 375 | | 376 | CON [0x9869] | 377 | (Token 0x78728FD4AC3190FF) | 378 | Payload EAP-PSK MSG 3 | 379 | POST /auth/5 | 380 7) |<----------------------------------------| 381 | | 382 | ACK [0x9869] | 383 | (Token 0x78728FD4AC3190FF) | 384 | 2.04 Changed | 385 | Payload EAP-PSK MSG 4 | 386 8) |---------------------------------------->| 387 MSK | | MSK 388 | | | | 389 DTLS_PSK| | DTLS_PSK 390 | | 391 | DTLS HANDSHAKE | 392 | (Initiated by EAP Auth.) | 393 9') |<--------------------------------------->| 394 | | 395 | CON [0x7811] | 396 | (Token 0x78728FD4AC3190FF) | 397 | Payload EAP Success | (*) 398 | POST /auth/5 | 399 10) |<----------------------------------------| 400 | | 401 | ACK [0x7811] | 402 (*) | (Token 0x78728FD4AC3190FF) | 403 | 2.04 Changed | 404 11) |---------------------------------------->| 406 ............. 408 | | 409 | CON [0x7511] | 410 | (Token 0xAA763D82F623B7FF) | (*) 411 | GET /temp | 412 12) |<----------------------------------------| 413 | | 414 | ACK [0x7511] | 415 (*) | (Token 0xAA763D82F623B7FF) | 416 | 2.05 Content | 417 | "22.5C" | 418 13) |---------------------------------------->| 419 ................ 421 | | 422 | CON [0x7600] | 423 | (Token 0x678443AA678BC690) | (*) 424 | DELETE /auth/5 | 426 14) |<----------------------------------------| 427 | | 428 | ACK [0x7500] | 429 (*) | (Token 0x678443AA678BC690) | 430 | 2.02 Deleted | 431 15) |---------------------------------------->| 433 (*) Protected with DTLS 435 Figure 3: EAP over CoAP with DTLS 437 3.3. CoAP as EAP lower-layer 439 In this section we discuss the suitability of the CoAP protocol as 440 EAP lower layer, and review the requisites imposed by the EAP 441 protocol to any protocol that transports EAP. The assumptions EAP 442 makes about its lower layers can be found in section 3.1 of the rfc 443 [RFC3748], which are enumerated next: 445 o Unreliable transport. EAP does lower layers are not assumed 446 reliable. 448 o Lower layer error detection. EAP relies on lower layer error 449 detection (e.g., CRC, Checksum, MIC, etc.) 451 o Lower layer security. EAP does not require security services from 452 the lower layers. 454 o Minimum MTU. Lower layers need to provide an EAP MTU size of 1020 455 octets or greater. 457 o Possible duplication. EAP stipulates that, while desirable, it 458 does not require for the lower layers to provide non-duplication. 460 o Ordering guarantees. EAP relies on lower layer ordering 461 guarantees for correct operation. 463 Next we go over the previous points to verify that CoAP does fits the 464 EAP lower layer requirements. Regarding the unreliable transport, 465 although EAP assumes a non reliable transport, CoAP does provide a 466 reliability mechanism through the use of Confirmable messages. For 467 the error detection, CoAP goes on top of UDP which provides a 468 checksum mechanism over its payload. Lower layer security services 469 are not required. About the minimum MTU of 1020 octets, CoAP assumes 470 an upper bound of 1024 for its payload which covers the requirements 471 of EAP. About possible duplication, although not required, CoAP 472 provides a message-ID value for deduplication purposes. Finally for 473 the ordering guarantees needed by EAP, CoAP message-ID can be used 474 for this purpose. 476 As we can see, CoAP does fulfill the requirements of EAP to be 477 considered suitable as lower-layer. 479 3.4. Optimization Considerations 481 Here we consider two possible optimizations for reducing the message 482 length: 484 o A first optimization would be to reduce the URI of the 485 bootstrapping service. For example, the /auth URI could be 486 reduced to /a. 488 o Another optimization would be to use a zero length CoAP token in 489 the exchange. 491 Some use cases as LoRA Networks [I-D.pelov-core-cosol] might take 492 advantage of these reductions to improve the performance of the 493 bootstrapping process. 495 4. Key Derivation for protecting CoAP messages 497 As a result of a successful EAP authentication, both CoAP server and 498 CoAP client share a Master Key Session (MSK). The assumption is that 499 MSK is a fresh key so any derived key from the MSK will be also 500 fresh. We have considered the derivation of either COAP_PSK or 501 DTLS_PSK. 503 4.1. Deriving COAP_PSK 505 A key COAP_PSK is derived from the MSK to generate the authentication 506 tag included in the AUTH option. COAP_PSK is derived by using AES- 507 CMAC-PRF-128 [RFC4615], which, in turn, uses AES-CMAC-128 [RFC4493]. 508 In this case, rest of CoAP exchanges between both entities can be 509 protected with integrity (NOTE: encryption will be considered in the 510 future) with AUTH option without the need of using DTLS. Thus, all 511 CoAP messages MUST include AUTH option from that point. (NOTE: We 512 understand that this would not be the standard way of protecting CoAP 513 but instead a new way of protecting CoAP messages). 515 COAP_PSK is a 16-byte length key which is computed in the following 516 way: 518 COAP_PSK = KDF(MSK, "IETF_COAP_PSK" || nonce_c || nonce_s, 64, 519 length) 520 where: 522 o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses 523 AES-CMAC-128 as building block. 525 o The MSK exported by the EAP method. 527 o "IETF_COAP_PSK" is the ASCII code representation of the non-NULL 528 terminated string (excluding the double quotes around it). This 529 value is concatenated with the value of the Token Option value. 531 o nonce_c is the random value sent by the EAP Authenticator to the 532 EAP Peer in the POST Message. 534 o nonce_s is the random value sent by the EAP Peer to the EAP 535 Authenticator in the Acknowledgment to the POST Message. 537 o 64 is the length of the MSK. 539 o length is the length of the label "IETF_COAP_PSK" (13 bytes). 541 4.2. Deriving DTLS_PSK 543 In the second alternative, a DTLS_PSK is derived from the MSK between 544 both CoAP endpoints. So far, DTLS_PSK will have also 16 byte length 545 and it will derived as follows: 547 DTLS_PSK = KDF(MSK, "IETF_DTLS_PSK" || nonce_c || nonce_s, 64, 548 length). This value is concatenated with the value of the Token 549 Option value. 551 where: 553 o MSK is exported by the EAP method. 555 o "IETF_DTLS_PSK" is the ASCII code representation of the non-NULL 556 terminated string (excluding the double quotes around it). 558 o nonce_c is the random value sent by the EAP Authenticator to the 559 EAP Peer in the POST Message. 561 o nonce_s is the random value sent by the EAP Peer to the EAP 562 Authenticator in the Acknowledgment to the POST Message. 564 o 64 is the length of the MSK. 566 o length is the length of the label "IETF_DTLS_PSK" (13 bytes). 568 As mentioned in [RFC4279], a PSK identity is needed. We are 569 considering the usage of the Token Option value chosen during the EAP 570 authentication as identity. In any case, this still needs further 571 investigation. 573 5. Generating AUTH option 575 A new AUTH option is defined in this document for authentication 576 purposes. Following guidelines in [RFC7252] this option is: 578 1. Format opaque (sequence of bytes). 580 2. Elective. 582 3. Unsafe to Forward. 584 4. No cacheable. 586 The number of the option will be determined by this previous 587 decisions. 589 1. Elective (C = 0) 591 2. Unsafe to Forward (0) 593 3. NoCacheKey (111) 595 The number of the AUTH option will fit this pattern: xxx11100 597 0 1 2 3 4 5 6 7 598 +---+---+---+---+---+---+---+---+ 599 | | NoCacheKey| U | C | 600 +---+---+---+---+---+---+---+---+ 602 Figure 4: Auth Option Number Mask 604 First available option number is 01011100 (92). 606 The resultant AUTH option is: 608 +-----+----+---+---+---+-----------+--------+--------+---------+ 609 | No. | C | U | N | R | Name | Format | Length | Default | 610 +-----+----+---+---+---+-----------+--------+--------+---------+ 611 | 92 | | | x | | AUTH | opaque | 128 | (none) | 612 +-----+----+---+---+---+-----------+--------+--------+---------+ 614 Figure 5: AUTH Option 616 C, U, N and R columns indicate the properties, Critical, UnSafe, 617 NoCacheKey and Repeatable, respectively. 619 To generate the value of the AUTH option, we use AES-CMAC-128 as 620 authentication algorithm. Thus, the AUTH option content will have an 621 authentication tag of 16 bytes. 623 AUTH Option value = AES-CMAC-128(COAP_PSK, MSG, MSG_LENGTH) 625 where: 627 o COAP_PSK is the key derived in the CoAP Security Association 628 process. 630 o MSG is the CoAP message including AUTH option filled with zeros. 632 o MSG_LENGTH. Length of the CoAP message. 634 After applying AES-CMAC-128 function, the AUTH option value will be 635 set in the AUTH option replacing the zeros. 637 6. Implementation 639 At the time of writing this document, we have developed a proof-of- 640 concept based on libcoap ([libCoAP]) in PC platform and started the 641 development of a simulation with COOJA network simulator for Contiki 642 ([Contiki]). 644 So far, we have implemented an authentication tag by using AES-CMAC- 645 128. However this authentication tag has been included in the 646 payload of two final messages after sending the EAP Success. The 647 implementation of the AUTH option will come soon. Moreover, we have 648 used AES-CMAC-128 for COAP_PSK. Since this function does not allow a 649 key longer than 16 bytes, we have used the most significative 16 650 bytes of the MSK as input key. Since AES-CMAC-PRF-128 eliminates 651 this limitation, we will implement this version instead. 653 We are using (for the PC version) libeap in wpa-supplicant and 654 hostapd open source software ([hostapd]) to implement the EAP stack 655 and, in particular, the EAP-PSK method. 657 7. Future Work: CoAP Relay 659 Architecture explained in Figure 1 assumes that EAP peer can 660 communicate with the EAP authenticator. In certain scenarios, EAP 661 authenticator may not be reachable from the EAP peer if the EAP 662 authenticator is placed several hops-away. In this scenario, 663 described in Figure 6, we are considering the usage a new service 664 that assists the authentication. This service acts as a relay of 665 CoAP messages between the EAP peer and EAP authenticator. We have 666 called the entity in charge of performing this service CoAP relay. 667 The strategy is similar to the one described in PANA Relay 668 ([RFC6345]) or DTLS Relay ([I-D.kumar-dice-dtls-relay]). Unlike CoAP 669 proxy, the CoAP relay is not intended to keep any state (stateless 670 behaviour) and the EAP peer is not assumed to be aware of the 671 presence of the CoAP relay. In any case, this part needs further 672 investigation since CoAP already provides the concept of CoAP proxy 673 and, particular, CoAP-to-CoAP proxy that might be used instead. 675 +------------+ +------------+ +--------------+ 676 | EAP peer/ | | | | EAP auth | 677 | CoAP server|+------+| CoAP relay |+------+| CoaP client | 678 +------------+ CoAP +------------+ CoAP +--------------+ 679 | 680 AAA | 681 | 682 +--------------+ 683 | EAP server/ | 684 | AAA server | 685 +--------------+ 687 Figure 6: CoAP EAP Relay Architecture 689 Once the EAP peer has been authenticated, CoAP relay service should 690 not be needed anymore for this EAP peer. 692 Development of this new service may modify the "Unsafe to Forward" 693 flag of the AUTH option. 695 8. Use Case Scenario 697 In the following, we explain a basic example about the usage of CoAP- 698 EAP. There are 5 entities involved in the scenario: 700 o 2 nodes (A and B), which are constrained devices. 702 o 1 node D, which is considered a no so constrained device, such as 703 a phone, or a tablet or even a laptop. 705 o 1 controller (C). The controller manages a domain where nodes can 706 be deployed. It can be considered a more powerful machine than 707 the nodes, however it may have some constrained resources. 709 o 1 AAA server (AAA). The AAA is an Authentication, Authorization 710 and Accounting Server, which is not constrained. 712 Any node wanting to join the domain managed by the controller, must 713 perform and CoAP-EAP authentication with the controller C. This 714 authentication, as depicted in Figure 6, may involve an external AAA 715 server. This means that A and B, once deployed, will perform this 716 CoAP-EAP once as a bootstrapping phase to establish a security 717 association with the controller C. Moreover, any other entity (i.e. 718 node D) , which wants to join and establish communications with nodes 719 under the controller C's domain must also do the same. 721 One use case is the following. The node A wants to communicate with 722 node B (e.g. to active a light switch). The overall process is 723 divided in three phases. Let's start with node A. In the first 724 phase, the node A (EAP peer) does not yet belong to the controller 725 C's domain. Then, it communicates with controller C (EAP 726 authenticator) and authenticates with CoAP-EAP, which, in turn, 727 communicates with the AAA server to complete the authentication 728 process. If the authentication is successful, key material is 729 distributed to the controller C and derived by node A. This key 730 material allows node A to establish a security association with 731 controller C. Some authorization information may be also provided in 732 this step. If authentication and authorization are correct, node A 733 is enrolled in the controller C's domain during a period of time. In 734 particular, [RFC5247] recommends 8 hours, though the AAA server can 735 establish this lifetime. In the same manner, B needs to perform the 736 same process with CoAP-EAP to be part of the controller C's domain. 738 In the second phase, when node A wants to talk with node B, it 739 contacts the controller C for authorization to access node B and 740 obtain all the required information to do that in a secure manner 741 (e.g. keys, tokens, authorization information, etc.). It does not 742 require the usage of CoAP-EAP. The details of this phase are out of 743 scope of this document. 745 In the third phase, the node A can access node B with the credentials 746 and information obtained from the controller C in the second phase. 747 This access can be repeated without contacting the controller, while 748 the credentials given to A are still valid. The details of this 749 phase are out of scope of this document. 751 It is worth noting that first phase with CoAP-EAP is only required to 752 join the controller C's domain. Once it is performed with success, 753 the communications are local to the controller C's domain so there is 754 no need to contact the external AAA server. 756 Another use case is the following. Node D wants to communicate with 757 node A (e.g. to obtain a temperature measurement). To do that, first 758 of all, node D must join the controller C's domain. To do that it 759 performs a CoAP-EAP authentication and authorization with the 760 controller C (first phase). If everything ends with success, the 761 node D can request access to node A to C (second phase). Then if 762 node D is authorized can access to node A (third phase). So, in the 763 end, node D also implements CoAP-EAP as any other constrained node. 765 9. Acknowledgments 767 We would like to thank Pedro Moreno-Sanchez and Gabriel Lopez-Millan 768 for the first review of this document. Also, we would like to thank 769 Ivan Jimenez-Sanchez for the first proof-of-concept implementation of 770 this idea. 772 We also thank for their valuables comments to Alexander Pelov and 773 Laurent Toutain, specially for the potential optimizations of CoAP- 774 EAP. 776 This work has been partly funded by European Commission through the 777 FP7-SMARTIE-609062 EU Project. 779 10. Security Considerations 781 TBD. 783 11. IANA Considerations 785 This document has no actions for IANA. 787 12. References 789 12.1. Normative References 791 [I-D.kumar-dice-dtls-relay] 792 Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay 793 for Constrained Environments", draft-kumar-dice-dtls- 794 relay-02 (work in progress), October 2014. 796 [I-D.ohba-core-eap-based-bootstrapping] 797 Das, S. and Y. Ohba, "Provisioning Credentials for CoAP 798 Applications using EAP", draft-ohba-core-eap-based- 799 bootstrapping-01 (work in progress), March 2012. 801 [I-D.pelov-core-cosol] 802 Pelov, A., Toutain, L., and Y. Delibie, "Constrained 803 Signaling Over LP-WAN", draft-pelov-core-cosol-01 (work in 804 progress), February 2016. 806 [I-D.tcs-coap-no-response-option] 807 Bhattacharyya, A., Bandyopadhyay, S., Pal, A., and T. 808 Bose, "CoAP option for no server-response", draft-tcs- 809 coap-no-response-option-16 (work in progress), April 2016. 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, 813 DOI 10.17487/RFC2119, March 1997, 814 . 816 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 817 Levkowetz, Ed., "Extensible Authentication Protocol 818 (EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, 819 . 821 [RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., "Pre-Shared Key 822 Ciphersuites for Transport Layer Security (TLS)", 823 RFC 4279, DOI 10.17487/RFC4279, December 2005, 824 . 826 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 827 AES-CMAC Algorithm", RFC 4493, DOI 10.17487/RFC4493, June 828 2006, . 830 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 831 Advanced Encryption Standard-Cipher-based Message 832 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 833 PRF-128) Algorithm for the Internet Key Exchange Protocol 834 (IKE)", RFC 4615, DOI 10.17487/RFC4615, August 2006, 835 . 837 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 838 Pre-Shared Key Extensible Authentication Protocol (EAP) 839 Method", RFC 4764, DOI 10.17487/RFC4764, January 2007, 840 . 842 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 843 Authentication Protocol (EAP) Key Management Framework", 844 RFC 5247, DOI 10.17487/RFC5247, August 2008, 845 . 847 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 848 "Specification for the Derivation of Root Keys from an 849 Extended Master Session Key (EMSK)", RFC 5295, 850 DOI 10.17487/RFC5295, August 2008, 851 . 853 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., Ed., and 854 A. Yegin, "Protocol for Carrying Authentication for 855 Network Access (PANA) Relay Element", RFC 6345, 856 DOI 10.17487/RFC6345, August 2011, 857 . 859 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 860 Application Protocol (CoAP)", RFC 7252, 861 DOI 10.17487/RFC7252, June 2014, 862 . 864 12.2. Informative References 866 [Contiki] "Contiki: The Open Source OS for the Internet of Things", 867 March 2014. 869 [hostapd] "hostapd: IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS 870 Authenticator", March 2014. 872 [libCoAP] "C-Implementation of CoAP", January 2013. 874 Authors' Addresses 876 Rafa Marin-Lopez 877 University of Murcia 878 Campus de Espinardo S/N, Faculty of Computer Science 879 Murcia 30100 880 Spain 882 Phone: +34 868 88 85 01 883 Email: rafa@um.es 885 Dan Garcia Carrillo 886 University of Murcia 887 Campus de Espinardo S/N, Faculty of Computer Science 888 Murcia 30100 889 Spain 891 Phone: +34 868 88 78 82 892 Email: dan.garcia@um.es