idnits 2.17.1 draft-schmitt-ace-twowayauth-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 : ---------------------------------------------------------------------------- ** There are 26 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([RFC7228]), 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 30, 2015) is 3216 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: 'RFC7228' on line 736 -- Looks like a reference, but probably isn't: 'RFC2119' on line 739 -- Looks like a reference, but probably isn't: 'RFC6550' on line 742 -- Looks like a reference, but probably isn't: 'RFC4944' on line 750 -- Looks like a reference, but probably isn't: 'RFC7252' on line 766 == Missing Reference: '3' is mentioned on line 769, but not defined -- Looks like a reference, but probably isn't: 'Certificate' on line 344 -- Looks like a reference, but probably isn't: 'CH' on line 379 -- Looks like a reference, but probably isn't: 'Zurich' on line 380 -- Looks like a reference, but probably isn't: 'Zurich-Oerlikon' on line 381 -- Looks like a reference, but probably isn't: 'UZH' on line 382 -- Looks like a reference, but probably isn't: 'IFI' on line 383 -- Looks like a reference, but probably isn't: 'RFC6090' on line 754 -- Looks like a reference, but probably isn't: 'RFC5280' on line 757 == Missing Reference: '12' is mentioned on line 779, but not defined == Missing Reference: '5' is mentioned on line 774, but not defined -- Looks like a reference, but probably isn't: 'RFC6347' on line 747 -- Looks like a reference, but probably isn't: 'RFC4754' on line 762 == Unused Reference: '11' is defined on line 813, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 16 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: January 1, 2016 M. Noack 6 June 30, 2015 8 Two-way Authentication for IoT 9 11 Abstract 13 In this draft a full two-way authentication security scheme for the 14 Internet of Things (IoT) based on existing Internet standards and 15 protocols is introduced. The solution is twofold providing a two-way 16 authentication for resource-rich hardware (e.g., class 2 devices with 17 ~50 KiB RAM and ~250 KiB ROM [RFC7228]) and for devices with less 18 resources (e.g., class 1 devices with ~10 KiB RAM and ~100 KiB ROM 19 [RFC7228]). By relying on an established standard, existing 20 implementations, engineering techniques, and security infrastructure 21 can be reused, which enables an easy security uptake. The proposed 22 security scheme for resource-rich devices is, therefore, based on 23 RSA, the most widely used public key cryptography algorithm. It is 24 designed to work over standard communication stacks that offer UDP/ 25 IPv6 networking for Low power Wireless Personal Area Networks 26 (6LoWPANs). RSA is a bulky solution at the moment but shows that it 27 is possible using it on constraint devices for security purposes. An 28 optimization is the usage of elliptic curve cryptography (ECC) as 29 assumed for devices with less resources. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 1, 2016. 48 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Document Structure . . . . . . . . . . . . . . . . . . . . 5 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3. High Level Design Requirements . . . . . . . . . . . . . . . . 5 70 3.1. Implementation of A Standards Based Design . . . . . . . . 5 71 3.2. Focus on Application Layer and End-to-End Security . . . . 6 72 3.3. Support for UDP . . . . . . . . . . . . . . . . . . . . . 6 74 4. End-to-End Security Using Two-way authentication . . . . . . . 7 75 4.1. Class 2 Devices or Higher . . . . . . . . . . . . . . . . 7 76 4.1.1. Handshake Description . . . . . . . . . . . . . . . . 8 77 4.1.2. Certificate Creation . . . . . . . . . . . . . . . . . 9 78 4.2. Class 1 Devices . . . . . . . . . . . . . . . . . . . . . 10 79 4.2.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 10 81 5. Architecture Description . . . . . . . . . . . . . . . . . . . 11 82 5.1. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . 11 83 5.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 12 84 5.3. Data Access Procedure . . . . . . . . . . . . . . . . . . 13 86 6. Hardware Requirements . . . . . . . . . . . . . . . . . . . . 15 87 6.1. Class 2 Hardware Requirements . . . . . . . . . . . . . . 15 88 6.2. Class 1 Hardware Requirements . . . . . . . . . . . . . . 16 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 7.1. Class 2 Security Considerations . . . . . . . . . . . . . 16 92 7.2. Class 1 Security Considerations . . . . . . . . . . . . . 16 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 95 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 97 10. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 17 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 11.1. Norminative References . . . . . . . . . . . . . . . . . . 18 101 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 105 1. Introduction 107 Today, there is a multitude of envisioned and implemented use cases 108 for the Internet of Things (IoT) and wireless sensor networks 109 (WSNs).In many of these scenarios it is intended to make the 110 collected data globally accessible to authorized users and data 111 processing units through the Internet. Most of these data collected 112 in such scenarios is of sensitive nature due to the relation to 113 location and personal information or IDs. Even seemingly 114 inconspicuous data, such as the energy consumption measured by a 115 smart meter, can lead to potential infringements in the users' 116 privacy, e.g., by allowing an eavesdropper to conclude whether or not 117 a user is currently at home. From an industry perspective, there is 118 also a pressing need for security solutions based on standards as 119 pointed out by the market research firm Gartner Inc. [1]. Regarding 120 the infrastructure, security risks are aggravated by the trend toward 121 a separation of sensor network infrastructure and applications. 122 Therefore, a true end-to-end security solution is required to achieve 123 an adequate level of security for IoT. Protecting the data once it 124 leaves the scope of the local network is not sufficient. 126 A similar scenario in the traditional computing world would be a user 127 browsing the Internet over an unsecured WLAN. Assuming attackers in 128 physical proximity of the user it can happen that the attacker can 129 capture the traffic between the user and a Web server. 130 Countermeasures against such attacks include the establishment of a 131 secured connection to the Web server via HTTPS, the use of a VPN 132 tunnel to securely connect to a trusted VPN endpoint, and using 133 wireless network security such as WPA. 135 These solutions are comparable to security approaches in the IoT 136 area. Using WPA is similar to the traditional use of link layer 137 encryption. The VPN solution is equivalent to creating a secure 138 connection between a sensor node and a security end-point, which may 139 or may not be the final destination of the sensor data. Establishing 140 a HTTPS connection with the server is comparable to the approach 141 described in this draft: The use of the DTLS protocol in an end-to- 142 end security architecture for IoT is investigated, where a two-way 143 authentication handshake is processed in order to establish a secured 144 communication channel requiring authentication of both communication 145 parties. Due to high resource requirements, especially memory and 146 computational capacities, devices with additional hardware like TPM 147 can perform this solution (e.g., class 2 devices with ~50 KiB RAM and 148 ~250 KiB ROM [RFC7228]). More constraint devices (e.g., class 1 149 devices with ~10 KiB RAM and ~100 KiB ROM [RFC7228]) can perform two- 150 way authentication using ECC [2] instead. 152 1.1. Document Structure 154 Section 2 mentions conventions used in this draft. Afterwards the 155 assumed high level design requirements are briefly mentioned in 156 Section 3. Section 4 describes a two-way authentication handshake 157 for constraint devices in order to establish an end-to-end security 158 in constraint networks (e.g., wireless sensor networks). This 159 section consists of two parts specifying the solution for resource- 160 rich devices (class 2 devices, for example, supporting Trusted 161 Platform Module (TPM)) and for resource less devices (class 1). The 162 parts include description of the handshake and message details. The 163 assumed use-case with its requirements and architecture is described 164 in Section 5. Section 6 defines the hardware requirements, followed 165 by security considerations and IANA considerations. 167 2. Terminology 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 A publisher represents any kind of device that makes its data public 174 available in a network using WLAN or LAN connection. 176 A subscriber represents any kind of device that wants to access data. 178 An Access Control server (AC) is an entity in the network that 179 regulates the access of data and issues an access ticket for 180 subscribers based on legal and regulative implications. 182 3. High Level Design Requirements 184 Due to the usage of DTLS for establishing an end-to-end security 185 architecture for IoT three high-level design decisions have to be 186 made. 188 3.1. Implementation of A Standards Based Design 190 Standardization has helped the widespread uptake of technologies. 191 Radio chips can rely on IEEE 802.15.4 for the physical and the MAC 192 layer. Routing functionality is provided by the so-called 'IPv6 193 Routing Protocol for Low power and Lossy Networks' (RPL) [RFC6550] or 194 6LoWPAN [RFC4944]. COAP [RFC7252] defines the application layer. So 195 far, no such efforts have addressed security in a wider context of 196 IoT. 198 3.2. Focus on Application Layer and End-to-End Security 200 An end-to-end protocol provides security even if the underlying 201 network infrastructure is only partially under the user's control. 202 As the infrastructure for Machine-to-Machine (M2M) communication is 203 getting increasingly commoditized, this scenario becomes more likely: 204 The European Telecommunications Standard Institute (ETSI) plans to 205 standardize the transport of local device data to a remote data 206 center. For stationary installations security functionality could be 207 provided by the gateway to the higher-level network. However, such 208 gateways may present a high-value target for an attacker. If the 209 devices are mobile, as it is possible within a logistic application, 210 there may be no gateway to a provider's network that is under the 211 user's control, similar to how users of smart phones connect directly 212 to their carrier's network. Another example that favors end-to-end 213 security is a multi-tenancy office building being equipped with a 214 common infrastructure for metering and climate-control purposes. 215 Tenants share the infrastructure but are still able to keep their 216 devices' data private from other members of the network. 218 DTLS is located between the transport and the application layer. 219 Thus, it is not necessary that providers of the infrastructure 220 support security mechanisms. It is purely in the hands of the two 221 communicating applications to establish security. If the security is 222 provided by a network layer protocol (e.g., IPsec) the same is true 223 to a lower degree, because network stacks of both devices have to 224 support the same security protocols. 226 3.3. Support for UDP 228 Reliable transport protocols like TCP incur an overhead over simpler 229 protocols such as UDP. Especially for energy starved, battery 230 powered devices this overhead is often too costly and TCP has been 231 shown to perform poorly in low-bandwidth scenarios [3]. This is 232 reflected in the design of the emerging standard COAP, which uses UDP 233 transport and defines a binding to DTLS for security [RFC7252]. By 234 using DTLS in conjunction with UDP this draft does not force the 235 application developer to use reliable transport - as it would be the 236 case if TLS would be used. It is still possible to use DTLS over 237 transport protocols like TCP, since DTLS only assumes unreliable 238 transport. 240 This is a weaker property than the reliability provided by TCP. 241 However, adaptations of DTLS for unreliable transport introduce 242 additional overhead when compared to TLS. There MAY be a benefit in 243 using TCP during the handshake phase but the DTLS reliability 244 mechanism SHOULD be adapted to the special requirements of constraint 245 networks. 247 4. End-to-End Security Using Two-way authentication 249 End-to-end security using two-way authentication requires lots of 250 resources depending on the selected solution. Here two solutions are 251 presented using two device classes. The more resource consuming 252 solution requires devices with ~50 KiB RAM and ~250 KiB RAM (e.g., 253 class 2) as a minimum. Details are in Section 4.1. A two-way 254 authentication solution using ECC gets along with smaller devices 255 (e.g., class 1 devices with ~10 KiB RAM and ~100 KiB ROM) as 256 describes in Section 4.2. 258 4.1. Class 2 Devices or Higher 260 The proposed system architecture in this draft is following the IoT 261 model. It is assumed that IPv6 connects the Internet and parts of it 262 run 6LoWPAN. The transport layer in 6LoWPAN is UDP, which can be 263 considered unreliable; the routing layer is RPL or Hydro [3]. Both 264 routing protocols are similar enough and, therefore, a change has 265 negligible impact on the results. IEEE 802.15.4 is used for the 266 physical and MAC layer. Based on this protocol stack DTLS was 267 selected as the security protocol and placed in the application layer 268 on top of the UDP transportation layer. Figure 1 shows the network 269 stack used in this draft [6], while BLIP is a special 6LoWPAN 270 implementation including several IP protocols [7]. 272 +--------------------------------------+ 273 | Application Layer: COAP, XML, .... | 274 | | 275 | +-------------------------+ | 276 | | Security Layer: DTLS | | 277 | +-------------------------+ | 278 +--------------------------------------+ 279 | Transport Layer: UDP-- | 280 | |-->BLIP,RPL | 281 | Network Layer: IPv6--- | 282 +--------------------------------------+ 283 | Medium Access Layer: IEEE 802.15.4 | 284 +--------------------------------------+ 285 | Physical Layer: IEEE 802.15.4 | 286 +--------------------------------------+ 288 Figure 1: Assumed Network Stack 290 In order to support end-to-end communication security the need for 291 proper authentication of data publishing devices and access control 292 throughout the network is required. Thus, an Access Control (AC) 293 server is integrated in the assumed system architecture. The AC is a 294 trusted entity and a resource-rich server, on which access rights for 295 the publisher (= sensor nodes) of the secured network are stored. 296 The identity of a default subscriber is usually preconfigured on a 297 publisher before it is deployed. 299 If any additional subscribers want to initialize a connection with 300 the publisher, they first have to obtain an access ticket from the 301 AC. The AC verifies that the subscriber has the right to access the 302 information available from the publisher. In the next step the 303 publisher only has to evaluate the identity of the subscriber and has 304 to verify the ticket it has received from the AC. This requires a 305 unique identity for a publisher in the network. 307 In the Internet, identities are usually established via public key 308 cryptography (PKC) and identifiers are provided through X.509 309 certificates. An X.509 certificate contains, among other 310 information, the public key of an entity and its common name. A 311 trusted third party, called the Certificate Authority (CA), signs the 312 certificate. 314 The CA serves two purposes: Firstly, the signature allows the 315 receiver to detect modifications to the certificate. Secondly, it 316 also states that the CA has verified the identity of the entity that 317 requested the certificate. In the following sections the proposed 318 two-way authentication handshake is specified and message structure 319 is presented in detail. 321 4.1.1. Handshake Description 323 Based on the hardware equipment (cf. Section 6) the proposed two-way 324 authentication handshake has to support a solution for class 2 325 devices or higher. 327 Figure 2 summarizes the message flow during the two-way 328 authentication handshake. Here client and server represent the two 329 communication parties that want to exchange data. Client 330 (Subscriber) is each entity that requests data from another entity 331 and a server (Publisher) can be each entity that has the data. 333 Client (A) Server (B) 334 | | 335 |---ClientHello------------------------------------------>| 336 | | 337 |<------------------------------------ClientHelloVerify---| 338 | | 339 |---ClientHello------------------------------------------>| 340 | | 341 | ServerHello, Certificate, | 342 |<-----------------[CertificateRequest],ServerHelloDone---| 343 | | 344 | [Certificate], ClentKeyExchange, | 345 |---[CertificateVerify], ChangeCipherSpec, Finished------>| 346 | | 347 |<---------------------------ChangeCipherSpec, Finished---| 348 | | 349 | | 351 Figure 2: Message Flow of Two-way Authentication Handshake for Class 352 2 Devices 354 4.1.2. Certificate Creation 356 When the network consists of class 2 devices or higher it is 357 processed like shown in Figure 2. Before deploying the devices 358 certificates and individual 2048 bit RSA keys should be created and 359 stored. Therefore, it is recommended to use an OpenSSL 360 implementation on the server site [13]. 362 The certificate should include the following details: 363 1. Serial number 364 2. Validity: 365 * Not Before: Date and time 366 * Not After: Date and time 367 3. Subject 368 * commonName = localhost 369 4. X509v3 extensions: 370 * X509v3 Basic Constraints: CA:FALSE 371 * Netscape Comment: OpenSSL Generated Certificate 372 * X509v3 Subject Key Identifier 373 * X509v3 Authority Key Identifier 375 Depending on the implementation additional information should be 376 requested that will be incorporated into the certificate request. 377 This informatiion may include the following: 379 1. Country Name (2 letter code) [CH] 380 2. State or Providence Name (full name) [Zurich] 381 3. Locality Name (e.g., city) [Zurich-Oerlikon] 382 4. Organization Name (e.g., company) [UZH] 383 5. Organisation Unit Name (e.g., section) [IFI] 384 6. Common Name (e.g., YOUR name) [opal-device10] 385 7. Email Address [] 386 8. optional 387 * A challenge password [] 388 * An optional company name [] 390 4.2. Class 1 Devices 392 The prosposed solution for class 1 devices requests the same network 393 stack as for higher devices shown in Figure 2. Instead of working 394 with X.509 certificates each device is deployed with an unique pre- 395 shared key (PSK) of 16 Byte length [2]. This key is the initial key 396 material that is used for resource saving ECC for performed PKC. ECC 397 [RFC6090] itself offers efficient algorithms (ECDSA [RFC5280], ECIES 398 [16], ECDH [RFC5280]) for key generation, key exchange, encryption, 399 decryption, and signatures. For message encryption an integrated 400 encryption scheme (IES) is recommendated to harness the speed- 401 advantage of symmetric encryption for large amount of data without 402 drawback of a repeated key exchange for every transmission to avoid 403 reusage of secrets. 405 4.2.1. Handshake 407 In order to achieve two-way authentication for class 1 devices the 408 Bellare-Canetti-Krawczyk (BCK) protocol [15] with pre-shared key is 409 recommendated [2]. Those pre-shared keys are master keys for initial 410 authentication between two devices (e.g., client and server). 411 Figure 3 shows the recommendated handshake between two devices. 413 ECC is used for key generation, key exchange, encryption, decryption, 414 and signatures during the data exchange. The public ECC keys are 415 decomposed into x and y-coordinates for easy handling on the mote 416 side. Elliptic Curve Digital Signature Algorithm (ECDSA) signatures 417 are integer keypairs, written as (r, s), and therefore difficult to 418 include in a fixed-length packet, because the bit-length of the 419 hexadecimal representation of large integers may vary. [2] 420 Client (A) Server (B) 421 | | 422 |---------- X_A, H(K, X_A) -------------->| 423 | | 424 |<-- X_B, Sig_B (X_B,X_A, A), H(K, X_B) --| 425 | | 426 |-------- Sig_A (X_A, X_B, B) ----------->| 427 | | 429 Figure 3: Message Flow of Two-way Authentication Handshake for Class 430 1 Devices 432 X_A is the public key of client (A), respectivly X_B of server (B). 433 Sig_A is the signature of client (A), respectively Sig_B of server 434 (B). K represents the PSK. H is a hash function created from the 435 PSK and the corresponding public key, resulting in H(K, X_A) or H(K, 436 X_B). 438 5. Architecture Description 440 As briefly mentioned in Section 1 data is connected to sensitive 441 information and can lead to potential infringements in the users' 442 privacy. This fact becomes a security risk if the data is 443 transmitted over long distances, perhaps several hops, to a specified 444 global sink [10]. Depending on the setting it might happen that the 445 data is also transmitted via the Internet and might be cached in 446 between. The latter case is inspired by the project FLAMINGO, which 447 deals with access regulations based on legal and regulative 448 implications in IP networks [9]. By definition of the Internet of 449 Things it can be assumed that IP communication is supported by all 450 devices in wireless sensor networks, which allows the adaptation of 451 standards in IP networks to constraint networks. 453 5.1. Use-cases 455 The idea of the Internet of Thing includes any device connection that 456 supports IPv6 communication. Thus, the diversity of use-cases is 457 manifold and not limited to the following list of use-cases: 459 Home Automation 461 Different devices (e.g., temperature, light, movement sensors) are 462 deployed in a house. Those devices transmit collected data to a 463 central entitiy that is responsible for further processing 464 including data publishing if other devices (e.g., HVAC unit, 465 mobile devices) subscribe to data in order to create an action 466 (e.g., turn on heating or light). 468 Health Monitoring 470 Devices are carried by patients that monitor health status (e.g., 471 heart beat, oxigen concentration). Data is transmitted to central 472 unit that again publishs the data and makes it available to a 473 doctor or health care center. 475 Emergency Alerts 477 Devices measure environment, transmit data to central unit to 478 publish it. Authenticated entities subscribe to data for 479 emergency warnings (e.g. earth quake warning system, fire 480 department). 482 Logistics 484 Logistic devices are equipped with sensors (e.g., graviation, 485 humidity, GPS). Data is monitored and made available to owners to 486 locate the equipment during transportation. 488 Several use-cases are specified in reference [12]. All use-cases 489 have in common that data is collected to monitor something, is 490 transmitted to central unit that published data. This data can than 491 be accessed by authorized entities (e.g., device, persons). Usually, 492 the data includes sensitive information and, therefore, secure 493 transmission is required as proposed by the aforementioned sections. 494 The projects FLAMINGO [9] and SmartenIT [8] deal with some of those 495 use-cases and investigate the security issues with focus on two-way 496 authentication issues for secure data transmission. 498 5.2. Requirements 500 In order to show the applicability of the proposed solution 501 throughout the above sections a common network structure consisting 502 of a global sink and several sensor nodes is assumed. Additionally, 503 an Access Control Server (ACS) is integrated into the network. The 504 ACS is a trusted entity and a more resource-rich server, on which the 505 access rights for the publishers (= sensor nodes) of the secured 506 network are stored. Therefore, every publisher in the network MUST 507 have an unique identity. Figure 4 illustrates the assumed 508 architecture, where it is assumed that also the subscriber, 509 publisher, and sensors have individual certificates received from the 510 Certificate Authority. Depending on individual architectural setups 511 it can be possible to integrate the ACS functionality direct into the 512 gateway. 514 +----------------------------+ 515 | Certificate Authority (CA) | 516 +----------------------------+ 517 | | 518 +----------------+ +----------------------------+ +---------+ 519 | Subscriber (S) |-----| Access Control Server (ACS)|----| Gateway | 520 +----------------+ +----------------------------+ +---------+ 521 | 522 +---------------+ 523 | Publisher (P) | 524 +---------------+ 525 | 526 +------------+----------------+ 527 | | | 528 +----------+ +----------+ +----------+ 529 | Sensor 1 | | Sensor 2 | ... | Sensor n | 530 +----------+ +----------+ +----------+ 532 Figure 4: Architecture 534 As mentioned the concept of Internet of Things forms the basis for 535 this draft, which include also the basic understanding of the 536 Internet. Thus, it is assumed that identities are usually 537 established via public key cryptography and the identifiers provided 538 through X.509 certificates [RFC5280]. In general, X.509 certificate 539 contains the public key of an entity and its common name. A trusted 540 third party - Certificate Authority (CA) - signs that certificate. 541 This signing allows the receiver to detect modifications to the 542 certificate and that the identity of the entity, who requested the 543 certificate, has been verified by the CA. The CA can be run by the 544 administrator of the network or an established Internet certificate 545 authority can be used. 547 Furthermore, it is assumed that the identity of a default subscriber 548 is usually preconfigured on a publisher before it is deployed. 550 5.3. Data Access Procedure 552 Based on the FLAMINGO project the following use-case is assumed [9]: 553 A sensor node has published its data, which is transmitted in 554 direction to the global sink (cf. Figure 4 where global sink is 555 located in the gateway component). Therefore, it is assumed that a 556 two-way authentication handshake between those two communication 557 parties was successful performed before. In between the data can be 558 cashed in order to make it accessible more quicker to subscribers. 559 In this case the cached entity functions as a publisher. 561 Assuming the new subscriber wants to access the data, it must 562 initialize a connection with the publisher. Therefore, the 563 subscriber MUST obtain an access ticket from the ACS before. The 564 functionality of the ACS is to verify that the subscriber has the 565 right to access the data available from the publisher. Those rights 566 are influenced by legal and regulative implications (e.g., rights 567 connected to an ISP region, where the subscriber belongs to). If the 568 subscriber received a valid access ticket, it is presented to the 569 publisher. The publisher must evaluate the identity of the 570 subscriber and verify the ticket it has received from the ACS. 572 If the validation was successful the subscriber can access the data. 573 Before every kind of data exchange, where sensitive information is 574 involved, takes place the proposed two-way authentication handshake 575 is performed in order to establish a highly secured communication 576 channel between the entities. Figure 5 summarizes the aforementioned 577 work flow and will be defined in detail in the upcoming subsections 578 assuming that the ACS functionality is included in the Gateway 579 component. 581 Subscriber (S) Gateway (incl. ACS) Publisher (P) 582 | | | 583 | | Two-way | 584 | |<-------Authentication Handshake---->| 585 | | | 586 | |<------Measured Data-----------------| 587 | | | 588 | Two-way | | 589 |<--authentication Handshake -->| | 590 | | | 591 |---Connection request for P--->| | 592 | | | 593 | Check of Request | 594 | | | 595 |<---Copy of Access Ticket------+-----Subscriber's Access ticket----->| 596 | | | 597 | | Validation of 598 | | Access Ticket 599 | | | 600 | Two-way authentication handshake between | 601 |<------------------------------------------------------------------->| 602 | Subscriber and Publisher | 603 | | | 604 |<-------------Data exchange using DTLS secured channel-------------->| 605 | | | 606 | | | 608 Figure 5: Flow Diagram for Data Access Procedure 610 6. Hardware Requirements 612 6.1. Class 2 Hardware Requirements 614 Hu et al. showed that RSA, the most commonly used public key 615 algorithm in the Internet, can be used in sensor networks with the 616 assistance of a class 2 devices that MAY include a TPM, which costs 617 less than 5% of a common sensor node [4]. A TPM is an embedded chip 618 that provides tamper proof generation and storage of RSA keys as well 619 as hardware support for the RSA algorithm. The certificate of a TPM 620 equipped publisher and the certificate of a trusted CA MUST be stored 621 on the publisher prior to deployment. 623 For publishers that are not equipped with TPM chips the 624 authentication can be proposed via the DTLS pre-shared key cipher- 625 suite, which requires a small number of random bytes, from which the 626 actual key is derived, to be preloaded to the publisher before 627 deployment. This secret MUST also be made available to the ACS, 628 which will disclose the key to devices with sufficient authorization. 630 6.2. Class 1 Hardware Requirements 632 No hardware requirements. 634 7. Security Considerations 636 7.1. Class 2 Security Considerations 638 The following security goals are addressed by the key idea presented 639 in this draft: 641 Authenticity 643 Recipients of a message can identify their communication partners 644 and can detect if the sender information has been forged. 646 Integrity 648 Communication partners can detect changes to a message during 649 transmission. 651 Confidentiality 653 Attackers cannot gain knowledge about the content of a secured 654 message. 656 By choosing DTLS as the security protocol those goals can be 657 achieved. DTLS is a modification of TLS for the unreliable UDP and 658 inherits its security properties [5]. Furthermore, if hardware 659 including TPM is available, it is recommended to use it especially on 660 vulnerable points (e.g., cluster heads, aggregation points, 661 publisher, subscriber) within the network. 663 7.2. Class 1 Security Considerations 665 t.b.a. 667 8. IANA Considerations 669 No considerations. 671 9. Acknowledgement 673 The draft authors thank Thomas Kothmayr from Technische Universitaet 674 Muenchen (Germany) for developing the idea of the DTLS solution. 675 Additional thanks to Wen Hu from CSIRO ICT Centre (Australia), who 676 supported the complete approach and funding the required sensor 677 node`s hardware with TPM technology. 679 The ongoing work is supported partially by the SmartenIT [8] and the 680 FLAMINGO [9] projects, funded by the EU FP7 Program under Contract 681 No. FP7-2012-ICT-317846 and No. FP7-2012-ICT-318488, respectively. 683 10. Formal Syntax 685 6LoWPAN - IPv6 over Low power Wireless Personal Area Network (RFC 686 4944) 688 ACS - Access Control Server 690 BLIP - Berkeley Low-power IP stack 692 CA - Certificate Authority 694 COAP - Constrained Application Protocol 696 DTLS - Datagram Transport Layer Security protocol (RFC 6347) 698 ECC - Elliptic Curve Cryptography 700 ECDH - Elliptic Curve Diffie-Hellman 702 ECDSA -Elliptic Curve Digital Signature Algorithm 704 ECIES - Elliptic Curve Integrated Encryption System 706 ETSI - European Telecommunications Standard Institute 708 HVAC - Heating, Ventilation, and Air Conditioning 710 IEC - Integrated Encryption Scheme 712 IoT - Internet of Things 714 KiB - Kibi-Byte (1 KiB = 1024 Bytes) [14] 716 PKC - Public Key Cryptography 717 PSK - Pre-shared Key 719 RPL - Routing Protocol for Low power and Lossy Networks (RFC 6550) 721 TCP - Transmission Control Protocol (RFC 793) 723 TLS - The Transport Layer Security (TLS) Protocol Version 1.2 (RFC 724 5246) 726 TPM - Trusted Platform Module 728 UDP - User Datagram Protocol (RFC 768) 730 WSN - Wireless Sensor Network 732 11. References 734 11.1. Norminative References 736 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 737 Constrained-Node Networks", RFC 7228, May 2014. 739 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 740 Requirement Levels", BCP 14, RFC 2119, March 1997. 742 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 743 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 744 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 745 Lossy Networks", RFC 6550, March 2012. 747 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 748 Security Version 1.2", RFC 6347, January 2012. 750 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 751 "Transmission of IPv6 Packets over IEEE 802.15.4 752 Networks", RFC 4944, September 2007. 754 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 755 Curve Cryptography Algorithms", RFC 6090, February 2011. 757 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 758 Housley, R., and W. Polk, "Internet X.509 Public Key 759 Infrastructure Certificate and Certificate Revocation List 760 (CRL) Profile", RFC 5280, May 2008. 762 [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using 763 the Elliptic Curve Digital Signature Algorithm (ECDSA)", 764 RFC 4754, January 2007. 766 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 767 Application Protocol (CoAP)", RFC 7252, June 2014. 769 [3] Balakrishnan, H., Padmanabhan, V., Seshan, S., and R. 770 Katz, "A Comparison Of Mechanisms For Improving TCP 771 Performance Over Wireless Links", IEEE/ACM Transaction on 772 Networking, Vol. 5, No. 6, pp. 756-769 , 1997. 774 [5] Modadugu et al., N., "The Design and Implementation of 775 Datagram TLS", In Proceedings of the Network and 776 Distributed System Security Symposium (NDSS), San Diego, 777 California, U.S.A. , 2004. 779 [12] Seitz et al., L., "ACE use cases, 780 https://tools.ietf.org/html/draft-seitz-ace-usecases-02", 781 IETF Draft draft-ietf-ace-usecases-02, Version 2 , 2014. 783 11.2. Informative References 785 [1] LeHong, H., "Hype Cycle for the Internet of Things", Tech. 786 rep., Gartner Inc. , 2012. 788 [4] Hu, W., "Toward Trusted Wireless Sensor Networks", ACM 789 Transactions on Sensor Networks, Vol. 7, No.5. , 2010. 791 [6] Kothmayr et al., T., "DTLS Based Security and Two-Way 792 Authentication for the Internet of Things", Elsevier, 793 Journal Ad Hoc Networks , 2013. 795 [7] Dawson-Haggerty, S. and D. Culler, "Berkeley IP 796 Information, Berkeley WEBS Wireless Embedded Systems, 797 http://smote.cs.berkeley.edu:8000/tracenv/wiki/blip", 798 2010. 800 [8] SmartenIT Consortium, "Socially-aware Management of New 801 Overlay Application Traffic combined with Energy 802 Efficiency in the Internet (SmartenIT), 803 http://www.smartenit.eu/", 2013. 805 [9] Flamingo Consortium, "FLAMINGO - Management of the Future 806 Internet, http://www.fp7-flamingo.eu/", 2013. 808 [10] Schmitt, C., "Secure Data Transmission in Wireless Sensor 809 Networks, Dissertation", Network Architectures and 810 Services (NET), ISBN: 3-937201-36-X, ISSN: 1868-2634 811 (print), DOI: 10.2313/NET-2013-07-2 , 2013. 813 [11] Boyd, C. and A. Mathuria, "Protocols for Authentication 814 and Key Establishment (Information Security and 815 Cryptography)", Springer, ISBN 3540431071 , 2003. 817 [13] "OpenSSL - Cryptography and SSL/TLS Toolkit, 818 https://www.openssl.org/", 2014. 820 [14] "International Standard - Quantities and units - Part 13: 821 Information science and technology", IEC 80000-13 , 2008. 823 [15] Bellare, M., Canetti, R., and H. Krawczyk, "A Modular 824 Approach to the Design and Analysis of Authentication and 825 Key Exchange Protocols (Extended Abstract)", In 826 Proceedings of the 13th Annual ACM Symposium on Theory of 827 Computing, ser. STOC , 2008. 829 [16] Menezes, A., van Oorschot, P., and S. Vanstone, "Handbook 830 of Applied Cryptography", ICRC Press, ISBN: 831 0-8493-8523-7 , 1996. 833 [2] Noack, M., "Optimization of Two-way Authentication 834 Protocol in Internet of Things", Master Thesis, University 835 of Zurich, Communication Systems Group, Department of 836 Informatics, Zurich, Switzerland , 2014. 838 Authors' Addresses 840 Corinna Schmitt 841 University of Zurich 842 Department for Informatics 843 Communication Systems Group 844 Binzmuehlestrasse 14 845 Zurich 8050 846 Switzerland 848 Email: schmitt@ifi.uzh.ch 849 Burkhard Stiller 850 University of Zurich 851 Department for Informatics 852 Communication Systems Group 853 Binzmuehlestrasse 14 854 Zurich 8050 855 Switzerland 857 Email: stiller@ifi.uzh.ch 859 Martin Noack 861 Email: martin.noack@acm.org