idnits 2.17.1 draft-kumar-dice-dtls-relay-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 60 instances of too long lines in the document, the longest one being 21 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, 2013) is 3833 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DICE Working Group S. Kumar 3 Internet-Draft Philips Research 4 Intended status: Standards Track S. Keoh 5 Expires: April 24, 2014 University of Glasgow Singapore 6 O. Garcia-Morchon 7 Philips Research 8 October 21, 2013 10 DTLS Relay for Constrained Environments 11 draft-kumar-dice-dtls-relay-00 13 Abstract 15 The 6LoWPAN and CoAP standards defined for resource-constrained 16 devices are fast emerging as the de-facto protocols for enabling the 17 Internet-of-Things (IoTs). Security is an important concern in IoTs 18 and the DTLS protocol has been chosen as the preferred method for 19 securing CoAP messages. DTLS is a point-to-point protocol relying on 20 the IP routing to deliver messages between the client and the server. 21 However in some low-power lossy networks (LLNs) with multi-hop, a new 22 "joining" device may not be initially IP routable. This prevents 23 DTLS from being directly useful as an authentication and 24 confidentiality protocol during this stage, requiring other security 25 protocols to be implemented on the device. These devices being 26 resource-constrained often cannot accommodate more than one security 27 protocol in their code memory. To overcome this problem and reuse 28 DTLS, we present a DTLS Relay solution for the non-IP routable 29 "joining" device to establish a secure DTLS connection with a DTLS 30 server. Further we present a stateful and stateless mode of 31 operation for the DTLS Relay. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 24, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. DTLS relay . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Relay in Stateful mode . . . . . . . . . . . . . . . . . 5 71 3.2. Relay in Stateless mode . . . . . . . . . . . . . . . . . 7 72 3.3. Comparison between the two modes . . . . . . . . . . . . 9 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 7.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 The Internet-of-Things (IoTs) vision is more closer to reality with 84 the IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) 85 [RFC4944] and Constrained Application Protocol (CoAP) 86 [I-D.ietf-core-coap] standards . The 6LoWPAN adaptation layer allows 87 for transmission of IPv6 Packets over IEEE 802.15.4 networks 88 [ieee802.15.4] and thereby enabling end-to-end IPv6 connectivity of 89 "Things". CoAP is a web protocol based on REST architecture designed 90 to work under the special requirements of the constrained 91 environment. It supports binding to UDP [RFC0768] which is preferred 92 over TCP [RFC0793] in low-power lossy networks (LLNs) such as IEEE 93 802.15.4. 95 Security is important concern in such a wireless multi-hop network 96 that could be used in various application domains such as smart 97 energy and building automation. However security protocols are often 98 heavy-weight both in terms of code and network processing. Due to 99 the constrained nature of most of these devices, multiple security 100 protocols for different purposes and at different networking layers 101 are hard to envision. It is more efficient to use a single security 102 protocol to fulfill multiple security requirements in such 103 constrained environments. 105 CoAP has chosen Datagram Transport Layer Security (DTLS) [RFC6347] as 106 the preferred security protocol for authenticity and confidentiality 107 of the messages. It is based on Transport Layer Security (TLS) 108 [RFC5246] with modifications to run over UDP. DTLS makes use of 109 additional reliability mechanisms in its handshake due to the lack of 110 TCP reliable transmission mechanisms that are available to TLS. 112 DTLS is a point-to-point protocol relying on the underlying IP layer 113 to perform the routing between the DTLS client and the DTLS server. 114 However in some LLNs with multi-hop, a new "joining" device may not 115 be initially IP routable. A new "joining" device can only initially 116 use a link-local IPv6 address to communicate with a neighbour node 117 using neighbour discovery [RFC6775] until it receives the necessary 118 network configuration parameters. Before the device can receive 119 these configuration parameters, it may need to authenticate itself or 120 wish to authenticate the network to which it connects. DTLS although 121 a suitable protocol for such authentication and secure transfer of 122 configuration parameters, would not work due to the lack of IP 123 routability of its messages to the intended recipients. 125 We present a DTLS Relay solution to overcome this problem for the 126 "joining" device to establish a secure DTLS connection with a DTLS 127 server. This draft is inspired by the Protocol for carrying 128 Authentication for Network Access (PANA) Relay Element [RFC6345] 129 which is intended to solve a similar problem when PANA [RFC5191] is 130 used for network access. Further we present a stateful and stateless 131 mode of operation for the DTLS Relay. 133 This draft is an early description of the solutions and does not 134 provide the complete details yet. This draft is structured as 135 follows: we present a use-case for the DTLS Relay in Section 2, then 136 present the DTLS Relay solution in Section 3 for stateful and 137 stateless mode of operation. Further we present some security 138 considerations in Section 5. 140 2. Use Case 142 We present here a target usecase based on 143 [I-D.jennings-core-transitive-trust-enrollment] describing a 144 rendezvous protocol that allows a constrained IoT device to securely 145 connect into a system or network. The main idea is that the joining 146 Device has a pre-established trust relationship with a "Transfer 147 Agent" entity, for e.g. Pre-Shared Keys provisioned during 148 manufacturing. This "Transfer Agent" provides the needed trust 149 credentials to the Device and/or a Controller in the system to 150 establish a secured connection to perform further authentication and 151 transfer of system/network configuration parameters. This step is 152 enabled by an "Introducer" entity which informs the "Transfer Agent" 153 about the details of Controller to which the joining Device should 154 connect, and provide to the Controller the identity including one- 155 time credentials for enable secure connection to the Device. The 156 transitive trust trust establishment procedure is explained in detail 157 in [I-D.jennings-core-transitive-trust-enrollment] and we focus here 158 on how to enable this using DTLS. 160 As depicted in the Figure 1, the joining Device (D) is multi-hop away 161 from the Controller (C) and not yet authenticated into the network. 162 At this stage, it can only communicate one-hop to its nearest 163 neighbour (N) using their link-local IPv6 addresses. However, the 164 Device needs to communicate with end-to-end security with a Transfer 165 Agent (T) or to Controller (C) to authenticate and get the relevant 166 system/network parameters. If the Device (D), initiates a DTLS 167 connection to the Transfer Agent that has been pre-configured, then 168 the packets are dropped at the neighbour (N) since the Device (D) is 169 not yet admitted to the network or there is no IP-routability to 170 Device (D) for any returned messages. 172 Trust Agent 173 ++++ 174 |T | 175 | | +--+ 176 ++++ |N'| 177 | --+--+ 178 | ++++ / 179 | |C |---- +--+ +--+ 180 --| | \ |N |........|D | 181 ++++ \-----| | | | 182 Controller +--+ +--+ 183 Neighbour "join" Device 185 Figure 1: Use case depiction in a multi-hop network 187 Further the Device (D) may wish to establish a secure connection to 188 the Controller (C) in the network assuming credentials are exchanged 189 out-of-band, for e.g. a hash of the Device (D)'s raw public key could 190 be provided to the Controller (C). However, the Device (D) is 191 unaware of the IP address of the Controller (C) to initiate a DTLS 192 connection and perform authentication. 194 To overcome these problems with non-routability of DTLS packets and/ 195 or discovery of the destination address of the DTLS server to 196 contact, we define a DTLS Relay solution. This DTLS Relay ability is 197 configured into all authenticated devices in the network which may 198 act as the Neighbour (N) device for newly joining nodes. The DTLS 199 Relay allows for relaying of the packets from the Neighbour (N) using 200 IP-routing to the intended DTLS server. Further, if the DTLS server 201 address is not known to the joining Device (D), then messages are 202 delivered to a pre-configured DTLS server address (mostly the 203 Controller (C)) known to the DTLS Relay. 205 3. DTLS relay 207 In this section, we describe how the DTLS Relay functionality can be 208 achieved. When a joining device as a client attempts a DTLS 209 connection (for example to a "Transfer Agent"), it uses its link- 210 local IP address as its IP source address. This message is 211 transmitted one-hop to a neighbour node. Under normal circumstances, 212 this message would be dropped at the neighbour node since the joining 213 device is not yet IP routable, or it is not yet authenticated to send 214 messages through the network. However, if the neighbour device has 215 the DTLS Relay functionality enabled, it forwards DTLS messages to 216 specific servers. Additional security mechanisms need to exist to 217 prevent this forwarding functionality to be used by rogue nodes to 218 bypass any network authentication procedures and are discussed in 219 Section 5. 221 The DTLS Relay can operate in two different modes: stateful and 222 stateless. We present here both the methods, however for inter- 223 operability, only one of the modes should be mandated. Within each 224 mode, the DTLS Relay can further forward packets based on the client 225 defined DTLS server address or a DTLS server address that has been 226 configured into the Relay. 228 3.1. Relay in Stateful mode 230 The neighbour node on receiving a DTLS message from a joining device 231 enters into DTLS Relay mode. In this mode, the neighbour node has 232 the additional functionality to send DTLS messages further to the 233 end-point DTLS server the joining device wishes to contact. In the 234 stateful mode of operation, the message is transmitted to the end- 235 point as originating from the DTLS Relay by replacing the IP address 236 and port to DTLS Relay's own IP address and a randomly chosen port. 237 The DTLS message itself is not modified. 239 Additionally, the DTLS Relay must track the ongoing DTLS connections 240 based on the following 4-tuple stored locally: 242 o Client source IP address (IP_C) 244 o Client source port (p_C) 246 o DTLS Server IP address (IP_S) 248 o Relay source port (p_R) 250 The DTLS server communicates to the Relay as if it were communicating 251 to the end-point Client with no modification required to the DTLS 252 messages. The Relay on receiving this message, looks up its locally 253 stored 4-tuple array to identify to which joining device (if multiple 254 exists) the message belongs. The DTLS message's destination address 255 is replaced with that of the link-local address and port of the 256 joining device from the lookup array and forwarded to it. The Relay 257 does not modify the DTLS packets and therefore the normal processing 258 and security of DTLS is unaffected. 260 The following message flow diagram indicates the various steps of the 261 process where the DTLS server address in known to the joining device: 263 +---------------+---------------+----------------+---------------------------+ 264 | DTLS Client | DTLS Relay | DTLS Server | Message | 265 | (C) | (R) | (S) | Src_IP:port | Dst_IP:port | 266 +---------------+---------------+----------------+-------------+-------------+ 267 | --ClientHello--> | IP_C:p_C | IP_S:5684 | 268 | --ClientHello--> | IP_R:p_R | IP_S:5684 | 269 | | | | 270 | <--ServerHello-- | IP_S:5684 | IP_R:p_R | 271 | : | | | 272 | <--ServerHello-- | IP_S:5684 | IP_C:p_C | 273 | : | | | 274 | :: | : | : | 275 | :: | : | : | 276 | --Finished--> | IP_C:p_C | IP_S:5684 | 277 | --Finished--> | IP_R:p_R | IP_S:5684 | 278 | | | | 279 | <--Finished-- | IP_S:5684 | IP_R:p_R | 280 | <--Finished-- | IP_S:5684 | IP_C:p_C | 281 | :: | : | : | 282 +------------------------------------------------+-------------+-------------+ 283 IP_C:p_C = IP (non-routable) and port of Client 284 IP_S:5684 = IP and coaps port of Server 285 IP_R:p_R = IP and port of Relay 286 Figure 2: Message flow in Stateful mode with DTLS Server defined by 287 Client 289 In the situation where the joining device is unaware of the IP 290 address of DTLS server it needs to contact, for e.g. the Controller 291 of the network, the DTLS Relay can be configured with IP destination 292 of the default DTLS server that a joining device needs to contact. 293 The joining device initiates its DTLS request as if the DTLS Relay is 294 the intended end-point DTLS server. The DTLS relay translates the 295 DTLS message as in the previous case by modifying both the source and 296 destination IP address to forward the message to the intended DTLS 297 server. The Relay keeps a similar 4-tuple array to enable 298 translation of the DTLS messages received from the server and forward 299 it to the DTLS Client. The following message flow indicates this 300 process: 302 +---------------+---------------+----------------+---------------------------+ 303 | DTLS Client | DTLS Relay | DTLS Server | Message | 304 | (C) | (R) | (S) | Src_IP:port | Dst_IP:port | 305 +---------------+---------------+----------------+-------------+-------------+ 306 | --ClientHello--> | IP_C:p_C | IP_Ra:5684 | 307 | --ClientHello--> | IP_Rb:p_Rb| IP_S:5684 | 308 | | | | 309 | <--ServerHello-- | IP_S:5684 | IP_Rb:p_Rb | 310 | : | | | 311 | <--ServerHello-- | IP_Ra:5684| IP_C:p_C | 312 | : | | | 313 | :: | : | : | 314 | :: | : | : | 315 | --Finished--> | IP_C:p_C | IP_Ra:5684 | 316 | --Finished--> | IP_Rb:p_Rb| IP_S:5684 | 317 | | | | 318 | <--Finished-- | IP_S:5684 | IP_Rb:p_Rb | 319 | <--Finished-- | IP_Ra:5684| IP_C:p_C | 320 | :: | : | : | 321 +------------------------------------------------+-------------+-------------+ 322 IP_C:p_C = IP (non-routable) and port of Client 323 IP_S:5684 = IP and coaps port of Server 324 IP_Ra:5684 = IP and coaps port of Relay 325 IP_Rb:p_Rb = IP (can be same as IP_Ra) and the port of Relay 327 Figure 3: Message flow in Stateful mode with DTLS Server defined by 328 Relay 330 3.2. Relay in Stateless mode 331 In the alternative mode of operation for the DTLS Relay, a stateless 332 approach is applied where th Relay does not need to store a local 333 4-tuple array. Just as in the previous case, if a DTLS client with 334 only link local addressing wants to contact a trusted end-point DTLS 335 server, it send the DTLS message to the Relay. The Relay instead of 336 translating, encapsulates this message into a new type of message 337 called DTLS Relay (DRY) message. The DRY consists of two parts: 339 o Header (H) field: consisting of the source link-local address and 340 port of the DTLS Client device, and 342 o Contents (C) field: containing the original DTLS message. 344 The DTLS end server on receiving the DRY message, decapsulates it to 345 retrieve the two parts. It then uses the Header field information to 346 associate the new state created on the server for the DTLS connection 347 to the DTLS client's address and port. The DTLS server then performs 348 the normal DTLS operations on the DTLS message contents. However 349 when the DTLS server replies, it also encapsulates its message in a 350 DRY message back to the Relay with the Header containing the original 351 source link-local address and port of the DTLS Client. The Relay can 352 decapsulate the DRY message, retrieves the Header information to 353 forward this message to the right DTLS Client device. 355 The following figure depicts the message flow diagram when the DTLS 356 server end-point address is known only to the Relay: 358 +----------------+---------------------+---------------------+---------------------------+ 359 | DTLS Client | DTLS Relay | DTLS Server | Message | 360 | (C) | (R) | (S) | Src_IP:port | Dst_IP:port | 361 +----------------+---------------------+---------------------+-------------+-------------+ 362 | --ClientHello--> | IP_C:p_C | IP_Ra:5684 | 363 | --DRY[H(IP_C:p_C),C(ClientHello)]--> | IP_Rb:p_Rb| IP_S:5684 | 364 | | | | 365 | <--DRY[H(IP_C:p_C),C(ServerHello)]-- | IP_S:5684 | IP_Rb:p_Rb | 366 | : | | | 367 | <--ServerHello-- | IP_Ra:5684| IP_C:p_C | 368 | : | | | 369 | :: | : | : | 370 | :: | : | : | 371 | --Finished--> | IP_C:p_C | IP_Ra:5684 | 372 | --DRY[H(IP_C:p_C),C(Finished)]--> | IP_Rb:p_Rb| IP_S:5684 | 373 | | | | 374 | <--DRY[H(IP_C:p_C),C(Finished)]-- | IP_S:5684 | IP_Rb:p_Rb | 375 | <--Finished-- | IP_Ra:5684| IP_C:p_C | 376 | :: | : | : | 377 +------------------------------------------------------------+-------------+-------------+ 378 IP_C:p_C = IP (non-routable) and port of Client 379 IP_S:5684 = IP and coaps port of Server 380 IP_Ra:5684 = IP and coaps port of Relay 381 IP_Rb:p_Rb = IP (can be same as IP_Ra) and the port of Relay 383 DRY[H(),C()] = DTLS Relay message with header H and content C 385 Figure 4: Message flow in Stateless mode with DTLS Server defined by 386 Relay 388 The message flow for the case in which the DTLS Client is aware of 389 the end-point DTLS server's address is similar and not described 390 further. It can be derived based on Figure 2 and Figure 4. 392 3.3. Comparison between the two modes 394 A comparison between the two modes will be done in an updated version 395 of this draft. 397 4. IANA Considerations 399 tbd 401 Note to RFC Editor: this section may be removed on publication as an 402 RFC. 404 5. Security Considerations 406 Additional security considerations need to be taken into account 407 about forwarding of messages from devices through a network to which 408 it has not yet been admitted. This can lead to denial-of-service 409 attacks or misuse of network resources without proper authentication. 410 One way to overcome any large scale misuse of the network is to have 411 a management message from the Controller that initiates already 412 authenticated devices in the network to enter into a DTLS Relay mode. 413 The devices can stay such a Relay mode for a fixed period of time or 414 until the Controller sends a new management message blocking the DTLS 415 Relay mode in all devices in the network. This is often possible 416 since the administrator of the network can be aware when new devices 417 join the network either because of the "Introduction" phase or 418 commissioning phase. 420 Other mechanisms based on IP destination filtering can be applied by 421 the controller to all Relay nodes to avoid misuse of the network 422 resources. 424 6. Acknowledgements 426 The authors would like to thank Sahil Sharma, Ernest Ma, Dee 427 Denteneer and Peter Lenoir for the valuable discussions and 428 suggestions, 430 7. References 432 7.1. Normative References 434 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 435 Security Version 1.2", RFC 6347, January 2012. 437 7.2. Informative References 439 [I-D.ietf-core-coap] 440 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 441 Application Protocol (CoAP)", draft-ietf-core-coap-18 442 (work in progress), June 2013. 444 [I-D.jennings-core-transitive-trust-enrollment] 445 Jennings, C., "Transitive Trust Enrollment for Constrained 446 Devices", draft-jennings-core-transitive-trust- 447 enrollment-01 (work in progress), October 2012. 449 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 450 August 1980. 452 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 453 793, September 1981. 455 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 456 "Transmission of IPv6 Packets over IEEE 802.15.4 457 Networks", RFC 4944, September 2007. 459 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 460 Yegin, "Protocol for Carrying Authentication for Network 461 Access (PANA)", RFC 5191, May 2008. 463 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 464 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 466 [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. 467 Yegin, "Protocol for Carrying Authentication for Network 468 Access (PANA) Relay Element", RFC 6345, August 2011. 470 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 471 "Neighbor Discovery Optimization for IPv6 over Low-Power 472 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 473 November 2012. 475 [ieee802.15.4] 476 IEEE Computer Society, ., "IEEE Std. 802.15.4-2003", 477 October 2003. 479 Authors' Addresses 481 Sandeep S. Kumar 482 Philips Research 483 High Tech Campus 34 484 Eindhoven 5656 AE 485 NL 487 Email: sandeep.kumar@philips.com 489 Sye Loong Keoh 490 University of Glasgow Singapore 491 Republic PolyTechnic, 9 Woodlands Ave 9 492 Singapore 838964 493 SG 495 Email: SyeLoong.Keoh@glasgow.ac.uk 497 Oscar Garcia-Morchon 498 Philips Research 499 High Tech Campus 34 500 Eindhoven 5656 AE 501 NL 503 Email: oscar.garcia@philips.com