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