idnits 2.17.1 draft-marin-ace-wg-coap-eap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (April 9, 2014) is 3670 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: '0x6af5' is mentioned on line 325, but not defined == Missing Reference: '0xFA5B45FF4723BB43' is mentioned on line 320, but not defined == Missing Reference: '0x73DE' is mentioned on line 336, but not defined == Missing Reference: '0x7654' is mentioned on line 348, but not defined == Missing Reference: '0x9869' is mentioned on line 360, but not defined == Missing Reference: '0x7811' is mentioned on line 379, but not defined == Missing Reference: '0x7511' is mentioned on line 392, but not defined == Missing Reference: '0x7600' is mentioned on line 400, but not defined == Missing Reference: '0x7500' is mentioned on line 405, 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 University of Murcia 5 Expires: October 11, 2014 April 9, 2014 7 EAP-based Authentication Service for CoAP 8 draft-marin-ace-wg-coap-eap-00 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 11, 2014. 37 Copyright Notice 39 Copyright (c) 2014 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. EAP in CoAP with DTLS . . . . . . . . . . . . . . . . . . 7 60 4. Key Derivation for protecting CoAP messages . . . . . . . . . 9 61 4.1. Deriving COAP_AUTH_KEY . . . . . . . . . . . . . . . . . 10 62 4.2. Deriving DTLS_PSK . . . . . . . . . . . . . . . . . . . . 10 63 5. Generating AUTH option . . . . . . . . . . . . . . . . . . . 11 64 6. Implementation . . . . . . . . . . . . . . . . . . . . . . . 12 65 7. Future Work: CoAP Relay . . . . . . . . . . . . . . . . . . . 13 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 71 11.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 74 1. Introduction 76 The goal of this document is to describe an authentication service 77 that uses the Extensible Authentication Protocol (EAP) [RFC3748]. 78 The authentication service is built on top of the Constrained 79 Application Protocol (CoAP) [I-D.ietf-core-coap] and allows 80 authenticating two CoAP endpoints by using EAP without the need of 81 additional protocols to bootstrap a security association between 82 them. 84 In particular, the document describes how CoAP can be used as EAP 85 lower-layer [RFC3748] to transport EAP between a CoAP server (EAP 86 peer) and the CoAP client (EAP authenticator) using CoAP messages. 87 The CoAP client may contact with a backend AAA infrastructure to 88 complete the EAP negotiation as described in the EAP specification 89 [RFC3748]. 91 The assumption is that the EAP method transported in CoAP MUST 92 generate cryptographic material [RFC5247] . In this way, the CoAP 93 messages can be protected. There are two approaches that we have 94 considered in this document: 96 o To define a new AUTH option that includes an authentication tag 97 generated with the cryptographic material exported during an EAP 98 authentication. This new option is used to protect the integrity 99 of the CoAP message that carries the AUTH option. (NOTE: 100 Encryption will be considered in the future). 102 o To establish a DTLS security association using the exported 103 cryptographic material after a successful EAP authentication. 104 [I-D.ohba-core-eap-based-bootstrapping] 106 This document also provides some comments about implementation of a 107 proof-of-concept of this preliminary idea 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. General Architecture 117 The Figure 1 shows the architecture defined in this document. 118 Basically a node acting as the EAP peer wants to be authenticated by 119 using EAP. At the time of writing this document, we have considered 120 a model where the EAP peer will act as CoAP server for this service 121 and the EAP authenticator will act as CoAP client and may interact 122 with a backend AAA infrastructure. Nevertheless, a model where the 123 EAP peer act as CoAP client and the EAP authenticator as CoAP server 124 will be also analyzed in the future. 126 +------------+ +------------+ +--------------+ 127 | EAP peer/ | | EAP auth./ | | EAP server/ | 128 | CoAP server|+------+| CoAP client|+-----+| AAA server | 129 +------------+ CoAP +------------+ AAA +--------------+ 131 Figure 1: CoAP EAP Architecture 133 3. General Flow Operation 135 The authentication service uses the CoAP protocol as transport layer 136 for EAP. CoAP becomes an EAP lower-layer (in EAP terminology). In 137 general, it is assumed that, since the EAP authenticator may need to 138 implement an AAA client to interact with the AAA infrastructure, this 139 endpoint will have more resources. We describe two different 140 sequence flow. First, it is shown in Figure 2 where the AUTH option 141 is used at the end of EAP authentication. Second diagram (see 142 Figure 3) shows the flow when DTLS is used to protect CoAP messages 143 at the end of the EAP authentication. As an example, both diagrams 144 show the usage of the EAP-PSK method [RFC4764] as authentication 145 mechanism. (NOTE: any EAP method which is able to export 146 cryptographic material should be valid). 148 3.1. EAP in CoAP with AUTH option 150 If the EAP peer discovers the presence of the EAP authenticator and 151 wants to start the authentication, it can send a Confirmable "GET / 152 auth" request to the node (Step 0). If the EAP authenticator 153 implements the authentication service will return a 2.05 in a 154 Acknowledgment with a piggy-backed response (Step 0'). Immediately 155 after that, the EAP authenticator will start the authentication 156 service. It is worth noting that the EAP authenticator may decide to 157 start the authentication without waiting for a "GET /auth" message. 159 In any case, to perform the authentication service, the CoAP client 160 (EAP authenticator) sends a Confirmable "POST /auth" request to the 161 CoAP Server (Step 1). POST message indicates to the CoAP server the 162 creation of a resource for the EAP-based authentication service. The 163 CoAP server assigns a resource and answers with an Acknowledgment 164 with the piggy-backed resource identifier (Uri-Path) (Step 2). It is 165 assumed that the CoAP server will only have an ongoing authentication 166 and will not process simultaneous EAP authentications in parallel to 167 save resources. Moreover if after a period of time (TBD) no further 168 message is received from the CoAP client, the CoAP server will free 169 the created state. In this moment, the CoAP server has started a 170 resource for the EAP authentication, whose resource identifier value 171 will be used together with the Token option value to relate all the 172 EAP conversation between both CoAP endpoints. 174 From now on, the EAP authenticator and the EAP peer will exchange EAP 175 packets transported in the CoAP message payload (Steps 3,4,5,6,7). 176 The EAP authenticator will use PUT method to send EAP requests to the 177 EAP peer. The EAP peer will use a Piggy-backed response in the 178 Acknowledgement message to carry the EAP response. At the end of the 179 message exchanges, if everything has gone well, the EAP authenticator 180 is able to send an EAP Success message and both CoAP endpoints will 181 share a Master Session Key (MSK) ([RFC5295]) 183 If the new defined AUTH option is used, an authentication tag is 184 generated with a new key named COAP_AUTH_KEY, derived from the MSK. 185 The Acknowledgment message from the CoAP server will also include an 186 AUTH option so that the CoAP client can verify that the CoAP server 187 obtained the MSK. This is shown in Steps 7 and 8. From that point 188 any exchange (for example, Steps 9 and 10) between both CoAP 189 endpoints are protected with the AUTH option. Finally, the CoAP 190 client MAY send a Confirmable DELETE request to remove all the state 191 related with the authentication service in the CoAP server (Steps 11 192 and 12). The CoAP server may decide to remove the state after period 193 of time in case not receiving a DELETE request. This may be easier 194 if the EAP authenticator sends a session lifetime option (TBD) in the 195 Step 7 (where the EAP Success is sent). 197 On the contrary, if DTLS is used (see Figure 3), a DTLS_PSK is 198 derived from the MSK. Moreover, exchanges between both CoAP 199 endpoints are protected with DTLS from that point. 201 EAP peer EAP Auth. 202 (COAP server) (COAP client) 203 ------------- ------------- 204 | | 205 | CON [0x6af5] | 206 0) | Token [0xFA5B45FF4723BB43] | 207 | GET /auth | 208 |---------------------------------------->| 209 | | 210 | | 211 | ACK 2.05 [0x6af5] | 212 | (Token 0xFA5B45FF4723BB43) | 213 0') | Payload ["OK"]| 214 |<----------------------------------------| 215 | | 216 | | 217 | CON [0x73DE] | 218 | (Token 0x78728FD4AC3190FF) | 219 | POST /auth | 220 1) |<----------------------------------------| 221 | | 222 | ACK [0x73DE] | 223 | (Token 0x78728FD4AC3190FF) | 224 | 2.01 Created | 225 | Uri-Path [auth/5] | 226 2) |---------------------------------------->| 227 | | 228 | CON [0x7654] | 229 | (Token 0x78728FD4AC3190FF) | 230 | Payload EAP-PSK MSG 1 | 231 | PUT /auth/5 | 232 3) |<----------------------------------------| 233 | | 234 | ACK [0x7654] | 235 | (Token 0x78728FD4AC3190FF) | 236 | 2.04 Changed | 237 | Payload EAP-PSK MSG 2 | 238 4) |---------------------------------------->| 239 | | 240 | CON [0x9869] | 241 | (Token 0x78728FD4AC3190FF) | 242 | Payload EAP-PSK MSG 3 | 243 | PUT /auth/5 | 244 5) |<----------------------------------------| 245 | | 246 | ACK [0x9869] | 247 | (Token 0x78728FD4AC3190FF) | 248 | 2.04 Changed | 249 | Payload EAP-PSK MSG 4 | 250 6) |---------------------------------------->| 251 MSK | | MSK 252 | | CON [0x7811] | | 253 COAP_AUTH_KEY (Token 0x78728FD4AC3190FF) |COAP_AUTH_KEY 254 | AUTH option | 255 | Payload EAP Success | (*) 256 | PUT /auth/5 | 257 7) |<----------------------------------------| 258 | | 259 (*) | ACK [0x7811] | 260 | (Token 0x78728FD4AC3190FF) | 261 | AUTH option | 262 | 2.04 Changed | 263 8) |---------------------------------------->| 265 ............. 267 | | 268 | CON [0x7511] | 269 | (Token 0x55566AF7464646BC) | (*) 270 | AUTH option | 271 | GET /temp | 272 9) |<----------------------------------------| 273 | | 274 | ACK [0x7511] | 275 (*) | (Token 0x55566AF7464646BC) | 276 | AUTH option | 277 | 2.05 Content | 278 | "22.5C" | 279 10) |---------------------------------------->| 280 ................ 282 | | 283 | CON [0x7600] | 284 | (Token 0x678443AA678BC690) | (*) 285 | AUTH option | 286 | DELETE /auth/5 | 287 11) |<----------------------------------------| 288 | | 289 | ACK [0x7500] | 290 (*) | (Token 0x678443AA678BC690) | 291 | AUTH option | 292 | 2.02 Deleted | 293 12) |---------------------------------------->| 295 (*) Protected with AUTH option 297 Figure 2: EAP over CoAP with AUTH option 299 3.2. EAP in CoAP with DTLS 301 Other possibility at our disposal is to do a DTLS handshake after the 302 MSKs generation and continue the communication between endpoints 303 using CoAP through DTLS as we can see at Figure 3. The Steps 0-6 are 304 the same as the case with AUTH option, however, before continuing 305 with Steps 7 and 8, the EAP authenticator starts the DTLS handshake 306 with the EAP peer (Step 7'). To establish a DTLS Security 307 Association, a key named DTLS-PSK is derived from MSK (see Section 4 308 ). In this case the CoAP client can start DTLS before sending the 309 last message containing the EAP Success. Once DTLS is established, 310 any posterior CoAP exchange is protected. Thus, new AUTH option is 311 not needed. A successful DTLS negotiation confirms the possession of 312 DTLS_PSK that, in turn, corroborates that both entities participated 313 in the EAP authentication. 315 EAP peer EAP Auth. 316 (COAP server) (COAP client) 317 ------------- ------------- 318 | | 319 | CON [0x6af5] | 320 0) | Token [0xFA5B45FF4723BB43] | 321 | GET /auth | 322 |---------------------------------------->| 323 | | 324 | | 325 | ACK 2.05 [0x6af5] | 326 | (Token 0xFA5B45FF4723BB43) | 328 0') | Payload ["OK"]| 329 |<----------------------------------------| 330 | | 331 | CON [0x73DE] | 332 | (Token 0x78728FD4AC3190FF) | 333 | POST /auth | 334 1) |<----------------------------------------| 335 | | 336 | ACK [0x73DE] | 337 | (Token 0x78728FD4AC3190FF) | 338 | 2.01 Created | 339 | Uri-Path [auth/5] | 340 2) |---------------------------------------->| 341 | | 342 | CON [0x7654] | 343 | (Token 0x78728FD4AC3190FF) | 344 | Payload EAP-PSK MSG 1 | 345 | PUT /auth/5 | 346 3) |<----------------------------------------| 347 | | 348 | ACK [0x7654] | 349 | (Token 0x78728FD4AC3190FF) | 350 | 2.04 Changed | 351 | Payload EAP-PSK MSG 2 | 352 4) |---------------------------------------->| 353 | | 354 | CON [0x9869] | 355 | (Token 0x78728FD4AC3190FF) | 356 | Payload EAP-PSK MSG 3 | 357 | PUT /auth/5 | 358 5) |<----------------------------------------| 359 | | 360 | ACK [0x9869] | 361 | (Token 0x78728FD4AC3190FF) | 362 | 2.04 Changed | 363 | Payload EAP-PSK MSG 4 | 364 6) |---------------------------------------->| 365 MSK | | MSK 366 | | | | 367 DTLS_PSK| | DTLS_PSK 368 | | 369 | DTLS HANDSHAKE | 370 | (Initiated by EAP Auth.) | 371 7') |<--------------------------------------->| 372 | | 373 | CON [0x7811] | 374 | (Token 0x78728FD4AC3190FF) | 375 | Payload EAP Success | (*) 376 | PUT /auth/5 | 377 7) |<----------------------------------------| 378 | | 379 | ACK [0x7811] | 380 (*) | (Token 0x78728FD4AC3190FF) | 381 | 2.04 Changed | 382 8) |---------------------------------------->| 384 ............. 386 | | 387 | CON [0x7511] | 388 | (Token 0xAA763D82F623B7FF) | (*) 389 | GET /temp | 390 9) |<----------------------------------------| 391 | | 392 | ACK [0x7511] | 393 (*) | (Token 0xAA763D82F623B7FF) | 394 | 2.05 Content | 395 | "22.5C" | 396 10) |---------------------------------------->| 397 ................ 399 | | 400 | CON [0x7600] | 401 | (Token 0x678443AA678BC690) | (*) 402 | DELETE /auth/5 | 403 11) |<----------------------------------------| 404 | | 405 | ACK [0x7500] | 406 (*) | (Token 0x678443AA678BC690) | 407 | 2.02 Deleted | 408 12) |---------------------------------------->| 410 (*) Protected with DTLS 412 Figure 3: EAP over CoAP with DTLS 414 4. Key Derivation for protecting CoAP messages 416 As a result of a successful EAP authentication, both CoAP server and 417 CoAP client share a Master Key Session (MSK). The assumption is that 418 MSK is a fresh key so any derived key from the MSK will be also 419 fresh. We have considered the derivation of either COAP_AUTH_KEY or 420 DTLS_PSK. 422 4.1. Deriving COAP_AUTH_KEY 424 A key COAP_AUTH_KEY is derived from the MSK to generate the 425 authentication tag included in the AUTH option. COAP_AUTH_KEY is 426 derived by using AES-CMAC-PRF-128 [RFC4615], which, in turn, uses 427 AES-CMAC-128 [RFC4493]. In this case, rest of CoAP exchanges between 428 both entities can be protected with integrity (NOTE: encryption will 429 be considered in the future) with AUTH option without the need of 430 using DTLS. Thus, all CoAP messages MUST include AUTH option from 431 that point. (NOTE: We understand that this would not be the standard 432 way of protecting CoAP but instead a new way of protecting CoAP 433 messages). 435 COAP_AUTH_KEY is a 16-byte length key which is computed in the 436 following way: 438 COAP_AUTH_KEY = AES-CMAC-PRF-128(MSK, "IETF COAP AUTH" || Token 439 Option value, 64, length("IETF COAP AUTH" || Token Option value)) 441 where: 443 o The AES-CMAC-PRF-128 is defined in [RFC4615]. This function uses 444 AES-CMAC-128 as building block. 446 o The MSK exported by the EAP method. 448 o "IETF COAP AUTH" is the ASCII code representation of the non-NULL 449 terminated string (excluding the double quotes around it). This 450 value is concatenated with the value of the Token Option value. 452 o 64 is the length of the MSK. 454 o length("IETF COAP AUTH" || Token Option value) is the length of 455 the label "IETF COAP AUTH" (14 bytes) plus the Token Option value. 457 4.2. Deriving DTLS_PSK 459 In the second alternative, a DTLS_PSK is derived from the MSK between 460 both CoAP endpoints. So far, DTLS_PSK will have also 16 byte length 461 and it will derived as follows: 463 DTLS_PSK = AES-CMAC-PRF-128(MSK, "IETF COAP DTLS" || Token Option 464 value, 64, length("IETF COAP DTLS" || Token Option value)). This 465 value is concatenated with the value of the Token Option value. 467 where: 469 o MSK is exported by the EAP method. 471 o "IETF COAP DTLS" is the ASCII code representation of the non-NULL 472 terminated string (excluding the double quotes around it). 474 o 64 is the length of the MSK. 476 o length("IETF COAP DTLS" || Token Option value) is the length of 477 the label "IETF COAP DTLS" (14 bytes) plus the Token Option Value. 479 As mentioned in [RFC4279], a PSK identity is needed. We are 480 considering the usage of the Token Option value chosen during the EAP 481 authentication as identity. In any case, this still needs further 482 investigation. 484 5. Generating AUTH option 486 A new AUTH option is defined in this document for authentication 487 purposes. Following guidelines in [I-D.ietf-core-coap] this option 488 is: 490 1. Format opaque (sequence of bytes). 492 2. Elective. 494 3. Unsafe to Forward. 496 4. No cacheable. 498 The number of the option will be determined by this previous 499 decisions. 501 1. Elective (C = 0) 503 2. Unsafe to Forward (0) 505 3. NoCacheKey (111) 507 The number of the AUTH option will fit this pattern: xxx11100 509 0 1 2 3 4 5 6 7 510 +---+---+---+---+---+---+---+---+ 511 | | NoCacheKey| U | C | 512 +---+---+---+---+---+---+---+---+ 514 Figure 4: Auth Option Number Mask 516 First available option number is 01011100 (92). 518 The resultant AUTH option is: 520 +-----+----+---+---+---+-----------+--------+--------+---------+ 521 | No. | C | U | N | R | Name | Format | Length | Default | 522 +-----+----+---+---+---+-----------+--------+--------+---------+ 523 | 92 | | | x | | AUTH | opaque | 128 | (none) | 524 +-----+----+---+---+---+-----------+--------+--------+---------+ 526 Figure 5: AUTH Option 528 C, U, N and R columns indicate the properties, Critical, UnSafe, 529 NoCacheKey and Repeatable, respectively. 531 To generate the value of the AUTH option, we use AES-CMAC-128 as 532 authentication algorithm. Thus, the AUTH option content will have an 533 authentication tag of 16 bytes. 535 AUTH Option value = AES-CMAC-128(COAP_AUTH_KEY, MSG, MSG_LENGTH) 537 where: 539 o COAP_AUTH_KEY is the key derived in the CoAP Security Association 540 process. 542 o MSG is the CoAP message including AUTH option filled with zeros. 544 o MSG_LENGTH. Length of the CoAP message. 546 After applying AES-CMAC-128 function, the AUTH option value will be 547 set in the AUTH option replacing the zeros. 549 6. Implementation 551 At the time of writing this document, we have developed a proof-of- 552 concept based on libcoap ([libCoAP]) in PC platform and started the 553 development of a simulation with COOJA network simulator for Contiki 554 ([Contiki]). 556 So far, we have implemented an authentication tag by using AES- 557 CMAC-128. However this authentication tag has been included in the 558 payload of two final messages after sending the EAP Success. The 559 implementation of the AUTH option will come soon. Moreover, we have 560 used AES-CMAC-128 for COAP_AUTH_KEY. Since this function does not 561 allow a key longer than 16 bytes, we have used the most significative 562 16 bytes of the MSK as input key. Since AES-CMAC-PRF-128 eliminates 563 this limitation, we will implement this version instead. 565 We are using (for the PC version) libeap in wpa-supplicant and 566 hostapd open source software ([hostapd]) to implement the EAP stack 567 and, in particular, the EAP-PSK method. 569 7. Future Work: CoAP Relay 571 Architecture explained in Figure 1 assumes that EAP peer can 572 communicate with the EAP authenticator. In certain scenarios, EAP 573 authenticator may not be reachable from the EAP peer if the EAP 574 authenticator is placed several hops-away. In this scenario, 575 described in Figure 6, we are considering the usage a new service 576 that assists the authentication. This service acts as a relay of 577 CoAP messages between the EAP peer and EAP authenticator. We have 578 called the entity in charge of performing this service CoAP relay. 579 The strategy is similar to the one described in PANA Relay 580 ([RFC6345]) or DTLS Relay ([I-D.kumar-dice-dtls-relay]). Unlike CoAP 581 proxy, the CoAP relay is not intended to keep any state (stateless 582 behaviour) and the EAP peer is not assumed to be aware of the 583 presence of the CoAP relay. In any case, this part needs further 584 investigation since CoAP already provides the concept of CoAP proxy 585 and, particular, CoAP-to-CoAP proxy that might be used instead. 587 +------------+ +------------+ +--------------+ 588 | EAP peer/ | | | | EAP auth | 589 | CoAP server|+------+| CoAP relay |+------+| CoaP client | 590 +------------+ CoAP +------------+ CoAP +--------------+ 591 | 592 AAA | 593 | 594 +--------------+ 595 | EAP server/ | 596 | AAA server | 597 +--------------+ 599 Figure 6: CoAP EAP Relay Architecture 601 Once the EAP peer has been authenticated, CoAP relay service should 602 not be needed anymore for this EAP peer. 604 Development of this new service may modify the "Unsafe to Forward" 605 flag of the AUTH option. 607 8. Acknowledgments 609 We would like to thank Pedro Moreno-Sanchez and Gabriel Lopez-Millan 610 for the first review of this document. Also, we would like to thank 611 Ivan Jimenez-Sanchez for the first proof-of-concept implementation of 612 this idea. 614 9. Security Considerations 616 TBD. 618 10. IANA Considerations 620 This document has no actions for IANA. 622 11. References 624 11.1. Normative References 626 [I-D.ietf-core-coap] 627 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 628 Application Protocol (CoAP)", draft-ietf-core-coap-18 629 (work in progress), June 2013. 631 [I-D.kumar-dice-dtls-relay] 632 Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay 633 for Constrained Environments", draft-kumar-dice-dtls- 634 relay-00 (work in progress), October 2013. 636 [I-D.ohba-core-eap-based-bootstrapping] 637 Das, S. and Y. Ohba, "Provisioning Credentials for CoAP 638 Applications using EAP", draft-ohba-core-eap-based- 639 bootstrapping-01 (work in progress), March 2012. 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 645 Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 646 3748, June 2004. 648 [RFC4279] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 649 for Transport Layer Security (TLS)", RFC 4279, December 650 2005. 652 [RFC4493] Song, JH., Poovendran, R., Lee, J., and T. Iwata, "The 653 AES-CMAC Algorithm", RFC 4493, June 2006. 655 [RFC4615] Song, J., Poovendran, R., Lee, J., and T. Iwata, "The 656 Advanced Encryption Standard-Cipher-based Message 657 Authentication Code-Pseudo-Random Function-128 (AES-CMAC- 658 PRF-128) Algorithm for the Internet Key Exchange Protocol 659 (IKE)", RFC 4615, August 2006. 661 [RFC4764] Bersani, F. and H. Tschofenig, "The EAP-PSK Protocol: A 662 Pre-Shared Key Extensible Authentication Protocol (EAP) 663 Method", RFC 4764, January 2007. 665 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 666 Authentication Protocol (EAP) Key Management Framework", 667 RFC 5247, August 2008. 669 [RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, 670 "Specification for the Derivation of Root Keys from an 671 Extended Master Session Key (EMSK)", RFC 5295, August 672 2008. 674 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 675 Yegin, "Protocol for Carrying Authentication for Network 676 Access (PANA) Relay Element", RFC 6345, August 2011. 678 11.2. Informative References 680 [Contiki] "Contiki: The Open Source OS for the Internet of Things", 681 March 2014. 683 [hostapd] "hostapd: IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS 684 Authenticator", March 2014. 686 [libCoAP] "C-Implementation of CoAP", January 2013. 688 Authors' Addresses 690 Raul Sanchez-Sanchez 691 University of Murcia 692 Campus de Espinardo S/N, Faculty of Computer Science 693 Murcia 30100 694 Spain 696 Phone: +34 868 88 92 81 697 Email: raul@um.es 699 Rafa Marin-Lopez 700 University of Murcia 701 Campus de Espinardo S/N, Faculty of Computer Science 702 Murcia 30100 703 Spain 705 Phone: +34 868 88 85 01 706 Email: rafa@um.es