idnits 2.17.1 draft-gilger-smart-object-security-workshop-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 16, 2014) is 3503 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-iab-smart-object-architecture-04 == Outdated reference: A later version (-23) exists of draft-ietf-kitten-sasl-oauth-15 -- Obsolete informational reference (is this intentional?): RFC 3576 (Obsoleted by RFC 5176) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gilger 3 Internet-Draft 4 Intended status: Informational H. Tschofenig 5 Expires: March 20, 2015 6 September 16, 2014 8 Report from the 'Smart Object Security Workshop', 9 March 23, 2012, Paris, France 10 draft-gilger-smart-object-security-workshop-03.txt 12 Abstract 14 This document provides a summary of a workshop on 'Smart Object 15 Security', which took place in Paris on March 23, 2012. The main 16 goal of the workshop was to allow participants to share their 17 thoughts about the ability to utilize existing and widely deployed 18 security mechanisms for smart objects. 20 This report summarizes the discussions and lists the conclusions and 21 recommendations to the Internet Engineering Task Force (IETF) 22 community. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 20, 2015. 41 Copyright Notice 43 Copyright (c) 2014 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Workshop Structure . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Requirements and Use Cases . . . . . . . . . . . . . . . 4 62 3.2. Implementation Experience . . . . . . . . . . . . . . . . 7 63 3.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 10 64 3.4. Provisioning of credentials . . . . . . . . . . . . . . . 12 65 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 71 8.2. Informative References . . . . . . . . . . . . . . . . . 16 72 Appendix A. Program Committee . . . . . . . . . . . . . . . . . 17 73 Appendix B. Published Workshop Material . . . . . . . . . . . . 17 74 Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 18 75 Appendix D. Workshop Participants . . . . . . . . . . . . . . . 20 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 78 1. Introduction 80 In early 2011, the Internet Architecture Board (IAB) solicited 81 position statements for a workshop on 'Interconnecting Smart Objects 82 with the Internet', aiming to get feedback from the wider Internet 83 community on their experience with deploying IETF protocols in 84 constrained environments. The workshop took place in Prague on 85 March 25, 2011. During the workshop, a range of topics were 86 discussed, including architecture, routing, energy efficiency, and 87 security. RFC 6574 [RFC6574] summarizes the discussion and suggested 88 several next steps. 90 During the months following the workshop, new IETF initiatives were 91 started, such as the Light-Weight Implementation Guidance (lwig) 92 working group, and hackatons were organized at IETF#80 and IETF#81 to 93 better facilitate the exchange of ideas. 95 With the contributions on security in the IETF CoRE working group as 96 well as in the IETF TLS working group it became clear that further 97 discussions on security were necessary and that those would have to 98 feed in implementation and deployment experience as well as a shared 99 understanding how various building blocks fit into a larger 100 architecture. 102 The workshop on Smart Object Security was organized to bring together 103 various disconnected discussions about smart object security happing 104 in different IETF working groups and industry fora. It was a one-day 105 workshop, held prior to the IETF#83 in Paris on March 23, 2012. 107 The workshop organizers were particularly interested to get input on 108 the following topics, as outlined in the call for position papers: 110 o What techniques for issuing credentials have been deployed? 112 o What extensions are useful to make existing security protocols 113 more suitable for smart objects? 115 o What type of credentials are frequently used? 117 o What experience has been gained when implementing and deploying 118 application layer, transport layer, network layer, and link layer 119 security mechanisms (or a mixture of all of them)? 121 o How can "clever" implementations make security protocols a better 122 fit for constrained devices? 124 o Are there lessons we can learn from existing deployments? 126 This document lists some of the recurring discussion topics of the 127 workshop. It also offers recommendations from the workshop 128 participants. 130 Note that this document is a report on the proceedings of the 131 workshop. The views and positions documented in this report are 132 those of the workshop participants and do not necessarily reflect the 133 views of the authors or the Internet Architecture Board (IAB). 135 2. Terminology 137 This document uses security terminology from [RFC4949] and smart 138 object related terms from [RFC6574]. 140 3. Workshop Structure 142 With 36 accepted position papers there was a wealth of topics to talk 143 about during the one-day workshop. The program committee decided to 144 divide the discussion into four topic areas ("Requirements and Use 145 Cases", "Implementation Experience", "Authorization" and "Providing 146 Credentials"), with two or three invited talks per slot to get a 147 discussion started. This section will summarize the points raised by 148 the invited speakers as well as the essence of the ensuing 149 discussions. 151 3.1. Requirements and Use Cases 153 To design a security solution, an initial starting point is to 154 understand the communication relationships, the constraints, and the 155 security threats. The typical IETF security consideration section 156 describes security threats, security requirements, and security 157 solutions at the level of a single protocol or a single document. To 158 offer a meaningful solution for a smart object deployment it is, 159 however, necessary to go beyond this limited view to the analysis of 160 the larger eco-system. The security analysis, documented in 161 [RFC3552] and in [RFC4101], still provides valuable guidance. 163 Typical questions that arise are: 165 1. Who are the involved actors? 167 Some usage scenarios look very simple at first but then, after a 168 longer investigation, turn out to be quite complex. The smart 169 meter deployment, for example, certainly belongs to one of the 170 more complex deployments due to the history of the energy sector, 171 see [RFC6272]. 173 2. Who provisions credentials? 175 Credentials may, for example, be provisioned by the end user, by 176 the hardware manufacturer, an application service provider, or 177 other parties. With security provided at multiple layers, 178 credentials from multiple parties may need to be provisioned. 180 3. What constraints are imposed on the design? 182 For example, a constraint can be the need to interworking with 183 existing infrastructure. From an architectural point of view an 184 important question is whether security is terminated at the 185 border router (or proxy server) at the customer's premise or if 186 end-to-end security to servers in the Internet is required. A 187 more detailed discussion can be found at 188 [I-D.iab-smart-object-architecture]. 190 4. What type of authorization is required by the identified actors? 191 This may, for example, be authorization to get access to the 192 network, or authorization at the application layer. 193 Authorization decisions may be binary, or may consist of complex 194 role-based access control policies. 196 5. What tasks are expected by the customer who deploys the solution? 198 An end customer may, for example, be expected to enter short PIN 199 codes to pair devices, might need to update the firmware, or 200 needs to connect to an appliance via a Web browser to make more 201 sophisticated configuration settings. The familiarity of end- 202 users with Internet-based devices certainly increases constantly 203 but user interface challenges contribute to a large number of 204 security weaknesses of the Internet and therefore have to be 205 taken into account. 207 To illustrate the differences, consider a mass-market deployment for 208 end customers in comparison to a deployment that is targeting 209 enterprise customers. In the latter case, enterprise system 210 administrators are likely to utilize different management systems to 211 provision security and other system-relevant parameters. 213 Paul Chilton illustrated the security and usability requirements in a 214 typical end-user scenario for small-scale smart lighting systems 215 [PaulChilton] . These systems present a substantial challenge for 216 providing usable and secure communication because they are supposed 217 to be cheap and very easy to set up, ideally as easy as their "dumb" 218 predecessors. The example of IP-enabled light bulbs shows that the 219 more constrained devices are, the more difficult it is to get 220 security right. For this reason, and the required usability, light 221 bulbs might just be the perfect example for examining the viability 222 of security solutions. 224 Rudolf van der Berg focused on large-scale deployments of smart 225 objects, such as eBook readers, smart meters, and automobiles. The 226 use of mobile cellular networks is attractive because they are 227 networks with adequate coverage and capacity on a global scale. In 228 order to make use of mobile networks you need to make use of 229 Subscriber Identity Modules (SIM)-based authentication. However, at 230 this moment the SIM is controlled by the network operator. These 231 companies could also use EAP-SIM [RFC4186] authentication in, for 232 example, wireless LANs. 234 The end-user interaction may differ depending on the credentials 235 being used: for a light bulb deployed in the user's home it is 236 expected that the user somehow configures devices so that only, for 237 example, family members can turn them on and off. Smart objects that 238 are equipped with SIM-based credential infrastructure do not require 239 credential management by the end-user since credential management by 240 the operator can be assumed. Switching cellular operator may, 241 however, pose challenges for these devices. 243 Furthermore, we have a technology that will be both deployed by end- 244 users and large enterprise customers. While the protocol building 245 blocks may be the same, there is certainly a big difference between 246 deployments for large-scale industrial applications and deployments 247 for regular end-users in terms of the architecture. Between these 248 two, the security requirements differ significantly, as do the 249 threats. It is difficult, if not impossible, to develop a single 250 security architecture that fulfills the needs of all users while at 251 the same time meeting the constraints of all kinds of smart objects. 253 In the consumer market, security should not incur any overhead during 254 installation. If an end user has to invest more time or effort to 255 secure a smart object network, he or she will likely not do it. 256 Consumer products will often be retrofitted into the existing 257 infrastructure, bought and installed by consumers themselves. This 258 means that devices will have to come pre-installed to some extent and 259 will most likely interoperate only with the infrastructure provided 260 by the vendor, i.e., the devices will be able to connect to the 261 Internet but will only interoperate with the servers provided by the 262 vendor selling the device. 264 Closed systems (one bulb, one switch) typically work out of the box, 265 as they have been extensively tested and often come with factory- 266 configured security credentials. Problems do arise when additional 267 devices are added or when these closed systems get connected to the 268 Internet. It is still very common to ship devices with default 269 passwords. It is, however, not acceptable that a device is in a 270 vulnerable, but Internet-connected, state before it has been 271 correctly configured by a consumer. It is easy to conceive that many 272 consumers do not configure their devices properly and may therefore 273 make it easy for an adversary to take control of the device by, for 274 example, using the default password or an outdated firmware. 276 Once security threats for a specific deployment scenario have been 277 identified, an assessment takes place to decide what security 278 requirements can be identified and what security properties are 279 desirable for the solution. As part of this process, a conscious 280 decision needs to take place about which countermeasures will be used 281 to mitigate certain threats. For some security threats, the 282 assessment may also lead to the conclusion that the threat is 283 considered out-of-scope and that therefore no technical protection is 284 applied. Different businesses are likely to come to different 285 conclusions about the priorities for protection and what security 286 requirements will be derived. 288 Which security threats are worthwhile to protect against is certainly 289 in the eye of the beholder and remains an entertaining discussion 290 even among security specialists. For some of the workshop 291 participants, the security threats against a smart lighting system 292 were considered relatively minor compared to other smart home 293 appliances. Clearly, the threats depend on the specific application 294 domain but there is a certain danger that deployments of vulnerable 295 smart objects will increase. As the systems evolve and become more 296 pervasive, additional security features may be required and may be 297 difficult to incorporate into the already installed base, 298 particularly if smart objects have no software update mechanism 299 incorporated in their initial design. Smart objects which require 300 human interaction to perform software updates will likely be 301 problematic in the future. This is particularly true for devices 302 that are expected to have service schedules of five to twentyfive 303 years. Experience shows that security breaches that are considered 304 to be a prank usually evolve very rapidly to become destructive 305 attacks. 307 Apart from the security requirements of individual households and 308 users, it is also important to look at the implications of 309 vulnerabilities in large-scale smart object deployments, for example 310 in smart meters and the power grid. 312 Finally, there is the usual wealth of other requirements that need to 313 be taken into account, such as ability for remote configuration and 314 software updates, the ability to deal with transfer of ownership of a 315 device, avoidance of operator or vendor lock-in, crypto agility, 316 minimal production, license and IPR costs, etc. 318 3.2. Implementation Experience 320 The second slot of the workshop was dedicated to reports from first- 321 hand implementation experience. Various participants had provided 322 position papers exploring different security protocols and 323 cryptographic primitives. There were three invited talks which 324 covered tiny implementations of the Constrained Application Protocol 325 (CoAP) protected by Datagram Transport Layer Security (DTLS), a TLS 326 implementation using raw public keys, as well as general experience 327 with implementing public key cryptography on smart object devices. 329 All three presenters demonstrated that implementations of IETF 330 security protocols on various constraint devices are feasible. This 331 was confirmed by other workshop participants as well. The overall 332 code size and performance of finished implementations will depend on 333 the chosen feature set. It is fairly obvious that more features 334 translate to a more complex outcome. Luckily, IETF security 335 protocols in general, and DTLS/TLS is no exception, can be customized 336 in a variety of ways to fit a specific deployment environment. As 337 such, an engineer will have to decide which features are important 338 for a given deployment scenario, and what trade-offs can be made. 339 There was also the belief that IETF security protocols offer useful 340 customization features (such as different ciphersuites in TLS/DTLS) 341 to select the desired combination of algorithms and cryptographic 342 primitives. The need to optimize available security protocols 343 further or to even develop new cryptographic primitives for smart 344 objects was questioned and not seen as worthwile by many 345 participants. 347 The three common constraints for security implementations on smart 348 objects are code size, energy consumption, and bandwidth. The 349 importance to tailor a solution to one of these constraints depends 350 on the specific deployment environment. It might be difficult to 351 develop an architecture that minimizes for all constraints at the 352 same time. 354 To wait for the next generation of hardware typically does not 355 magically lift the constraints faced today. The workshop 356 participants again reinforced the message that was made at the 357 earlier smart object workshop [RFC6574] regarding future developments 358 in the smart object space: "While there are constantly improvements 359 being made, Moore's law tends to be less effective in the embedded 360 system space than in personal computing devices: gains made available 361 by increases in transistor count and density are more likely to be 362 invested in reductions of cost and power requirements than into 363 continual increases in computing power.". 365 The above statement is applicable to smart object designs in general; 366 not only for security. Thus, it is expected that designers will 367 continue having to deal with various constraints of smart objects in 368 the future. A short description of the different classes of smart 369 objects can be found in [RFC7228], which also provides security- 370 related guidance. The workshop participants noted that making 371 security protocols suitable for smart objects must not water down 372 their effectiveness. Security functionality will demand some portion 373 of the overall code size. It will have an impact on the performance 374 of communication interactions, will lead to higher energy 375 consumption, and certainly make the entire product more complex. 376 Still, omitting security functionality because of various constraints 377 is not an option. The experience with implementing available 378 security protocol was encouraging even though the need to make 379 various architectural design decisions for selecting the right set of 380 protocols and protocol extensions that everyone must agree on was 381 pointed out. Sometimes, the leading constraint is energy consumption 382 and in other cases it is main memory, CPU performance, or bandwidth. 383 In any case, for an optimization it is important to look at the 384 entire system rather than a single protocol or even a specific 385 algorithm. 387 Equally important to the code size of the protocols being used in a 388 deployed product are various other design decisions, such as the 389 communication model, the number of communication partners, the 390 interoperability requirements, and the threats that are being dealt 391 with. Mohit Sethi noted that even the execution time for relatively 392 expensive operations like asymmetric signature generation and 393 verification are within acceptable limits for very constrained 394 devices, like an Arduino UNO. In either case, public key 395 cryptography will like only be used for the initial communication 396 setup to establish symmetric session keys. Perhaps surprisingly, the 397 energy cost of transmitting data wirelessly dwarfs even expensive 398 computations like public key cryptography. Since wireless reception 399 is actually the most power consuming task on a smart object, 400 protocols have to be designed accordingly. 402 The workshop participants shared the view that the complexity of 403 security protocols is a result of desired features. Redesigning a 404 protocol with the same set of features will, quite likely, lead to a 405 similar outcome in terms of code size, memory consumption, and 406 performance. It was, however, also acknowledged that the security 407 properties offered by DTLS/TLS/IKEv2-IPsec may not be needed for all 408 deployment environments. DTLS, for example, offers an authentication 409 and key exchange framework combined with channel security offering 410 data-origin authentication, integrity protection, and (optionally) 411 confidentiality protection. 413 The biggest optimization in terms of code size can be gained when 414 looking at the complete protocol stack, rather than only 415 cryptographic algorithms. This also includes software update 416 mechanisms and configuration mechanisms, all of which have to work 417 together. What may not have been investigated enough is the 418 potential of performing cross-layer and cross-protocol optimization. 419 We also need to think about how many protocols for security setup we 420 want to have. Due to the desire to standardize generic building 421 blocks, the ability to optimize for specific deployment environments 422 has been reduced. 424 Finally, it was noted that scalability of security protocols does not 425 imply usability. This means that while smart object technology might 426 currently be developed in large scale industrial environments, it 427 should be equally usable for consumers who want to equip their home 428 with just a few light bulbs. 430 For details about the investigated protocol implementations please 431 consult the positions papers, such as the ones by Bergmann et al., 432 Perelman et al., Tschofenig and Raza et al.. 434 3.3. Authorization 436 The discussion slot on authorization was meant to provide an idea of 437 what kind of authorization decisions are common in smart object 438 networks. Authorization is defined as 'an approval that is granted 439 to a system entity to access a system resource' [RFC4949]. 441 Authorization requires a view on the entire smart object lifecycle to 442 determine when and how a device was added to a specific environment, 443 what permissions have been granted for this device and how users are 444 allowed to interact with it. On a high level, there are two types of 445 authorization schemes: First, there are those systems that utilize an 446 authenticated identifier and match it against an access control 447 lists. Secondly, there are trait-based authorization mechanisms that 448 separate the authenticated identifier from the authorization rights 449 and utilize roles and other attributes to determine whether to grant 450 or deny access to a protected resource. 452 Richard Barnes looked at earlier communication security work and 453 argued that the model that dominates the web today will not be enough 454 for the smart object environment. Simply identifying users by their 455 credentials and servers via certificates is not something that 456 translates well to smart object networks because it binds all the 457 capabilities to the credentials. The evolution in access control is 458 moving in the direction of granting third parties certain 459 capabilities, with OAuth [RFC6749] being an example of a currently 460 deployed technology. Access to a resource using OAuth can be done 461 purely based on the capabilities rather than on the authenticated 462 identifier. 464 At the time of the workshop OAuth was very much focused on HTTP- 465 based protocols with early efforts to integrate OAuth into SASL 466 and the GSS-API [I-D.ietf-kitten-sasl-oauth]. Further 467 investigations need to be done to determine the suitability of 468 OAuth as a protocol for the smart object environment. 470 Richard believed that it is important to separate authentication from 471 authorization right from the beginning and to consider how users are 472 supposed to interact with these devices to introduce them into their 473 specific usage environment (and to provision them with credentials), 474 and to manage access from different parties. 476 The relationship between the policy enforcement point and the policy 477 decision point plays an important role regarding the standardization 478 needs and the type of information that needs to be conveyed between 479 these two entities. 481 For example, in a AAA context the authorization decision happens 482 at the AAA server (after the user requesting access to a network 483 or some application level services had been authenticated). Then, 484 the decision about granting access (or rejecting it) is 485 communicated from the AAA server to the AAA client at the end of 486 the network access authentication procedure. The AAA client then 487 typically enforces the authorization decision over the lifetime of 488 the granted user session. The dynamic authorization extension 489 [RFC3576] to the RADIUS protocol, for example, also allows the 490 RADIUS server to make dynamic changes to a previously granted user 491 session. This includes support for disconnecting users and 492 changing authorizations applicable to a user session. 494 The authorization decisions can range from 'only devices with 495 password can use the network' to very detailed application 496 specification authorization policies. The decisions are likely to be 497 more sophisticated in those use cases where ownership of devices may 498 be transferred from one person to another one, group membership 499 concepts may be needed, access rights may be revocable, and fine 500 grained access rights have to be used. The authorization decisions 501 may also take environmental factors into account, such as proximity 502 of devices to each other, physical location of the device asking 503 access, or the level of authentication. With the configuration of 504 authorization policies the question arises who will create them and 505 where these policies are stored. This immediately raises the 506 question about how devices are identified, and who is allowed to 507 create these policies. 509 Since smart objects may be limited in terms of code size, persistent 510 storage, and Internet connectivity, established authorization schemes 511 may not be well suited for such devices. Obviously, delegating every 512 authorization decision to another node in the network incurs a 513 certain network overhead, while storing sophisticated access control 514 policies directly on the smart object might be prohibitive because of 515 the size of such a ruleset. Jan Janak presented one approach to 516 distribute access control policies to smart objects within a single 517 administrative domain. 519 In those cases where access control decisions are bound to the 520 identifiers of devices and humans need to either create or verify 521 these access control policies, the choice of identifier matters for 522 readability and accessibility purposes. 524 A single mechanism will likely not help with solving the wide range 525 of authorization tasks. From the discussions it was not clear 526 whether there is a need for new authorization mechanisms or whether 527 existing mechanisms can be re-used. Examples of available protocols 528 with built-in authorization mechanism are Kerberos, OAuth, EAP/AAA, 529 attribute certificates, etc. In many cases, it is even conceivable 530 that the authorization decisions are internal to the system, and that 531 there is no need to standardize any additional authorization 532 mechanisms or protocols at all. In fact many of the authentication 533 and key exchange protocols have authorization mechanisms built-in. 535 3.4. Provisioning of credentials 537 When a smart object is to be introduced into an environment, like a 538 home or an enterprise network, it usually has to be provisioned with 539 some credentials first. The credentials that are configured at the 540 smart object and at some entity in the network are often an implicit 541 authorization to access the network or some other resource. The 542 provisioned information at the smart object will include some 543 identifier of the smart object, keying material, as well as other 544 configuration information (e.g., specific servers it has to interact 545 with). 547 Some devices will be pre-configured with default security codes or 548 passwords, or will have per-device or per-user credentials pre- 549 configured, when they are bought or when they arrive at the customer. 551 There is a limited set of solutions available (based on the available 552 interface support). The solutions for imprinting vary between the 553 enterprise and the consumer household scenarios. For large-scale 554 deployments, the time needed to pair two objects further excludes 555 other schemes which rely on manual steps. 557 Johannes Gilger dealt with the very basic ideas behind pairing 558 schemes, including the kinds of out-of-band channels that could be 559 employed and their limitations. Imprinting and pairing protocols 560 usually establish a security association between two equal devices, 561 such as Bluetooth-equipped cell phones. To deal with man-in-the- 562 middle attacks during this phase, various forms of additional 563 verification checks exist. For example, devices with a display allow 564 numeric values to be shown on each device and to let the user verify 565 whether they match. For other devices that have a keypad, a PIN may 566 need to be entered by the user. Where and how a smart object is to 567 be paired with other devices in the network can differ substantially 568 from the specific use cases and the hardware capabilities of devices. 569 Note that pairing is not necessarily something that is only done once 570 during the lifetime of a device. Is group pairing something to be 571 looked at? Or can any group key establishment be reduced to pair 572 wise pairing with a central master device? 573 Cullen Jennings presented a model for smart objects based on a 574 deployment used for IP phones. The idea was that the smart object 575 "phones home", i.e., contacts a server offered by the manufacturer, 576 when it is first switched on. This initial interaction can then be 577 used for managing the device and provisioning keying material for 578 further use. Proof of ownership could be done by identifying the 579 user who purchased the device. This is an approach that is 580 increasingly being done today. Another option is some kind of secret 581 information enclosed in the packaging. 583 For interface-constrained devices, the solution of using (semi)- 584 public information in combination with an online manufacturer during 585 imprinting seems like a possible solution. This solution approach 586 created a lot of discussion among the participants, as it assumes an 587 Internet connection and means that the manufacturer effectively knows 588 about the trust relationships of all the devices it sells. 590 A few questions did arise with such a model: Will there be third 591 parties which have a business interest in providing something like 592 key distribution and key escrow over the lifetime of a smart object? 593 For constrained devices, will it always be possible to fall back to 594 the existing security associations between device and manufacturer to 595 create new associations? Obviously, we do not want the lifetime of a 596 smart object limited by the manufacturer product support lifespan. 597 What happens if a manufacturer goes bankrupt, changes its business 598 scope, or gets bought by another company? Will end customers not be 599 able to use their smart objects anymore in such a case or will they 600 loose the ability to re-sell their devices because the ownership can 601 no longer be transferred? 603 One important design decision is that the compromise of the 604 manufacturer must not have any impact on the smart objects, which 605 have already been imprinted to their new owners. Furthermore, the 606 question of how to transfer ownership, e.g. when reselling a device 607 arise. While this may not be a requirement for all devices, there 608 will likely be classes of large or expensive devices where support 609 for transferring the ownership is an absolute necessity. 611 Industrial users are comfortable when they have to rely on the 612 manufacturer during the imprinting phase, but they want to be in 613 exclusive control over their devices afterwards. 615 There are many classes of devices where we could assume online 616 connectivity to be present, otherwise these devices would not make 617 sense in the first place. But, there are also other devices which 618 need to be imprinted completely offline. 620 Is it important to worry about security vulnerabilities, such as man- 621 in-the-middle attacks, during the very short imprinting phase? Is it 622 realistic that an adversary is in close proximity to mount an attack? 623 Especially for devices with limited capabilities, such as lightbulbs, 624 the concerns seemed rather small. 626 What happens if such a device is not enrolled by the customer but 627 still connected in a "naked" state? How does this impact security 628 and it is possible for an attacker to perform a 'drive-by' enrollment 629 procedure of many devices? How should a device behave in this 630 situation? The safest (for the user at least) would be to not allow 631 the device to work with full functionality if it has not been 632 enrolled. This concern is particularly applicable for cases where 633 smart objects are sold with default passwords or passwords using 634 semi-public information. Examples of those are Raspberry Pi's with 635 Linux images that use a default password [RaspberryPi]. 637 4. Summary 639 Designing for a smart object environment is about making an 640 optimization decision that needs to take technical aspects, usage 641 scenarios, security threats, and business models into account. Some 642 design constraints may be considered fixed while others are flexible. 643 Compromises will have need to be made but those should not only go at 644 the expense of security functionality. 646 Designing a software update mechanism into the system is crucial to 647 ensure that functionality can be enhanced and vulnerabilities can be 648 fixed. Also, security threats are perceived differently over time. 649 For example, pervasive monitoring was by many considered less 650 important prior to the Snowden revelations. 652 New research and standardization on cryptographic algorithms (like 653 encryption algorithms, hash functions, keyed message digests, public 654 key crypto systems) that are tailored to smart object environments 655 was not seen as worthwhile by the participants. A huge range of 656 algorithms already exists and standardized authentication and key 657 exchange protocols can be customized to use almost any selection of 658 algorithms already today. 660 The integration of various building blocks into a complete system was 661 considered important and this document highlights a number of those 662 areas in Section 3. Searching for a single, universally applicable 663 smart object security architecture was seen as a hopeless journey 664 given the large number of use cases, business models, and 665 constraints. 667 In response to the workshop follow-up work happened in a number of 668 areas (and standardization activities are still ongoing). Here a few 669 examples: 671 o The "Light-Weight Implementation Guidance (LWIG)" working group 672 was created to offer a venue to collect experiences from 673 implementers' of IP stacks, including security protocols, in 674 constrained devices. The ability to tune IETF protocols via 675 extensions and parameter choices gives implementers a lot of 676 flexibility to meet the constraints of a smart object environment. 678 o The "DTLS In Constrained Environments (DICE)" working group was 679 formed to define a DTLS profile that is suitable for Internet of 680 Things applications and is reasonably implementable on many 681 constrained devices and to define how DTLS record layer can be 682 used to transmit multicast messages securely. DTLS is seen as an 683 important enabling technology for securing communication 684 interactions by smart objects. 686 o A new working group to standardize an authentication and 687 authorization protocol for constrained environments offering a 688 dynamic and fine grained access control mechanism where clients 689 and resource servers are constrained and therefore have to make 690 use of a trusted third party has been formed. At the time of 691 writing the "Authentication and Authorization for Constrained 692 Environments (ACE)" working group has just been started. 694 5. Acknowledgements 696 We would like to thank the participants and the paper authors of the 697 position papers for their input. 699 Special thanks go to Thomas Heide Clausen and Ecole Polytechnique 700 (Paris) for providing the venue and organization. 702 Finally, we would like to thank Rudolf van der Berg for his review 703 comments. 705 6. IANA Considerations 707 This memo includes no request to IANA. 709 7. Security Considerations 711 The whole document is a report on the Smart Object Security Workshop. 712 The focus of this workshop was on security only; privacy was not part 713 of the workshop agenda. 715 8. References 717 8.1. Normative References 719 [RFC6574] Tschofenig, H. and J. Arkko, "Report from the Smart Object 720 Workshop", RFC 6574, April 2012. 722 8.2. Informative References 724 [I-D.iab-smart-object-architecture] 725 Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson, 726 "Architectural Considerations in Smart Object Networking", 727 draft-iab-smart-object-architecture-04 (work in progress), 728 July 2014. 730 [I-D.ietf-kitten-sasl-oauth] 731 Mills, W., Showalter, T., and H. Tschofenig, "A set of 732 SASL Mechanisms for OAuth", draft-ietf-kitten-sasl- 733 oauth-15 (work in progress), July 2014. 735 [PaulChilton] 736 Chilton, P., "Experiences and Challenges in using 737 constrained Smart Objects, Position Paper to the 'Workshop 738 on Smart Object Security'", URL: 739 http://www.tschofenig.priv.at/sos-papers/PaulChilton.pdf, 740 March 2012. 742 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 743 Text on Security Considerations", BCP 72, RFC 3552, July 744 2003. 746 [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 747 Aboba, "Dynamic Authorization Extensions to Remote 748 Authentication Dial In User Service (RADIUS)", RFC 3576, 749 July 2003. 751 [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, 752 June 2005. 754 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 755 Protocol Method for Global System for Mobile 756 Communications (GSM) Subscriber Identity Modules (EAP- 757 SIM)", RFC 4186, January 2006. 759 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC 760 4949, August 2007. 762 [RFC6272] Baker, F. and D. Meyer, "Internet Protocols for the Smart 763 Grid", RFC 6272, June 2011. 765 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 766 6749, October 2012. 768 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 769 Constrained-Node Networks", RFC 7228, May 2014. 771 [RaspberryPi] 772 Raspberry Pi Foundation, "Raspberry Pi", URL: 773 http://www.raspberrypi.org, February 2013. 775 Appendix A. Program Committee 777 The workshop was organized by the following individuals: 779 o Hannes Tschofenig 781 o Jari Arkko 783 o Carsten Bormann 785 o Peter Friess 787 o Cullen Jennings 789 o Antonio Skarmeta 791 o Zach Shelby 793 o Thomas Heide Clausen 795 Appendix B. Published Workshop Material 797 o Main Workshop Page: http://www.lix.polytechnique.fr/hipercom/ 798 SmartObjectSecurity 800 o Position Papers: 801 http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ 802 papers 804 o Slides: 805 http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ 806 slides 808 Appendix C. Accepted Position Papers 810 1. Michael Richardson, "Challenges in Smart Object Security: too 811 many layers, not enough ram" 813 2. Mitsuru Kanda, Yoshihiro Ohba, Subir Das, Stephen Chasko, "PANA 814 applicability in constrained environments" 816 3. Randy Bush, "An Operational View of Trust Needs of Moving 817 Objects" 819 4. Andrei Gurtov, Ilya Nikolaevsky, Andrey Lukyanenko,"Using HIP 820 DEX for Key Management and Access Control in Smart Objects" 822 5. Jens-Matthias Bohli, "Access Tokens for the IoT " 824 6. Sye Loong Keoh, Martina Brachmann, Oscar Garcia-Morchon, Sye- 825 Loong Keoh, Sandeep S. Kumar, "Security Considerations around 826 End-to-End Security in the IP-based Internet of Things" 828 7. Kazunori Miyazawa, "Convergence of Smart Objects in industrial 829 wireless sensor network" 831 8. Thomas Bartzsch, Dirk Burggraf, Laura Cristina, Alexis 832 Olivereau, Nouha Oualha, Emil Slusanschi, Dan Tudose, Markus 833 Wehner, Sven Zeisberg, "AAA-based Infrastructure for Industrial 834 Wireless Sensor Networks" 836 9. Philip Ginzboorg, Fida Khattak, Philip Ginzboorg, Valtteri 837 Niemi, Jan-Erik Ekberg, "Role of Border Router in 6LoWPAN 838 Security" 840 10. Thomas Fossati, Angelo Castellani, Salvatore Loreto, 841 "(Un)trusted Intermediaries in CoAP" 843 11. Rene Hummen, Christian Roeller, Klaus Wehrle, "Modeling User- 844 defined Trust Overlays for the IP-based Internet of Things" 846 12. Sam Hartman, Margaret Wasserman, "Federation, ABFAB and Smart 847 Devices" 849 13. Cary Bran, Joseph Stachula "Device Pairing: Lessons Learned" 851 14. Jan Janak, Hyunwoo Nam, Henning Schulzrinne, "On Access Control 852 in the Internet of Things" 854 15. Rene Struik, "Cryptography and Security for Highly Constrained 855 Networks" 857 16. Zhen Cao, Hui Deng, "The Architecture of Open Security 858 Capability" 860 17. Sujing Zhou, Zhenhua Xie, "On Cryptographic Approaches to 861 Internet-Of-Things Security" 863 18. Monique Morrow, Nancy Cam Winget, "Security Implications to 864 Smart Addressable Objects" 866 19. Jouni Korhonen, "Applying Generic Bootstrapping Architecture for 867 use with Constrained Devices" 869 20. Olaf Bergmann, Stefanie Gerdes, Carsten Bormann, "Simple Keys 870 for Simple Smart Objects" 872 21. Jari Arkko, Mohit Sethi, Ari Keranen, "Practical Considerations 873 and Implementation Experiences in Securing Smart Object 874 Networks" 876 22. Paul Chilton, "Experiences and Challenges in using constrained 877 Smart Objects" 879 23. Vladislav Perelman, Mehmet Ersue, "TLS with PSK for Constrained 880 Devices" 882 24. Richard Barnes, "Security for Smart Objects beyond COMSEC: 883 Principals and Principles" 885 25. Rudolf van der Berg, "OECD Publication on Machine-to-Machine 886 Communications: Connecting Billions of Devices", OECD Digital 887 Economy Papers, No. 192, OECD Publishing 889 26. Cullen Jennings, "Transitive Trust Enrollment for Constrained 890 Devices" 892 27. Barbara Fraser, Paul Duffy, Maik Seewald, "Smart Objects: 893 Security Challenges from the Power Sector" 895 28. Hannes Tschofenig, "Smart Object Security: Considerations for 896 Transport Layer Security Implementations" 898 29. Johannes Gilger, Ulrike Meyer, "Secure Pairing & Policy 899 Frameworks" 901 30. Klaas Wierenga, "Scalable Authentication for Smart Objects" 903 31. Dirk Stegemann, Jamshid Shokrollahi, "Security in the Internet 904 of Things - Experiences from Use Cases" 906 32. Alper Yegin, "Credentials for Smart Objects: A Challenge for the 907 Industry" 909 33. Shahid Raza, Thiemo Voigt, Vilhelm Jutvik, "Lightweight IKEv2: A 910 Key Management Solution for both the Compressed IPsec and the 911 IEEE 802.15.4 Security" 913 34. Eric Rescorla, "A Brief Survey of Imprinting Options for 914 Constrained Devices" 916 35. Fred Baker, "Security in distributed telemetry and control 917 networks" 919 Appendix D. Workshop Participants 921 We would like to thank the following workshop participants for 922 attending the workshop: 924 o Jari Arkko 926 o Carsten Bormann 928 o Cullen Jennings 930 o Antonio Skarmeta 932 o Sean Turner 934 o Thomas Heide Clausen 936 o Hannes Tschofenig 938 o Michael Richardson 940 o Yoshihiro Ohba 942 o Subir Das 944 o Randy Bush 946 o Andrei Gurtov 948 o Ilya Nikolaevsky 950 o Andrey Lukyanenko 952 o Jens-Matthias Bohli 953 o Kazunori Miyazawa 955 o Philip Ginzboorg 957 o Fida Khattak 959 o Angelo Castellani 961 o Salvatore Loreto 963 o Rene Hummen 965 o Klaus Wehrle 967 o Sam Hartman 969 o Margaret Wasserman 971 o Cary Bran 973 o Jan Janak 975 o Rene Struik 977 o Zhen Cao 979 o Hui Deng 981 o Zhou Sujing 983 o Xie Zhenhua 985 o Monique Morrow 987 o Nancy Cam Winget 989 o Jouni Korhonen 991 o Ari Keranen 993 o Paul Chilton 995 o Vladislav Perelman 997 o Mehmet Ersue 999 o Richard Barnes 1000 o Rudolf van der Berg 1002 o Barbara Fraser 1004 o Johannes Gilger 1006 o Sye Loong Keoh 1008 o Olaf Bergmann 1010 o Stefanie Gerdes 1012 o Klaus Hartke 1014 o Oualha Nouha 1016 o Oliverau Alexis 1018 o Alper Yegin 1020 o Klaas Wierenga 1022 o Jiazi Yi 1024 o Juan Antonio Cordero Fuertes 1026 o Antonin Bas 1028 o David Schinazi 1030 o Valerie Lecomte 1032 o Ulrich Herberg 1034 o Shahid Raza 1036 o Stephen Farrell 1038 o Eric Rescorla 1040 o Thomas Fossati 1042 o Mohit Sethi 1044 o Alan Duric 1046 o Guido Moritz 1047 o Sebstian Unger 1049 o Hans Loehr 1051 Authors' Addresses 1053 Johannes Gilger 1054 Mies-van-der-Rohe-Str. 15 1055 Aachen 52074 1056 Germany 1058 Phone: +49 (0)241 80 20 781 1059 Email: Gilger@ITSec.RWTH-Aachen.de 1061 Hannes Tschofenig 1062 Hall in Tirol 6060 1063 Austria 1065 Email: Hannes.tschofenig@gmx.net 1066 URI: http://www.tschofenig.priv.at