idnits 2.17.1 draft-marin-ace-wg-coap-eap-01.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 4 instances of too long lines in the document, the longest one being 1 character 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 8, 2014) is 3481 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '0x6af5' is mentioned on line 327, but not defined == Missing Reference: '0xFA5B45FF4723BB43' is mentioned on line 322, but not defined == Missing Reference: '0x73DE' is mentioned on line 338, but not defined == Missing Reference: '0x7654' is mentioned on line 350, but not defined == Missing Reference: '0x9869' is mentioned on line 362, but not defined == Missing Reference: '0x7811' is mentioned on line 381, but not defined == Missing Reference: '0x7511' is mentioned on line 394, but not defined == Missing Reference: '0x7600' is mentioned on line 402, but not defined == Missing Reference: '0x7500' is mentioned on line 407, but not defined == Outdated reference: A later version (-02) exists of draft-kumar-dice-dtls-relay-00 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group R. Sanchez 3 Internet-Draft R. Marin 4 Intended status: Experimental D. Garcia 5 Expires: April 11, 2015 University of Murcia 6 October 8, 2014 8 EAP-based Authentication Service for CoAP 9 draft-marin-ace-wg-coap-eap-01 11 Abstract 13 This document describes an authentication service that uses EAP 14 transported by means of CoAP messages with two purposes: 16 o Authenticate two CoAP endpoints. 18 o Bootstrap key material to protect CoAP messages exchanged between 19 them. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 11, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. General Architecture . . . . . . . . . . . . . . . . . . . . 3 58 3. General Flow Operation . . . . . . . . . . . . . . . . . . . 3 59 3.1. EAP in CoAP with AUTH option . . . . . . . . . . . . . . 4 60 3.2. EAP in CoAP with DTLS . . . . . . . . . . . . . . . . . . 7 61 4. Key Derivation for protecting CoAP messages . . . . . . . . . 9 62 4.1. Deriving COAP_AUTH_KEY . . . . . . . . . . . . . . . . . 10 63 4.2. Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . . 10 64 5. Generating AUTH option . . . . . . . . . . . . . . . . . . . 11 65 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 12 66 7. Future Work: CoAP Relay . . . . . . . . . . . . . . . . . . . 13 67 8. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 13 68 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 69 10. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 71 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 12.1. Normative References . . . . . . . . . . . . . . . . . . 15 73 12.2. Informative References . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 76 1. Introduction 78 The goal of this document is to describe an authentication service 79 that uses the Extensible Authentication Protocol (EAP) [RFC3748]. 80 The authentication service is built on top of the Constrained 81 Application Protocol (CoAP) [I-D.ietf-core-coap] and allows 82 authenticating two CoAP endpoints by using EAP without the need of 83 additional protocols to bootstrap a security association between 84 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 Confirmable "GET 154 /auth" request to the node (Step 0). If the EAP authenticator 155 implements the authentication service will return a 2.05 in a 156 Acknowledgment with a piggy-backed response (Step 0'). Immediately 157 after that, the EAP authenticator will start the authentication 158 service. It is worth noting that the EAP authenticator may decide to 159 start the authentication without waiting for a "GET /auth" message. 161 In any case, to perform the authentication service, the CoAP client 162 (EAP authenticator) sends a Confirmable "POST /auth" request to the 163 CoAP Server (Step 1). POST message indicates to the CoAP server the 164 creation of a resource for the EAP-based authentication service. The 165 CoAP server assigns a resource and answers with an Acknowledgment 166 with the piggy-backed resource identifier (Uri-Path) (Step 2). It is 167 assumed that the CoAP server will only have an ongoing authentication 168 and will not process simultaneous EAP authentications in parallel to 169 save resources. Moreover if after a period of time (TBD) no further 170 message is received from the CoAP client, the CoAP server will free 171 the created state. In this moment, the CoAP server has started a 172 resource for the EAP authentication, whose resource identifier value 173 will be used together with the Token option value to relate all the 174 EAP conversation between both CoAP endpoints. 176 From now on, the EAP authenticator and the EAP peer will exchange EAP 177 packets transported in the CoAP message payload (Steps 3,4,5,6,7). 178 The EAP authenticator will use PUT method to send EAP requests to the 179 EAP peer. The EAP peer will use a Piggy-backed response in the 180 Acknowledgement message to carry the EAP response. At the end of the 181 message exchanges, if everything has gone well, the EAP authenticator 182 is able to send an EAP Success message and both CoAP endpoints will 183 share a Master Session Key (MSK) ([RFC5295]) 185 If the new defined AUTH option is used, an authentication tag is 186 generated with a new key named COAP_AUTH_KEY, derived from the MSK. 187 The Acknowledgment message from the CoAP server will also include an 188 AUTH option so that the CoAP client can verify that the CoAP server 189 obtained the MSK. This is shown in Steps 7 and 8. From that point 190 any exchange (for example, Steps 9 and 10) between both CoAP 191 endpoints are protected with the AUTH option. Finally, the CoAP 192 client MAY send a Confirmable DELETE request to remove all the state 193 related with the authentication service in the CoAP server (Steps 11 194 and 12). The CoAP server may decide to remove the state after period 195 of time in case not receiving a DELETE request. This may be easier 196 if the EAP authenticator sends a session lifetime option (TBD) in the 197 Step 7 (where the EAP Success is sent). 199 On the contrary, if DTLS is used (see Figure 3), a DTLS_PSK is 200 derived from the MSK. Moreover, exchanges between both CoAP 201 endpoints are protected with DTLS from that point. 203 EAP peer EAP Auth. 204 (COAP server) (COAP client) 205 ------------- ------------- 206 | | 207 | CON [0x6af5] | 208 0) | Token [0xFA5B45FF4723BB43] | 209 | GET /auth | 210 |---------------------------------------->| 211 | | 212 | | 213 | ACK 2.05 [0x6af5] | 214 | (Token 0xFA5B45FF4723BB43) | 215 0') | Payload ["OK"]| 216 |<----------------------------------------| 217 | | 218 | | 219 | CON [0x73DE] | 220 | (Token 0x78728FD4AC3190FF) | 221 | POST /auth | 222 1) |<----------------------------------------| 223 | | 224 | ACK [0x73DE] | 225 | (Token 0x78728FD4AC3190FF) | 226 | 2.01 Created | 227 | Uri-Path [auth/5] | 228 2) |---------------------------------------->| 229 | | 230 | CON [0x7654] | 231 | (Token 0x78728FD4AC3190FF) | 232 | Payload EAP-PSK MSG 1 | 233 | PUT /auth/5 | 234 3) |<----------------------------------------| 235 | | 236 | ACK [0x7654] | 237 | (Token 0x78728FD4AC3190FF) | 238 | 2.04 Changed | 239 | Payload EAP-PSK MSG 2 | 240 4) |---------------------------------------->| 241 | | 242 | CON [0x9869] | 243 | (Token 0x78728FD4AC3190FF) | 244 | Payload EAP-PSK MSG 3 | 245 | PUT /auth/5 | 246 5) |<----------------------------------------| 247 | | 248 | ACK [0x9869] | 249 | (Token 0x78728FD4AC3190FF) | 250 | 2.04 Changed | 251 | Payload EAP-PSK MSG 4 | 252 6) |---------------------------------------->| 253 MSK | | MSK 254 | | CON [0x7811] | | 255 COAP_AUTH_KEY (Token 0x78728FD4AC3190FF) |COAP_AUTH_KEY 256 | AUTH option | 257 | Payload EAP Success | (*) 258 | PUT /auth/5 | 259 7) |<----------------------------------------| 260 | | 261 (*) | ACK [0x7811] | 262 | (Token 0x78728FD4AC3190FF) | 263 | AUTH option | 264 | 2.04 Changed | 265 8) |---------------------------------------->| 267 ............. 269 | | 270 | CON [0x7511] | 271 | (Token 0x55566AF7464646BC) | (*) 272 | AUTH option | 273 | GET /temp | 274 9) |<----------------------------------------| 275 | | 276 | ACK [0x7511] | 277 (*) | (Token 0x55566AF7464646BC) | 278 | AUTH option | 279 | 2.05 Content | 280 | "22.5C" | 281 10) |---------------------------------------->| 282 ................ 284 | | 285 | CON [0x7600] | 286 | (Token 0x678443AA678BC690) | (*) 287 | AUTH option | 288 | DELETE /auth/5 | 289 11) |<----------------------------------------| 290 | | 291 | ACK [0x7500] | 292 (*) | (Token 0x678443AA678BC690) | 293 | AUTH option | 294 | 2.02 Deleted | 295 12) |---------------------------------------->| 297 (*) Protected with AUTH option 299 Figure 2: EAP over CoAP with AUTH option 301 3.2. EAP in CoAP with DTLS 303 Other possibility at our disposal is to do a DTLS handshake after the 304 MSKs generation and continue the communication between endpoints 305 using CoAP through DTLS as we can see at Figure 3. The Steps 0-6 are 306 the same as the case with AUTH option, however, before continuing 307 with Steps 7 and 8, the EAP authenticator starts the DTLS handshake 308 with the EAP peer (Step 7'). To establish a DTLS Security 309 Association, a key named DTLS-PSK is derived from MSK (see Section 4 310 ). In this case the CoAP client can start DTLS before sending the 311 last message containing the EAP Success. Once DTLS is established, 312 any posterior CoAP exchange is protected. Thus, new AUTH option is 313 not needed. A successful DTLS negotiation confirms the possession of 314 DTLS_PSK that, in turn, corroborates that both entities participated 315 in the EAP authentication. 317 EAP peer EAP Auth. 318 (COAP server) (COAP client) 319 ------------- ------------- 320 | | 321 | CON [0x6af5] | 322 0) | Token [0xFA5B45FF4723BB43] | 323 | GET /auth | 324 |---------------------------------------->| 325 | | 326 | | 327 | ACK 2.05 [0x6af5] | 328 | (Token 0xFA5B45FF4723BB43) | 330 0') | Payload ["OK"]| 331 |<----------------------------------------| 332 | | 333 | CON [0x73DE] | 334 | (Token 0x78728FD4AC3190FF) | 335 | POST /auth | 336 1) |<----------------------------------------| 337 | | 338 | ACK [0x73DE] | 339 | (Token 0x78728FD4AC3190FF) | 340 | 2.01 Created | 341 | Uri-Path [auth/5] | 342 2) |---------------------------------------->| 343 | | 344 | CON [0x7654] | 345 | (Token 0x78728FD4AC3190FF) | 346 | Payload EAP-PSK MSG 1 | 347 | PUT /auth/5 | 348 3) |<----------------------------------------| 349 | | 350 | ACK [0x7654] | 351 | (Token 0x78728FD4AC3190FF) | 352 | 2.04 Changed | 353 | Payload EAP-PSK MSG 2 | 354 4) |---------------------------------------->| 355 | | 356 | CON [0x9869] | 357 | (Token 0x78728FD4AC3190FF) | 358 | Payload EAP-PSK MSG 3 | 359 | PUT /auth/5 | 360 5) |<----------------------------------------| 361 | | 362 | ACK [0x9869] | 363 | (Token 0x78728FD4AC3190FF) | 364 | 2.04 Changed | 365 | Payload EAP-PSK MSG 4 | 366 6) |---------------------------------------->| 367 MSK | | MSK 368 | | | | 369 DTLS_PSK| | DTLS_PSK 370 | | 371 | DTLS HANDSHAKE | 372 | (Initiated by EAP Auth.) | 373 7') |<--------------------------------------->| 374 | | 375 | CON [0x7811] | 376 | (Token 0x78728FD4AC3190FF) | 377 | Payload EAP Success | (*) 378 | PUT /auth/5 | 379 7) |<----------------------------------------| 380 | | 381 | ACK [0x7811] | 382 (*) | (Token 0x78728FD4AC3190FF) | 383 | 2.04 Changed | 384 8) |---------------------------------------->| 386 ............. 388 | | 389 | CON [0x7511] | 390 | (Token 0xAA763D82F623B7FF) | (*) 391 | GET /temp | 392 9) |<----------------------------------------| 393 | | 394 | ACK [0x7511] | 395 (*) | (Token 0xAA763D82F623B7FF) | 396 | 2.05 Content | 397 | "22.5C" | 398 10) |---------------------------------------->| 399 ................ 401 | | 402 | CON [0x7600] | 403 | (Token 0x678443AA678BC690) | (*) 404 | DELETE /auth/5 | 405 11) |<----------------------------------------| 406 | | 407 | ACK [0x7500] | 408 (*) | (Token 0x678443AA678BC690) | 409 | 2.02 Deleted | 410 12) |---------------------------------------->| 412 (*) Protected with DTLS 414 Figure 3: EAP over CoAP with DTLS 416 4. Key Derivation for protecting CoAP messages 418 As a result of a successful EAP authentication, both CoAP server and 419 CoAP client share a Master Key Session (MSK). The assumption is that 420 MSK is a fresh key so any derived key from the MSK will be also 421 fresh. We have considered the derivation of either COAP_AUTH_KEY or 422 DTLS_PSK. 424 4.1. Deriving COAP_AUTH_KEY 426 A key COAP_AUTH_KEY is derived from the MSK to generate the 427 authentication tag included in the AUTH option. COAP_AUTH_KEY is 428 derived by using AES-CMAC-PRF-128 [RFC4615], which, in turn, uses 429 AES-CMAC-128 [RFC4493]. In this case, rest of CoAP exchanges between 430 both entities can be protected with integrity (NOTE: encryption will 431 be considered in the future) with AUTH option without the need of 432 using DTLS. Thus, all CoAP messages MUST include AUTH option from 433 that point. (NOTE: We understand that this would not be the standard 434 way of protecting CoAP but instead a new way of protecting CoAP 435 messages). 437 COAP_AUTH_KEY is a 16-byte length key which is computed in the 438 following way: 440 COAP_AUTH_KEY = AES-CMAC-PRF-128(MSK, "IETF COAP AUTH" || Token 441 Option value, 64, length("IETF COAP AUTH" || Token Option value)) 443 where: 445 o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses 446 AES-CMAC-128 as building block. 448 o The MSK exported by the EAP method. 450 o "IETF COAP AUTH" is the ASCII code representation of the non-NULL 451 terminated string (excluding the double quotes around it). This 452 value is concatenated with the value of the Token Option value. 454 o 64 is the length of the MSK. 456 o length("IETF COAP AUTH" || Token Option value) is the length of 457 the label "IETF COAP AUTH" (14 bytes) plus the Token Option value. 459 4.2. Deriving DTLS_PSK 461 In the second alternative, a DTLS_PSK is derived from the MSK between 462 both CoAP endpoints. So far, DTLS_PSK will have also 16 byte length 463 and it will derived as follows: 465 DTLS_PSK = AES-CMAC-PRF-128(MSK, "IETF COAP DTLS" || Token Option 466 value, 64, length("IETF COAP DTLS" || Token Option value)). This 467 value is concatenated with the value of the Token Option value. 469 where: 471 o MSK is exported by the EAP method. 473 o "IETF COAP DTLS" is the ASCII code representation of the non-NULL 474 terminated string (excluding the double quotes around it). 476 o 64 is the length of the MSK. 478 o length("IETF COAP DTLS" || Token Option value) is the length of 479 the label "IETF COAP DTLS" (14 bytes) plus the Token Option Value. 481 As mentioned in [RFC4279], a PSK identity is needed. We are 482 considering the usage of the Token Option value chosen during the EAP 483 authentication as identity. In any case, this still needs further 484 investigation. 486 5. Generating AUTH option 488 A new AUTH option is defined in this document for authentication 489 purposes. Following guidelines in [I-D.ietf-core-coap] this option 490 is: 492 1. Format opaque (sequence of bytes). 494 2. Elective. 496 3. Unsafe to Forward. 498 4. No cacheable. 500 The number of the option will be determined by this previous 501 decisions. 503 1. Elective (C = 0) 505 2. Unsafe to Forward (0) 507 3. NoCacheKey (111) 509 The number of the AUTH option will fit this pattern: xxx11100 511 0 1 2 3 4 5 6 7 512 +---+---+---+---+---+---+---+---+ 513 | | NoCacheKey| U | C | 514 +---+---+---+---+---+---+---+---+ 516 Figure 4: Auth Option Number Mask 518 First available option number is 01011100 (92). 520 The resultant AUTH option is: 522 +-----+----+---+---+---+-----------+--------+--------+---------+ 523 | No. | C | U | N | R | Name | Format | Length | Default | 524 +-----+----+---+---+---+-----------+--------+--------+---------+ 525 | 92 | | | x | | AUTH | opaque | 128 | (none) | 526 +-----+----+---+---+---+-----------+--------+--------+---------+ 528 Figure 5: AUTH Option 530 C, U, N and R columns indicate the properties, Critical, UnSafe, 531 NoCacheKey and Repeatable, respectively. 533 To generate the value of the AUTH option, we use AES-CMAC-128 as 534 authentication algorithm. Thus, the AUTH option content will have an 535 authentication tag of 16 bytes. 537 AUTH Option value = AES-CMAC-128(COAP_AUTH_KEY, MSG, MSG_LENGTH) 539 where: 541 o COAP_AUTH_KEY is the key derived in the CoAP Security Association 542 process. 544 o MSG is the CoAP message including AUTH option filled with zeros. 546 o MSG_LENGTH. Length of the CoAP message. 548 After applying AES-CMAC-128 function, the AUTH option value will be 549 set in the AUTH option replacing the zeros. 551 6. Implementation 553 At the time of writing this document, we have developed a proof-of- 554 concept based on libcoap ([libCoAP]) in PC platform and started the 555 development of a simulation with COOJA network simulator for Contiki 556 ([Contiki]). 558 So far, we have implemented an authentication tag by using AES-CMAC- 559 128. However this authentication tag has been included in the 560 payload of two final messages after sending the EAP Success. The 561 implementation of the AUTH option will come soon. Moreover, we have 562 used AES-CMAC-128 for COAP_AUTH_KEY. Since this function does not 563 allow a key longer than 16 bytes, we have used the most significative 564 16 bytes of the MSK as input key. Since AES-CMAC-PRF-128 eliminates 565 this limitation, we will implement this version instead. 567 We are using (for the PC version) libeap in wpa-supplicant and 568 hostapd open source software ([hostapd]) to implement the EAP stack 569 and, in particular, the EAP-PSK method. 571 7. Future Work: CoAP Relay 573 Architecture explained in Figure 1 assumes that EAP peer can 574 communicate with the EAP authenticator. In certain scenarios, EAP 575 authenticator may not be reachable from the EAP peer if the EAP 576 authenticator is placed several hops-away. In this scenario, 577 described in Figure 6, we are considering the usage a new service 578 that assists the authentication. This service acts as a relay of 579 CoAP messages between the EAP peer and EAP authenticator. We have 580 called the entity in charge of performing this service CoAP relay. 581 The strategy is similar to the one described in PANA Relay 582 ([RFC6345]) or DTLS Relay ([I-D.kumar-dice-dtls-relay]). Unlike CoAP 583 proxy, the CoAP relay is not intended to keep any state (stateless 584 behaviour) and the EAP peer is not assumed to be aware of the 585 presence of the CoAP relay. In any case, this part needs further 586 investigation since CoAP already provides the concept of CoAP proxy 587 and, particular, CoAP-to-CoAP proxy that might be used instead. 589 +------------+ +------------+ +--------------+ 590 | EAP peer/ | | | | EAP auth | 591 | CoAP server|+------+| CoAP relay |+------+| CoaP client | 592 +------------+ CoAP +------------+ CoAP +--------------+ 593 | 594 AAA | 595 | 596 +--------------+ 597 | EAP server/ | 598 | AAA server | 599 +--------------+ 601 Figure 6: CoAP EAP Relay Architecture 603 Once the EAP peer has been authenticated, CoAP relay service should 604 not be needed anymore for this EAP peer. 606 Development of this new service may modify the "Unsafe to Forward" 607 flag of the AUTH option. 609 8. Use Case Scenario 611 In the following, we explain a basic example about the usage of CoAP- 612 EAP. There are 5 entities involved in the scenario: 614 o 2 nodes (A and B), which are constrained devices. 616 o 1 node D, which is considered a no so constrained device, such as 617 a phone, or a tablet or even a laptop. 619 o 1 controller (C). The controller manages a domain where nodes can 620 be deployed. It can be considered a more powerful machine than 621 the nodes, however it may have some constrained resources. 623 o 1 AAA server (AAA). The AAA is an Authentication, Authorization 624 and Accounting Server, which is not constrained. 626 Any node wanting to join the domain managed by the controller, must 627 perform and CoAP-EAP authentication with the controller C. This 628 authentication, as depicted in Figure 6, may involve an external AAA 629 server. This means that A and B, once deployed, will perform this 630 CoAP-EAP once as a bootstrapping phase to establish a security 631 association with the controller C. Moreover, any other entity (i.e. 632 node D) , which wants to join and establish communications with nodes 633 under the controller C's domain must also do the same. 635 One use case is the following. The node A wants to communicate with 636 node B (e.g. to active a light switch). The overall process is 637 divided in three phases. Let's start with node A. In the first 638 phase, the node A (EAP peer) does not yet belong to the controller 639 C's domain. Then, it communicates with controller C (EAP 640 authenticator) and authenticates with CoAP-EAP, which, in turn, 641 communicates with the AAA server to complete the authentication 642 process. If the authentication is successful, key material is 643 distributed to the controller C and derived by node A. This key 644 material allows node A to establish a security association with 645 controller C. Some authorization information may be also provided in 646 this step. If authentication and authorization are correct, node A 647 is enrolled in the controller C's domain during a period of time. In 648 particular, [RFC5247] recommends 8 hours, though the AAA server can 649 establish this lifetime. In the same manner, B needs to perform the 650 same process with CoAP-EAP to be part of the controller C's domain. 652 In the second phase, when node A wants to talk with node B, it 653 contacts the controller C for authorization to access node B and 654 obtain all the required information to do that in a secure manner 655 (e.g. keys, tokens, authorization information, etc.). It does not 656 require the usage of CoAP-EAP. The details of this phase are out of 657 scope of this document. 659 In the third phase, the node A can access node B with the credentials 660 and information obtained from the controller C in the second phase. 661 This access can be repeated without contacting the controller, while 662 the credentials given to A are still valid. The details of this 663 phase are out of scope of this document. 665 It is worth noting that first phase with CoAP-EAP is only required to 666 join the controller C's domain. Once it is performed with success, 667 the communications are local to the controller C's domain so there is 668 no need to contact the external AAA server. 670 Another use case is the following. Node D wants to communicate with 671 node A (e.g. to obtain a temperature measurement). To do that, first 672 of all, node D must join the controller C's domain. To do that it 673 performs a CoAP-EAP authentication and authorization with the 674 controller C (first phase). If everything ends with success, the 675 node D can request access to node A to C (second phase). Then if 676 node D is authorized can access to node A (third phase). So, in the 677 end, node D also implements CoAP-EAP as any other constrained node. 679 9. Acknowledgments 681 We would like to thank Pedro Moreno-Sanchez and Gabriel Lopez-Millan 682 for the first review of this document. Also, we would like to thank 683 Ivan Jimenez-Sanchez for the first proof-of-concept implementation of 684 this idea. 686 This work has been partly funded by European Commission through the 687 FP7- SMARTIE-609062 EU Project. 689 10. Security Considerations 691 TBD. 693 11. IANA Considerations 695 This document has no actions for IANA. 697 12. References 699 12.1. Normative References 701 [I-D.ietf-core-coap] 702 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 703 Application Protocol (CoAP)", draft-ietf-core-coap-18 704 (work in progress), June 2013. 706 [I-D.kumar-dice-dtls-relay] 707 Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay 708 for Constrained Environments", draft-kumar-dice-dtls- 709 relay-00 (work in progress), October 2013. 711 [I-D.ohba-core-eap-based-bootstrapping] 712 Das, S. and Y. Ohba, "Provisioning Credentials for CoAP 713 Applications using EAP", draft-ohba-core-eap-based- 714 bootstrapping-01 (work in progress), March 2012. 716 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 717 Requirement Levels", BCP 14, RFC 2119, March 1997. 719 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 720 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 721 3748, June 2004. 723 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 724 for Transport Layer Security (TLS)", RFC 4279, December 725 2005. 727 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 728 AES-CMAC Algorithm", RFC 4493, June 2006. 730 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 731 Advanced Encryption Standard-Cipher-based Message 732 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 733 PRF-128) Algorithm for the Internet Key Exchange Protocol 734 (IKE)", RFC 4615, August 2006. 736 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 737 Pre-Shared Key Extensible Authentication Protocol (EAP) 738 Method", RFC 4764, January 2007. 740 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 741 Authentication Protocol (EAP) Key Management Framework", 742 RFC 5247, August 2008. 744 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 745 "Specification for the Derivation of Root Keys from an 746 Extended Master Session Key (EMSK)", RFC 5295, August 747 2008. 749 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 750 Yegin, "Protocol for Carrying Authentication for Network 751 Access (PANA) Relay Element", RFC 6345, August 2011. 753 12.2. Informative References 755 [Contiki] "Contiki: The Open Source OS for the Internet of Things", 756 March 2014. 758 [hostapd] "hostapd: IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS 759 Authenticator", March 2014. 761 [libCoAP] "C-Implementation of CoAP", January 2013. 763 Authors' Addresses 765 Raul Sanchez-Sanchez 766 University of Murcia 767 Campus de Espinardo S/N, Faculty of Computer Science 768 Murcia 30100 769 Spain 771 Phone: +34 868 88 92 81 772 Email: raul@um.es 774 Rafa Marin-Lopez 775 University of Murcia 776 Campus de Espinardo S/N, Faculty of Computer Science 777 Murcia 30100 778 Spain 780 Phone: +34 868 88 85 01 781 Email: rafa@um.es 783 Dan Garcia Carrillo 784 University of Murcia 785 Campus de Espinardo S/N, Faculty of Computer Science 786 Murcia 30100 787 Spain 789 Phone: +34 868 88 87 71 790 Email: dan.garcia@um.es