idnits 2.17.1 draft-schmitt-two-way-authentication-for-iot-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 11, 2014) is 3726 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) -- Looks like a reference, but probably isn't: 'RFC2119' on line 689 -- Looks like a reference, but probably isn't: 'RFC6550' on line 692 -- Looks like a reference, but probably isn't: 'RFC4944' on line 700 == Missing Reference: '2' is mentioned on line 709, but not defined == Missing Reference: '3' is mentioned on line 714, but not defined -- Looks like a reference, but probably isn't: 'RFC6347' on line 697 -- Looks like a reference, but probably isn't: 'CH' on line 381 -- Looks like a reference, but probably isn't: 'Zurich' on line 382 -- Looks like a reference, but probably isn't: 'Zurich-Oerlikon' on line 383 -- Looks like a reference, but probably isn't: 'UZH' on line 384 -- Looks like a reference, but probably isn't: 'IFI' on line 385 == Missing Reference: '12' is mentioned on line 725, but not defined -- Looks like a reference, but probably isn't: 'RFC5280' on line 704 == Missing Reference: '5' is mentioned on line 720, but not defined == Unused Reference: '11' is defined on line 760, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Schmitt 3 Internet-Draft B. Stiller 4 Intended status: Standards Track University of Zurich 5 Expires: August 15, 2014 February 11, 2014 7 DTLS-based Security with two-way Authentication for IoT 8 10 Abstract 12 In this draft the first key idea for a full two-way authentication 13 security scheme for the Internet of Things (IoT) based on existing 14 Internet standards, specifically the Datagram Transport Layer 15 Security (DTLS) protocol, is introduced. By relying on an 16 established standard, existing implementations, engineering 17 techniques, and security infrastructure can be reused, which enables 18 an easy security uptake. The proposed security scheme is, therefore, 19 based on RSA, the most widely used public key cryptography algorithm. 20 It is designed to work over standard communication stacks that offer 21 UDP/IPv6 networking for Low power Wireless Personal Area Networks 22 (6LoWPANs). RSA is a bulky solution at the moment but shows that it 23 is possible using it on constraint devices for security purposes. An 24 optimization would be to use elliptic curve cryptography. For sure 25 the proposed handshake will stay the same. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 15, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. High Level Design Requirements . . . . . . . . . . . . . . . . 4 67 3.1. Implementation of A Standards Based Design . . . . . . . . 4 68 3.2. Focus on Application Layer and End-to-End Security . . . . 4 69 3.3. Support for Unreliable Transport Protocols . . . . . . . . 5 71 4. Two-way authentication handshake . . . . . . . . . . . . . . . 5 72 4.1. DTLS Standard - RFC 6347 . . . . . . . . . . . . . . . . . 6 73 4.2. A Standard Based End-to-End Security Architecture . . . . 6 74 4.2.1. Handshake description . . . . . . . . . . . . . . . . 8 75 4.2.2. Certificate creation . . . . . . . . . . . . . . . . . 8 77 5. Architecture Description . . . . . . . . . . . . . . . . . . . 9 78 5.1. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.3. Data Access Procedure . . . . . . . . . . . . . . . . . . 12 82 6. Hardware Requirements . . . . . . . . . . . . . . . . . . . . 14 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 86 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 88 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 10.1. Norminative References . . . . . . . . . . . . . . . . . . 16 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 96 1. Introduction 98 Today, there is a multitude of envisioned and implemented use cases 99 for the Internet of Things (IoT) and wireless sensor networks 100 (WSNs).In many of these scenarios it is intended to make the 101 collected data globally accessible to authorized users and data 102 processing units through the Internet. Most of these data collected 103 in such scenarios is of sensitive nature due to the relation to 104 location and personal information or IDs. Even seemingly 105 inconspicuous data, such as the energy consumption measured by a 106 smart meter, can lead to potential infringements in the users' 107 privacy, e.g., by allowing an eavesdropper to conclude whether or not 108 a user is currently at home. From an industry perspective, there is 109 also a pressing need for security solutions based on standards as 110 pointed out by the market research firm Gartner Inc. [1]. Regarding 111 the infrastructure, security risks are aggravated by the trend toward 112 a separation of sensor network infrastructure and applications. 113 Therefore, a true end-to-end security solution is required to achieve 114 an adequate level of security for IoT. Protecting the data once it 115 leaves the scope of the local network is not sufficient. 117 A similar scenario in the traditional computing world would be a user 118 browsing the Internet over an unsecured WLAN. Assuming attackers in 119 physical proximity of the user it can happen that the attacker can 120 capture the traffic between the user and a Web server. 121 Countermeasures against such attacks include the establishment of a 122 secured connection to the Web server via HTTPS, the use of a VPN 123 tunnel to securely connect to a trusted VPN endpoint, and using 124 wireless network security such as WPA. 126 These solutions are comparable to security approaches in the IoT 127 area. Using WPA is similar to the traditional use of link layer 128 encryption. The VPN solution is equivalent to creating a secure 129 connection between a sensor node and a security end-point, which may 130 or may not be the final destination of the sensor data. Establishing 131 a HTTPS connection with the server is comparable to the approach 132 described in this draft: The use of the DTLS protocol in an end-to- 133 end security architecture for IoT is investigated, where a two-way 134 authentication handshake is processed in order to establish a secured 135 communication channel requiring authentication of both communication 136 parties. 138 1.1. Document Structure 140 Section 2 mentions conventions used in this draft. Afterwards the 141 assumed high level design requirements are briefly mentioned in 142 Section 3. Section 4 describes a two-way authentication handshake 143 for constraint devices in order to establish an end-to-end security 144 in constraint networks (e.g., wireless sensor networks). In this 145 section a brief description of the standard DTLS protocol based on 146 RFC 6347 is given, as well as the description of the proposed 147 solution for a standard based end-to-end security architecture 148 including handshake and message details. The assumed use-case with 149 its requirements and architecture is described in Section 5. 150 Section 6 defines the hardware requirements, followed by security 151 considerations. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 A publisher represents any kind of device that makes its data public 160 available in a network using WLAN or LAN connection. 162 A subscriber represents any kind of device that wants to access data. 164 An Access Control server (AC) is an entity in the network that 165 regulates the access of data and issues an access ticket for 166 subscribers based on legal and regulative implications. 168 3. High Level Design Requirements 170 Due to the usage of DTLS for establishing an end-to-end security 171 architecture for IoT three high-level design decisions have to be 172 made. 174 3.1. Implementation of A Standards Based Design 176 Standardization has helped the widespread uptake of technologies. 177 Radio chips can rely on IEEE 802.15.4 for the physical and the MAC 178 layer. Routing functionality is provided by the so-called 'IPv6 179 Routing Protocol for Low power and Lossy Networks' (RPL) [RFC6550] or 180 6LoWPAN [RFC4944]. COAP [2] defines the application layer. So far, 181 no such efforts have addressed security in a wider context of IoT. 183 3.2. Focus on Application Layer and End-to-End Security 185 An end-to-end protocol provides security even if the underlying 186 network infrastructure is only partially under the user's control. 187 As the infrastructure for Machine-to-Machine (M2M) communication is 188 getting increasingly commoditized, this scenario becomes more likely: 189 The European Telecommunications Standard Institute (ETSI) plans to 190 standardize the transport of local device data to a remote data 191 center. For stationary installations security functionality could be 192 provided by the gateway to the higher-level network. However, such 193 gateways may present a high-value target for an attacker. If the 194 devices are mobile, as it is possible within a logistic application, 195 there may be no gateway to a provider's network that is under the 196 user's control, similar to how users of smart phones connect directly 197 to their carrier's network. Another example that favors end-to-end 198 security is a multi-tenancy office building being equipped with a 199 common infrastructure for metering and climate-control purposes. 200 Tenants share the infrastructure but are still able to keep their 201 devices' data private from other members of the network. 203 DTLS is located between the transport and the application layer. 204 Thus, it is not necessary that providers of the infrastructure 205 support security mechanisms. It is purely in the hands of the two 206 communicating applications to establish security. If the security is 207 provided by a network layer protocol (e.g., IPsec) the same is true 208 to a lower degree, because network stacks of both devices have to 209 support the same security protocols. 211 3.3. Support for Unreliable Transport Protocols 213 Reliable transport protocols like TCP incur an overhead over simpler, 214 unreliable protocols such as UDP. Especially for energy starved, 215 battery powered devices this overhead is often too costly and TCP has 216 been shown to perform poorly in low-bandwidth scenarios [3]. This is 217 reflected in the design of the emerging standard COAP, which uses UDP 218 transport and defines a binding to DTLS for security [2]. By using 219 DTLS in conjunction with UDP this draft does not force the 220 application developer to use reliable transport - as it would be the 221 application developer to use reliable transport - as it would be the 222 case if TLS would be used. It is still possible to use DTLS over 223 transport protocols like TCP, since DTLS only assumes unreliable 224 transport. 226 This is a weaker property than the reliability provided by TCP. 227 However, adaptations of DTLS for unreliable transport introduce 228 additional overhead when compared to TLS. There MAY be a benefit in 229 using TCP during the handshake phase but the DTLS reliability 230 mechanism SHOULD be adapted to the special requirements of constraint 231 networks. 233 4. Two-way authentication handshake 234 4.1. DTLS Standard - RFC 6347 236 The Datagram Transport Layer Security (DTLS) protocol in version 1.2 237 was standardized under the RFC 6347 [RFC6347]. All messages sent via 238 DTLS are prepended with a 13 Byte long DTLS record header. This 239 header specifies the content of the message (e.g. application data or 240 handshake data), the version of the protocol employed, as well as the 241 64 bit sequence number and the record length. The top two bytes of 242 the sequence number are used to specify the epoch of the message, 243 which changes once new encryption parameters have been negotiated 244 between client and server. 246 The key material and cipher suite, consisting of a block cipher and a 247 hash algorithm, are negotiated between the client and the server 248 during the handshake phase, which commences before any application 249 data can be transferred. Three types of handshake exist: 250 unauthenticated, server authenticated, and fully authenticated 251 handshakes. The latter handshake type is assumed for the proposed 252 two-way authentication solution in this draft in order to establish 253 end-to-end security. 255 4.2. A Standard Based End-to-End Security Architecture 257 The proposed system architecture in this draft is following the IoT 258 model. It is assumed that IPv6 connects the Internet and parts of it 259 run 6LoWPAN. The transport layer in 6LoWPAN is UDP, which can be 260 considered unreliable; the routing layer is RPL or Hydro [3]. Both 261 routing protocols are similar enough and, therefore, a change has 262 negligible impact on the results. IEEE 802.15.4 is used for the 263 physical and MAC layer. Based on this protocol stack DTLS was 264 selected as the security protocol and placed in the application layer 265 on top of the UDP transportation layer. Figure 1 shows the network 266 stack used in this draft [6], while BLIP is a special 6LoWPAN 267 implementation including several IP protocols [7]. 269 +--------------------------------------+ 270 | Application Layer: COAP, XML, .... | 271 | | 272 | +-------------------------+ | 273 | | Security Layer: DTLS | | 274 | +-------------------------+ | 275 +--------------------------------------+ 276 | Transport Layer: UDP-- | 277 | |-->BLIP,RPL | 278 | Network Layer: IPv6--- | 279 +--------------------------------------+ 280 | Medium Access Layer: IEEE 802.15.4 | 281 +--------------------------------------+ 282 | Physical Layer: IEEE 802.15.4 | 283 +--------------------------------------+ 285 Figure 1: Assumed Network Stack 287 In order to support end-to-end communication security the need for 288 proper authentication of data publishing devices and access control 289 throughout the network is required. Thus, an Access Control (AC) 290 server is integrated in the assumed system architecture. The AC is a 291 trusted entity and a resource-rich server, on which access rights for 292 the publisher (= sensor nodes) of the secured network are stored. 293 The identity of a default subscriber is usually preconfigured on a 294 publisher before it is deployed. 296 If any additional subscribers want to initialize a connection with 297 the publisher, they first have to obtain an access ticket from the 298 AC. The AC verifies that the subscriber has the right to access the 299 information available from the publisher. In the next step the 300 publisher only has to evaluate the identity of the subscriber and has 301 to verify the ticket it has received from the AC. This requires a 302 unique identity for a publisher in the network. 304 In the Internet, identities are usually established via public key 305 cryptography (PKC) and identifiers are provided through X.509 306 certificates. An X.509 certificate contains, among other 307 information, the public key of an entity and its common name. A 308 trusted third party, called the Certificate Authority (CA), signs the 309 certificate. 311 The CA serves two purposes: Firstly, the signature allows the 312 receiver to detect modifications to the certificate. Secondly, it 313 also states that the CA has verified the identity of the entity that 314 requested the certificate. In the following sections the proposed 315 two-way authentication handshake is specified and message structure 316 is presented in detail. 318 4.2.1. Handshake description 320 Based on the hardware equipment (cf. Section 6) the proposed two-way 321 authentication handshake has to support a solution for TPM equipped 322 devices and without. 324 Figure 2 summarizes the message flow during the two-way 325 authentication handshake. Here client and server represent the two 326 communication parties that want to exchange data. Client 327 (Subscriber) is each entity that requests data from another entity 328 and a server (Publisher) can be each entity that has the data. 330 Client Server 331 | | 332 |---ClientHello---------------------->| 333 | | 334 |<----------------ClientHelloVerify---| 335 | | 336 |---ClientHello---------------------->| 337 | | 338 |<----------------------ServerHello---| 339 |<----------------------Certificate---| 340 |<-------------[CertificateRequest]---| 341 |<------------------ServerHelloDone---| 342 | | 343 |---[Certificate]-------------------->| 344 |---ClentKeyExchange----------------->| 345 |---[CertificateVerify]-------------->| 346 |---ChangeCipherSpec----------------->| 347 |---Finished------------------------->| 348 | | 349 |<-----------------ChangeCipherSpec---| 350 |<-------------------------Finished---| 351 | | 352 | | 354 Figure 2: Message flow of two-way authentication handshake 356 4.2.2. Certificate creation 358 When the network consists of devices with TPM it is processed like 359 shown in Figure 2. Before deploying the devices certificates and 360 individual 2048 bit RSA keys should be created and stored. 362 Therefore, it is recommended to use an OpenSSL implementation on the 363 server site [13]. 365 The certificate should include the following details: 366 1. Serial number 367 2. Validity: 368 * Not Before: Date and time 369 * Not After: Date and time 370 3. Subject 371 * commonName = localhost 372 4. X509v3 extensions: 373 * X509v3 Basic Constraints: CA:FALSE 374 * Netscape Comment: OpenSSL Generated Certificate 375 * X509v3 Subject Key Identifier 376 * X509v3 Authority Key Identifier 378 Depending on the implementation additional information should be 379 requested that will be incorporated into the certificate request. 380 This informatiion may include the following: 381 1. Country Name (2 letter code) [CH] 382 2. State or Providence Name (full name) [Zurich] 383 3. Locality Name (e.g., city) [Zurich-Oerlikon] 384 4. Organization Name (e.g., company) [UZH] 385 5. Organisation Unit Name (e.g., section) [IFI] 386 6. Common Name (e.g., YOUR name) [opal-device10] 387 7. Email Address [] 388 8. optional 389 * A challenge password [] 390 * An optional company name [] 392 5. Architecture Description 394 As briefly mentioned in Section 1 data is connected to sensitive 395 information and can lead to potential infringements in the users' 396 privacy. This fact becomes a security risk if the data is 397 transmitted over long distances, perhaps several hops, to a specified 398 global sink [10]. Depending on the setting it might happen that the 399 data is also transmitted via the Internet and might be cached in 400 between. The latter case is inspired by the project FLAMINGO, which 401 deals with access regulations based on legal and regulative 402 implications in IP networks [9]. By definition of the Internet of 403 Things it can be assumed that IP communication is supported by all 404 devices in wireless sensor networks, which allows the adaptation of 405 standards in IP networks to constraint networks. 407 5.1. Use-cases 409 The idea of the Internet of Thing includes any device connection that 410 supports IPv6 communication. Thus, the diversity of use-cases is 411 manifold and not limited to the following list of use-cases: 413 Home Automation 415 Different devices (e.g., temperature, light, movement sensors) are 416 deployed in a house. Those devices transmit collected data to a 417 central entitiy that is responsible for further processing 418 including data publishing if other devices (e.g., HVAC unit, 419 mobile devices) subscribe to data in order to create an action 420 (e.g., turn on heating or light). 422 Health Monitoring 424 Devices are carried by patients that monitor health status (e.g., 425 heart beat, oxigen concentration). Data is transmitted to central 426 unit that again publishs the data and makes it available to a 427 doctor or health care center. 429 Emergency Alerts 431 Devices measure environment, transmit data to central unit to 432 publish it. Authenticated entities subscribe to data for 433 emergency warnings (e.g. earth quake warning system, fire 434 department). 436 Logistics 438 Logistic devices are equipped with sensors (e.g., graviation, 439 humidity, GPS). Data is monitored and made available to owners to 440 locate the equipment during transportation. 442 Several use-cases are specified in reference [12]. All use-cases 443 have in common that data is collected to monitore something, is 444 transmitted to central unit that published data. This data can than 445 be accessed by authorized entities (e.g., device, persons). Usually, 446 the data includes sensitive information and, therefore, secure 447 transmission is required as proposed by the aforementioned sections. 448 The projects FLAMINGO [9] and SmartenIT [8] deal with some of those 449 use-cases and investigate the security issues with focus on two-way 450 authentication issues for secure data transmission. 452 5.2. Requirements 454 In order to show the applicability of the proposed solution 455 throughout the above sections a common network structure consisting 456 of a global sink and several sensor nodes is assumed. Additionally, 457 an Access Control server (AC) is integrated into the network. The AC 458 is a trusted entity and a more resource-rich server, on which the 459 access rights for the publishers (= sensor nodes) of the secured 460 network are stored. Therefore, every publisher in the network MUST 461 have an unique identity. Figure 3 illustrates the assumed 462 architecture, where it is assumed that also the subscriber, 463 publisher, and sensors have individual certificates received from the 464 Certificate Authority. 466 +-----------------------+ 467 | Certificate Authority | 468 +-----------------------+ 469 | | 470 | | 471 +------------+ +----------------------+ +---------+ 472 | Subscriber |-------| Access Control Server|-------| Gateway | 473 +------------+ +----------------------+ +---------+ 474 | 475 | 476 +-----------+ 477 | Publisher | 478 +-----------+ 479 | 480 +------------+----------------+ 481 | | | 482 +----------+ +----------+ +----------+ 483 | Sensor 1 | | Sensor 2 | ... | Sensor n | 484 +----------+ +----------+ +----------+ 486 Figure 3: Architecture 488 As mentioned the concept of Internet of Things forms the basis for 489 this draft, which include also the basic understanding of the 490 Internet. Thus, it is assumed that identities are usually 491 established via public key cryptography and the identifiers provided 492 through X.509 certificates [RFC5280]. In general, X.509 certificate 493 contains the public key of an entity and its common name. A trusted 494 third party - Certificate Authority (CA) - signs that certificate. 495 This signing allows the receiver to detect modifications to the 496 certificate and that the identity of the entity, who requested the 497 certificate, has been verified by the CA. The CA can be run by the 498 administrator of the network or an established Internet certificate 499 authority can be used. 501 Furthermore, it is assumed that the identity of a default subscriber 502 is usually preconfigured on a publisher before it is deployed. 504 5.3. Data Access Procedure 506 Based on the FLAMINGO project the following use-case is assumed [9]: 507 A sensor node has published its data, which is transmitted in 508 direction to the global sink (cf. Figure 3 where global sink is 509 located in the gateway component). Therefore, it is assumed that a 510 two-way authentication handshake between those two communication 511 parties was successful performed before. In between the data can be 512 cashed in order to make it accessible more quicker to subscribers. 513 In this case the cached entity functions as a publisher. 515 Assuming the new subscriber wants to access the data, it must 516 initialize a connection with the publisher. Therefore, the 517 subscriber MUST obtain an access ticket from the AC before. The 518 functionality of the AC is to verify that the subscriber has the 519 right to access the data available from the publisher. Those rights 520 are influenced by legal and regulative implications (e.g., rights 521 connected to an ISP region, where the subscriber belongs to). If the 522 subscriber received a valid access ticket, it is presented to the 523 publisher. The publisher must evaluate the identity of the 524 subscriber and verify the ticket it has received from the AC. 526 If the validation was successful the subscriber can access the data. 527 Before every kind of data exchange, where sensitive information is 528 involved, takes place the proposed two-way authentication handshake 529 is performed in order to establish a highly secured communication 530 channel between the entities. Figure 4 summarizes the aforementioned 531 work flow and will be defined in detail in the upcoming subsections. 533 Access 534 Control 535 Subscriber Server Gateway Publisher 536 | | | | 537 | | | | 538 | | | Two-way | 539 | | |<--authentication-->| 540 | | | Handshake | 541 | | | | 542 | | | | 543 | | |<--Measured Data----| 544 | | | | 545 | Two-way | | | 546 |<--authentication -->| | | 547 | Handshake | | | 548 | | | | 549 | | | | 550 | Connection | | | 551 |------- request ---->| | | 552 | for Publisher | | | 553 | | | | 554 | | | | 555 | Check of | | 556 | Request | | 557 | | | | 558 | | | | 559 | Copy of | | | 560 |<------ Access ------+-Subscriber`s Access ticket-->| 561 | Ticket | | | 562 | | | | 563 | | | Validation of 564 | | | Access Ticket 565 | | | | 566 | | | | 567 | Two-way authentication handshake between | 568 |<-------------------------------------------------->| 569 | Subscriber and Publisher | 570 | | | | 571 | | | | 572 |<-----Data exchange using DTLS secured channel----->| 573 | | | | 574 | | | | 576 Figure 4: Flow Diagram for Data Access Procedure 578 6. Hardware Requirements 580 Hu et al. showed that RSA, the most commonly used public key 581 algorithm in the Internet, can be used in sensor networks with the 582 assistance of a Trusted Platform Module (TPM), which costs less than 583 5% of a common sensor node [4]. A TPM is an embedded chip that 584 provides tamper proof generation and storage of RSA keys as well as 585 hardware support for the RSA algorithm. The certificate of a TPM 586 equipped publisher and the certificate of a trusted CA MUST be stored 587 on the publisher prior to deployment. 589 For publishers that are not equipped with TPM chips the 590 authentication can be proposed via the DTLS pre-shared key cipher- 591 suite, which requires a small number of random bytes, from which the 592 actual key is derived, to be preloaded to the publisher before 593 deployment. This secret MUST also be made available to the AC 594 server, which will disclose the key to devices with sufficient 595 authorization. 597 7. Security Considerations 599 The following security goals are addressed by the key idea presented 600 in this draft: 602 Authenticity 604 Recipients of a message can identify their communication partners 605 and can detect if the sender information has been forged. 607 Integrity 609 Communication partners can detect changes to a message during 610 transmission. 612 Confidentiality 614 Attackers cannot gain knowledge about the content of a secured 615 message. 617 By choosing DTLS as the security protocol those goals can be 618 achieved. DTLS is a modification of TLS for the unreliable UDP and 619 inherits its security properties [5]. Furthermore, if hardware 620 including TPM is available, it is recommended to use it especially on 621 vulnerable points (e.g., cluster heads, aggregation points, 622 publisher, subscriber) within the network. 624 8. Acknowledgement 626 The draft authors thank Thomas Kothmayr from Technische Universitaet 627 Muenchen (Germany) for developing the idea of this draft and 628 implementing a first solution. Additional thanks to Wen Hu from 629 CSIRO ICT Centre (Australia) who supported the complete approach and 630 funding the required sensor node`s hardware with TPM technology. 632 The ongoing work is supported partially by the SmartenIT [8] and the 633 FLAMINGO [9] projects, funded by the EU FP7 Program under Contract 634 No. FP7-2012-ICT-317846 and No. FP7-2012-ICT-318488, respectively. 636 9. Formal Syntax 638 6LoWPAN - IPv6 over Low power Wireless Personal Area Network (RFC 639 4944) 641 AC - Access Control Server 643 BLIP - Berkeley Low-power IP stack 645 CA - Certificate Authority 647 CBC - Cipher-Block Chaining 649 COAP - Constrained Application Protocol 651 DTLS - Datagram Transport Layer Security protocol (RFC 6347) 653 ECC - Elliptic Curve Cryptography 655 ETSI - European Telecommunications Standard Institute 657 H - Header 659 HVAC - Heating, Ventilation, and Air Conditioning 661 HMAC - Hash-based Message Authentication Code 663 IoT - Internet of Things 665 IV - Initialization Vector 667 PKC - Public Key Cryptography 669 RPL - Routing Protocol for Low power and Lossy Networks (RFC 6550) 670 T-A - Token A 672 T-B - Token B 674 TCP - Transmission Control Protocol (RFC 793) 676 TLS - The Transport Layer Security (TLS) Protocol Version 1.2 (RFC 677 5246) 679 TPM - Trusted Platform Module 681 UDP - User Datagram Protocol (RFC 768) 683 WSN - Wireless Sensor Network 685 10. References 687 10.1. Norminative References 689 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 690 Requirement Levels", BCP 14, RFC 2119, March 1997. 692 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 693 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 694 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 695 Lossy Networks", RFC 6550, March 2012. 697 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 698 Security Version 1.2", RFC 6347, January 2012. 700 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 701 "Transmission of IPv6 Packets over IEEE 802.15.4 702 Networks", RFC 4944, September 2007. 704 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 705 Housley, R., and W. Polk, "Internet X.509 Public Key 706 Infrastructure Certificate and Certificate Revocation List 707 (CRL) Profile", RFC 5280, May 2008. 709 [2] Shelby et al., Z., "Constrained Application Protocol 710 (CoAP), 711 http://tools.ietf.org/html/draft-ietf-core-coap-14", 712 March 2013. 714 [3] Dawson-Haggerty et al., S., "Hydro: A Hybrid Routing 715 Protocol for Low-power and Lossy Networks", In Proceedings 716 of the 1st IEEE International Conference on Smart Grid 717 Communications, SmartGridComm, Gaithersburg, Maryland, 718 U.S.A. , 2010. 720 [5] Modadugu et al., N., "The Design and Implementation of 721 Datagram TLS", In Proceedings of the Network and 722 Distributed System Security Symposium (NDSS), San Diego, 723 California, U.S.A. , 2004. 725 [12] Seitz et al., L., "Use cases for CoRE security, http:// 726 tools.ietf.org/html/draft-seitz-core-sec-usecases-00", 727 IETF Draft draft-seitz-core-sec-usecases-00, Version 0, , 728 2012. 730 10.2. Informative References 732 [1] LeHong, H., "Hype Cycle for the Internet of Things", Tech. 733 rep., Gartner Inc. , 2012. 735 [4] Hu, W., "Toward Trusted Wireless Sensor Networks", ACM 736 Transactions on Sensor Networks, Vol. 7, No.5. , 2010. 738 [6] Kothmayr et al., T., "DTLS Based Security and Two-Way 739 Authentication for the Internet of Things", Elsevier, 740 Journal Ad Hoc Networks , 2013. 742 [7] Dawson-Haggerty, S. and D. Culler, "Berkeley IP 743 Information, Berkeley WEBS Wireless Embedded Systems, 744 http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip", 745 2010. 747 [8] SmartenIT Consortium, "Socially-aware Management of New 748 Overlay Application Traffic combined with Energy 749 Efficiency in the Internet (SmartenIT), 750 http://www.smartenit.eu/", 20103. 752 [9] Flamingo Consortium, "FLAMINGO - Management of the Future 753 Internet, http://www.fp7-flamingo.eu/", 2013. 755 [10] Schmitt, C., "Secure Data Transmission in Wireless Sensor 756 Networks, Dissertation", Network Architectures and 757 Services (NET), ISBN: 3-937201-36-X, ISSN: 1868-2634 758 (print), DOI: 10.2313/NET-2013-07-2 , 2013. 760 [11] Boyd, C. and A. Mathuria, "Protocols for Authentication 761 and Key Establishment (Information Security and 762 Cryptography)", Springer, ISBN 3540431071 , 2003. 764 [13] "OpenSSL - Cryptography and SSL/TLS Toolkit, 765 https://www.openssl.org/", 2014. 767 Authors' Addresses 769 Corinna Schmitt 770 Univerity of Zurich 771 Department for Informatics 772 Communication Systems Group 773 Binzmuehlestrasse 14 774 Zurich 8050 775 Switzerland 777 Email: schmitt@ifi.uzh.ch 779 Burkhard Stiller 780 Univerity of Zurich 781 Department for Informatics 782 Communication Systems Group 783 Binzmuehlestrasse 14 784 Zurich 8050 785 Switzerland 787 Email: stiller@ifi.uzh.ch