GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7397

Independent Submission J. Gilger Request for Comments: 7397 H. Tschofenig Category: Informational December 2014 ISSN: 2070-1721

           Report from the Smart Object Security Workshop

Abstract

 This document provides a summary of a workshop on 'Smart Object
 Security' that took place in Paris on March 23, 2012.  The main goal
 of the workshop was to allow participants to share their thoughts
 about the ability to utilize existing and widely deployed security
 mechanisms for smart objects.
 This report summarizes the discussions and lists the conclusions and
 recommendations to the Internet Engineering Task Force (IETF)
 community.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This is a contribution to the RFC Series, independently of any other
 RFC stream.  The RFC Editor has chosen to publish this document at
 its discretion and makes no statement about its value for
 implementation or deployment.  Documents approved for publication by
 the RFC Editor are not a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc7397.

Copyright Notice

 Copyright (c) 2014 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.

Gilger & Tschofenig Informational [Page 1] RFC 7397 Smart Object Security Workshop December 2014

Table of Contents

 1. Introduction ....................................................2
 2. Terminology .....................................................3
 3. Workshop Structure ..............................................3
    3.1. Requirements and Use Cases .................................4
    3.2. Implementation Experience ..................................7
    3.3. Authorization .............................................10
    3.4. Provisioning of Credentials ...............................12
 4. Summary ........................................................14
 5. Security Considerations ........................................15
 6. References .....................................................16
    6.1. Normative References ......................................16
    6.2. Informative References ....................................16
 Appendix A. Program Committee .....................................18
 Appendix B. Published Workshop Material ...........................18
 Appendix C. Accepted Position Papers ..............................18
 Appendix D. Workshop Participants .................................21
 Acknowledgements ..................................................22
 Authors' Addresses ................................................23

1. Introduction

 In early 2011, the Internet Architecture Board (IAB) solicited
 position statements for a workshop on 'Interconnecting Smart Objects
 with the Internet', aiming to get feedback from the wider Internet
 community on their experience with deploying IETF protocols in
 constrained environments.  The workshop took place in Prague on March
 25, 2011.  During the workshop, a range of topics were discussed,
 including architecture, routing, energy efficiency, and security.
 RFC 6574 [RFC6574] summarizes the discussion and suggests several
 next steps.
 During the months following the workshop, new IETF initiatives were
 started, such as the Light-Weight Implementation Guidance (LWIG)
 working group, and hackathons were organized at IETF 80 and IETF 81
 to better facilitate the exchange of ideas.
 Contributions regarding security from the IETF Constrained RESTful
 Environments (CoRE) working group and the IETF Transport Layer
 Security (TLS) working group made it clear that further discussions
 on security were necessary and that those would have to incorporate
 implementation and deployment experience as well as a shared
 understanding of how various building blocks fit into a larger
 architecture.

Gilger & Tschofenig Informational [Page 2] RFC 7397 Smart Object Security Workshop December 2014

 The workshop on 'Smart Object Security' was organized to bring
 together various disconnected discussions about smart object
 security happening in different IETF working groups and industry
 fora.  It was a one-day workshop held prior to the IETF 83 in Paris
 on March 23, 2012.
 The workshop organizers were particularly interested in getting input
 on the following topics, as outlined in the call for position papers:
 o  What techniques for issuing credentials have been deployed?
 o  What extensions are useful to make existing security protocols
    more suitable for smart objects?
 o  What type of credentials are frequently used?
 o  What experience has been gained when implementing and deploying
    application-layer, transport-layer, network-layer, and link-layer
    security mechanisms (or a mixture of all of them)?
 o  How can "clever" implementations make security protocols a better
    fit for constrained devices?
 o  Are there lessons we can learn from existing deployments?
 This document lists some of the recurring discussion topics at the
 workshop.  It also offers recommendations from the workshop
 participants.
 Note that this document is a report on the proceedings of the
 workshop.  The views and positions documented in this report are
 those of the workshop participants and do not necessarily reflect the
 views of the authors or the Internet Architecture Board (IAB).

2. Terminology

 This document uses security terminology from [RFC4949] and terms
 related to smart objects from [RFC6574].

3. Workshop Structure

 With 35 accepted position papers, there was a wealth of topics to
 talk about during the one-day workshop.  The program committee
 decided to divide the discussion into four topic areas ("Requirements
 and Use Cases", "Implementation Experience", "Authorization", and
 "Providing Credentials"), with two or three invited talks per slot to

Gilger & Tschofenig Informational [Page 3] RFC 7397 Smart Object Security Workshop December 2014

 get a discussion started.  This section will summarize the points
 raised by the invited speakers as well as the essence of the ensuing
 discussions.

3.1. Requirements and Use Cases

 To design a security solution, an initial starting point is to
 understand the communication relationships, the constraints, and the
 security threats.  The typical IETF Security Considerations section
 describes security threats, security requirements, and security
 solutions at the level of a single protocol or a single document.  To
 offer a meaningful solution for a smart object deployment, it is,
 however, necessary to go beyond this limited view to the analysis of
 the larger ecosystem.  The security analysis documented in [RFC3552]
 and in [RFC4101] still provides valuable guidance.
 Typical questions that arise are:
 1.  Who are the involved actors?
     Some usage scenarios look very simple at first but then, after a
     longer investigation, turn out to be quite complex.  The smart
     meter deployment, for example, certainly belongs to one of the
     more complex deployments due to the history of the energy sector
     (see [RFC6272]).
 2.  Who provisions credentials?
     Credentials may, for example, be provisioned by the end user, the
     hardware manufacturer, an application service provider, or other
     parties.  With security provided at multiple layers, credentials
     from multiple parties may need to be provisioned.
 3.  What constraints are imposed on the design?
     For example, a constraint can be the need to interwork with
     existing infrastructure.  From an architectural point of view, an
     important question is whether security is terminated at the
     border router (or proxy server) at the customer's premise or if
     end-to-end security to servers in the Internet is required.  A
     more detailed discussion can be found at [SMART-OBJECT].
 4.  What type of authorization is required by the identified actors?
     This may, for example, be authorization to get access to the
     network or authorization at the application layer.  Authorization
     decisions may be binary or may consist of complex, role-based
     access control policies.

Gilger & Tschofenig Informational [Page 4] RFC 7397 Smart Object Security Workshop December 2014

 5.  What tasks are expected by the customer who deploys the solution?
     An end customer may, for example, be expected to enter short PIN
     codes to pair devices, need to update the firmware, or need to
     connect to an appliance via a web browser to make more
     sophisticated configuration settings.  The familiarity of end
     users with Internet-based devices certainly increases constantly,
     but user-interface challenges contribute to a large number of
     security weaknesses of the Internet and therefore have to be
     taken into account.
 To illustrate the differences, consider a mass-market deployment for
 end customers in comparison to a deployment that is targeting
 enterprise customers.  In the latter case, enterprise system
 administrators are likely to utilize different management systems to
 provision security and other system-relevant parameters.
 Paul Chilton illustrated the security and usability requirements in a
 typical end-user scenario for small-scale smart lighting systems
 [PaulChilton].  These systems present a substantial challenge for
 providing usable and secure communication because they are supposed
 to be cheap and very easy to set up, ideally as easy as their "dumb"
 predecessors.  The example of IP-enabled light bulbs shows that the
 more constrained devices are, the more difficult it is to get
 security right.  For this reason, and the required usability, light
 bulbs might just be the perfect example for examining the viability
 of security solutions.
 Rudolf van der Berg focused on large-scale deployments of smart
 objects, such as eBook readers, smart meters, and automobiles.  The
 use of mobile cellular networks is attractive because they are
 networks with adequate coverage and capacity on a global scale.  In
 order to make use of mobile networks, you need to make use of
 authentication based on Subscriber Identity Modules (SIMs).  However,
 at this moment, the SIM is controlled by the network operator.  These
 companies could also use EAP-SIM (Extensible Authentication Protocol
 SIM) [RFC4186] authentication in, for example, wireless LANs.
 The end-user interaction may differ depending on the credentials
 being used: for a light bulb deployed in the user's home, it is
 expected that the user somehow configures devices so that only, for
 example, family members can turn them on and off.  Smart objects that
 are equipped with SIM-based credential infrastructure do not require
 credential management by the end user since credential management by
 the operator can be assumed.  Switching cellular operators may,
 however, pose challenges for these devices.

Gilger & Tschofenig Informational [Page 5] RFC 7397 Smart Object Security Workshop December 2014

 Furthermore, we have a technology that will be both deployed by end
 users and large enterprise customers.  While the protocol building
 blocks may be the same, there is certainly a big difference between
 deployments for large-scale industrial applications and deployments
 for regular end users in terms of the architecture.  Between these
 two, the security requirements differ significantly, as do the
 threats.  It is difficult, if not impossible, to develop a single
 security architecture that fulfills the needs of all users while at
 the same time meeting the constraints of all kinds of smart objects.
 In the consumer market, security should not incur any overhead during
 installation.  If an end user has to invest more time or effort to
 secure a smart object network, he or she will likely not do it.
 Consumer products will often be retrofitted into the existing
 infrastructure, bought, and installed by consumers themselves.  This
 means that devices will have to come pre-installed to some extent and
 will most likely interoperate only with the infrastructure provided
 by the vendor, i.e., the devices will be able to connect to the
 Internet but will only interoperate with the servers provided by the
 vendor selling the device.
 Closed systems (one bulb, one switch) typically work out of the box,
 as they have been extensively tested and often come with factory-
 configured security credentials.  Problems do arise when additional
 devices are added or when these closed systems get connected to the
 Internet.  It is still very common to ship devices with default
 passwords.  It is, however, not acceptable that a device is in a
 vulnerable, but Internet-connected, state before it has been
 correctly configured by a consumer.  It is easy to conceive that many
 consumers do not configure their devices properly and may therefore
 make it easy for an adversary to take control of the device by, for
 example, using the default password or outdated firmware.
 Once security threats for a specific deployment scenario have been
 identified, an assessment takes place to decide what security
 requirements can be identified and what security properties are
 desirable for the solution.  As part of this process, a conscious
 decision needs to take place about which countermeasures will be used
 to mitigate certain threats.  For some security threats, the
 assessment may also lead to the conclusion that the threat is
 considered out-of-scope and, therefore, no technical protection is
 applied.  Different businesses are likely to come to different
 conclusions about the priorities for protection and what security
 requirements will be derived.
 Which security threats are worthwhile to protect against is certainly
 in the eye of the beholder and remains an entertaining discussion
 even among security specialists.  For some of the workshop

Gilger & Tschofenig Informational [Page 6] RFC 7397 Smart Object Security Workshop December 2014

 participants, the security threats against a smart lighting system
 were considered relatively minor compared to other smart home
 appliances.  Clearly, the threats depend on the specific application
 domain, but there is a certain danger that deployments of vulnerable
 smart objects will increase.  As the systems evolve and become more
 pervasive, additional security features may be required and may be
 difficult to incorporate into the already installed base,
 particularly if smart objects have no software update mechanism
 incorporated in their initial design.  Smart objects that require
 human interaction to perform software updates will likely be
 problematic in the future.  This is particularly true for devices
 that are expected to have service schedules of five to twenty-five
 years.  Experience shows that security breaches that are considered
 pranks usually evolve very rapidly to become destructive attacks.
 Apart from the security requirements of individual households and
 users, it is also important to look at the implications of
 vulnerabilities in large-scale smart object deployments, for example,
 in smart meters and the power grid.
 Finally, there is the usual wealth of other requirements that need to
 be taken into account, such as ability for remote configuration and
 software updates, the ability to deal with transfer of ownership of a
 device, avoidance of operator or vendor lock-in, crypto agility,
 minimal production, license and IPR costs, etc.

3.2. Implementation Experience

 The second slot of the workshop was dedicated to reports from first-
 hand implementation experience.  Various participants had provided
 position papers exploring different security protocols and
 cryptographic primitives.  There were three invited talks that
 covered tiny implementations of the Constrained Application Protocol
 (CoAP) protected by Datagram Transport Layer Security (DTLS), a TLS
 implementation using raw public keys, and general experience with
 implementing public key cryptography on smart object devices.
 All three presenters demonstrated that implementations of IETF
 security protocols on various constraint devices are feasible.  This
 was confirmed by other workshop participants as well.  The overall
 code size and performance of finished implementations will depend on
 the chosen feature set.  It is fairly obvious that more features
 translate to a more complex outcome.  Luckily, IETF security
 protocols in general (and TLS/DTLS is no exception) can be customized
 in a variety of ways to fit a specific deployment environment.  As
 such, an engineer will have to decide which features are important
 for a given deployment scenario and what trade-offs can be made.
 There was also the belief that IETF security protocols offer useful

Gilger & Tschofenig Informational [Page 7] RFC 7397 Smart Object Security Workshop December 2014

 customization features (such as different ciphersuites in TLS/DTLS)
 to select the desired combination of algorithms and cryptographic
 primitives.  The need to optimize available security protocols
 further or to even develop new cryptographic primitives for smart
 objects was questioned and not seen as worthwhile by many
 participants.
 The three common constraints for security implementations on smart
 objects are code size, energy consumption, and bandwidth.  The
 importance of tailoring a solution to one of these constraints
 depends on the specific deployment environment.  It might be
 difficult to develop a solution that addresses all constraints at the
 same time.  For example, minimizing memory use may lead to increased
 communication overhead.
 Waiting for the next generation of hardware typically does not
 magically lift the constraints faced today.  The workshop
 participants again reinforced the message that was made at the
 earlier smart object workshop [RFC6574] regarding future developments
 in the smart object space:
    While there are constantly improvements being made, Moore's law
    tends to be less effective in the embedded system space than in
    personal computing devices: gains made available by increases in
    transistor count and density are more likely to be invested in
    reductions of cost and power requirements than into continual
    increases in computing power.
 The above statement is applicable to smart object designs in general,
 not only for security.  Thus, it is expected that designers will
 continue having to deal with various constraints of smart objects in
 the future.  A short description of the different classes of smart
 objects can be found in [RFC7228], which also provides security-
 related guidance.  The workshop participants noted that making
 security protocols suitable for smart objects must not water down
 their effectiveness.  Security functionality will demand some portion
 of the overall code size.  It will have an impact on the performance
 of communication interactions, lead to higher energy consumption, and
 certainly make the entire product more complex.  Still, omitting
 security functionality because of various constraints is not an
 option.  The experience with implementing available security
 protocols was encouraging even though the need to make various
 architectural design decisions for selecting the right set of
 protocols and protocol extensions that everyone must agree on was
 pointed out.  Sometimes, the leading constraint is energy
 consumption, and in other cases, it is main memory, CPU performance,

Gilger & Tschofenig Informational [Page 8] RFC 7397 Smart Object Security Workshop December 2014

 or bandwidth.  In any case, for an optimization, it is important to
 look at the entire system rather than a single protocol or even a
 specific algorithm.
 Equally important to the code size of the protocols being used in a
 deployed product are various other design decisions, such as the
 communication model, the number of communication partners, the
 interoperability requirements, and the threats that are being dealt
 with.  Mohit Sethi noted that even the execution time for relatively
 expensive operations like asymmetric signature generation and
 verification are within acceptable limits for very constrained
 devices, like an Arduino UNO.  In either case, public key
 cryptography will likely only be used for the initial communication
 setup to establish symmetric session keys.  Perhaps surprisingly, the
 energy cost of transmitting data wirelessly dwarfs even expensive
 computations like public key cryptography.  Since wireless reception
 is actually the most power-consuming task on a smart object,
 protocols have to be designed accordingly.
 The workshop participants shared the view that the complexity of
 security protocols is a result of desired features.  Redesigning a
 protocol with the same set of features will, quite likely, lead to a
 similar outcome in terms of code size, memory consumption, and
 performance.  It was, however, also acknowledged that the security
 properties offered by DTLS/TLS/IKEv2-IPsec may not be needed for all
 deployment environments.  DTLS, for example, offers an authentication
 and key exchange framework combined with channel security offering
 data-origin authentication, integrity protection, and (optionally)
 confidentiality protection.
 The biggest optimization in terms of code size can be gained when
 looking at the complete protocol stack, rather than only
 cryptographic algorithms.  This also includes software update
 mechanisms and configuration mechanisms, all of which have to work
 together.  What may not have been investigated enough is the
 potential of performing cross-layer and cross-protocol optimization.
 We also need to think about how many protocols for security setup we
 want to have.  Due to the desire to standardize generic building
 blocks, the ability to optimize for specific deployment environments
 has been reduced.
 Finally, it was noted that scalability of security protocols does not
 imply usability.  This means that while smart object technology might
 currently be developed in large-scale industrial environments, it
 should be equally usable for consumers who want to equip their home
 with just a few light bulbs.

Gilger & Tschofenig Informational [Page 9] RFC 7397 Smart Object Security Workshop December 2014

 For details about the investigated protocol implementations, please
 consult the position papers, such as the ones by Bergmann et al.,
 Perelman et al., Tschofenig, and Raza et al. (see Appendix C).

3.3. Authorization

 The discussion slot on authorization was meant to provide an idea of
 what kind of authorization decisions are common in smart object
 networks.  Authorization is defined as an "approval that is granted
 to a system entity to access a system resource" [RFC4949].
 Authorization requires a view on the entire smart object lifecycle to
 determine when and how a device was added to a specific environment,
 what permissions have been granted for this device, and how users are
 allowed to interact with it.  On a high level, there are two types of
 authorization schemes.  First, there are those systems that utilize
 an authenticated identifier and match it against an access control
 list.  Second, there are trait-based authorization mechanisms that
 separate the authenticated identifier from the authorization rights
 and utilize roles and other attributes to determine whether to grant
 or deny access to a protected resource.
 Richard Barnes looked at earlier communication security work and
 argued that the model that dominates the web today will not be enough
 for the smart object environment.  Simply identifying users by their
 credentials and servers via certificates is not something that
 translates well to smart object networks because it binds all the
 capabilities to the credentials.  The evolution in access control is
 moving in the direction of granting third parties certain
 capabilities, with OAuth [RFC6749] being an example of a currently
 deployed technology.  Access to a resource using OAuth can be done
 purely based on the capabilities rather than on the authenticated
 identifier.
 At the time of the workshop, OAuth was very much focused on
 HTTP-based protocols with early efforts to integrate OAuth into the
 Simple Authentication and Security Layer (SASL) and the Generic
 Security Service Application Program Interface (GSS-API)
 [SASL-OAUTH].  Further investigations need to be done to determine
 the suitability of OAuth as a protocol for the smart object
 environment.
 Richard believed that it is important to separate authentication from
 authorization right from the beginning and to consider how users are
 supposed to interact with these devices to introduce them into their
 specific usage environment (and to provision them with credentials)
 and to manage access from different parties.

Gilger & Tschofenig Informational [Page 10] RFC 7397 Smart Object Security Workshop December 2014

 The relationship between the policy enforcement point and the policy
 decision point plays an important role regarding the standardization
 needs and the type of information that needs to be conveyed between
 these two entities.
 For example, in an Authentication, Authorization, and Accounting
 (AAA) context, the authorization decision happens at the AAA server
 (after the user requesting access to a network or some application-
 level services had been authenticated).  Then, the decision about
 granting access (or rejecting it) is communicated from the AAA server
 to the AAA client at the end of the network access authentication
 procedure.  The AAA client then typically enforces the authorization
 decision over the lifetime of the granted user session.  The dynamic
 authorization extension [RFC5176] to the RADIUS protocol, for
 example, also allows the RADIUS server to make dynamic changes to a
 previously granted user session.  This includes support for
 disconnecting users and changing authorizations applicable to a user
 session.
 The authorization decisions can range from 'only devices with
 passwords can use the network' to very detailed application-specific
 authorization policies.  The decisions are likely to be more
 sophisticated in those use cases where ownership of devices may be
 transferred from one person to another one, group membership concepts
 may be needed, access rights may be revocable, and fine-grained
 access rights have to be used.  The authorization decisions may also
 take environmental factors into account, such as proximity of devices
 to each other, physical location of the device asking access, or the
 level of authentication.  With the configuration of authorization
 policies, questions arise regarding who will create them and where
 these policies are stored.  This immediately raises questions about
 how devices are identified and who is allowed to create these
 policies.
 Since smart objects may be limited in terms of code size, persistent
 storage, and Internet connectivity, established authorization schemes
 may not be well suited for such devices.  Obviously, delegating every
 authorization decision to another node in the network incurs a
 certain network overhead, while storing sophisticated access control
 policies directly on the smart object might be prohibitive because of
 the size of such a ruleset.  Jan Janak presented one approach to
 distribute access control policies to smart objects within a single
 administrative domain.
 In those cases where access control decisions are bound to the
 identifiers of devices and humans need to either create or verify
 these access control policies, the choice of identifier matters for
 readability and accessibility purposes.

Gilger & Tschofenig Informational [Page 11] RFC 7397 Smart Object Security Workshop December 2014

 A single mechanism will likely not help with solving the wide range
 of authorization tasks.  From the discussions, it was not clear
 whether there is a need for new authorization mechanisms or whether
 existing mechanisms can be reused.  Examples of available protocols
 with built-in authorization mechanisms are Kerberos, OAuth, EAP/AAA,
 attribute certificates, etc.  In many cases, it is even conceivable
 that the authorization decisions are internal to the system and that
 there is no need to standardize any additional authorization
 mechanisms or protocols at all.  In fact, many of the authentication
 and key exchange protocols have authorization mechanisms built in.

3.4. Provisioning of Credentials

 When a smart object is to be introduced into an environment, like a
 home or an enterprise network, it usually has to be provisioned with
 some credentials first.  The credentials that are configured at the
 smart object and at some entity in the network are often an implicit
 authorization to access the network or some other resource.  The
 provisioned information at the smart object will include some
 identifier of the smart object, keying material, and other
 configuration information (e.g., specific servers it has to interact
 with).
 Some devices will be pre-configured with default security codes or
 passwords, or will have per-device or per-user credentials
 pre-configured, when they are bought or when they arrive at the
 customer.
 There is a limited set of solutions available (based on the available
 interface support).  The solutions for imprinting vary between the
 enterprise and the consumer household scenarios.  For large-scale
 deployments, the time needed to pair two objects further excludes
 other schemes that rely on manual steps.
 Johannes Gilger dealt with the very basic ideas behind pairing
 schemes, including the kinds of out-of-band channels that could be
 employed and their limitations.  Imprinting and pairing protocols
 usually establish a security association between two equal devices,
 such as Bluetooth-equipped cell phones.  To deal with man-in-the-
 middle attacks during this phase, various forms of additional
 verification checks exist.  For example, devices with a display allow
 numeric values to be shown on each device and let the user verify
 whether they match.  For other devices that have a keypad, a PIN may
 need to be entered by the user.  Where and how a smart object is to
 be paired with other devices in the network can differ substantially
 from the specific use cases and the hardware capabilities of devices.
 Note that pairing is not necessarily something that is only done once

Gilger & Tschofenig Informational [Page 12] RFC 7397 Smart Object Security Workshop December 2014

 during the lifetime of a device.  Is group pairing something to be
 looked at?  Or can any group key establishment be reduced to pairwise
 pairing with a central master device?
 Cullen Jennings presented a model for smart objects based on a
 deployment used for IP phones.  The idea was that the smart object
 "phones home", i.e., contacts a server offered by the manufacturer,
 when it is first switched on.  This initial interaction can then be
 used for managing the device and provisioning keying material for
 further use.  Proof of ownership could be done by identifying the
 user who purchased the device.  This is an approach that is
 increasingly being done today.  Another option is some kind of secret
 information enclosed in the packaging.
 For interface-constrained devices, the solution of using (semi)-
 public information in combination with an online manufacturer during
 imprinting seems like a possible solution.  This solution approach
 created a lot of discussion among the participants, as it assumes an
 Internet connection and means that the manufacturer effectively knows
 about the trust relationships of all the devices it sells.
 A few questions did arise with such a model: Will there be third
 parties that have a business interest in providing something like key
 distribution and key escrow over the lifetime of a smart object?  For
 constrained devices, will it always be possible to fall back to the
 existing security associations between device and manufacturer to
 create new associations?  Obviously, we do not want the lifetime of a
 smart object limited by the manufacturer product support lifespan.
 What happens if a manufacturer goes bankrupt, changes its business
 scope, or gets bought by another company?  Will end customers not be
 able to use their smart objects anymore in such a case, or will they
 lose the ability to resell their devices because the ownership can no
 longer be transferred?
 One important design decision is that the compromise of the
 manufacturer must not have any impact on the smart objects, which
 have already been imprinted to their new owners.  Furthermore, the
 question arises of how to transfer ownership, e.g., when reselling a
 device.  While this may not be a requirement for all devices, there
 will likely be classes of large or expensive devices where support
 for transferring the ownership is an absolute necessity.
 Industrial users are comfortable when they have to rely on the
 manufacturer during the imprinting phase, but they want to be in
 exclusive control over their devices afterwards.

Gilger & Tschofenig Informational [Page 13] RFC 7397 Smart Object Security Workshop December 2014

 There are many classes of devices where we could assume online
 connectivity to be present; otherwise, these devices would not make
 sense in the first place.  But, there are also other devices that
 need to be imprinted completely offline.
 Is it important to worry about security vulnerabilities, such as
 man-in-the-middle attacks, during the very short imprinting phase?
 Is it realistic that an adversary is in close proximity to mount an
 attack?  Especially for devices with limited capabilities, such as
 light bulbs, the concerns seemed rather small.
 What happens if such a device is not enrolled by the customer but
 still connected in a "naked" state?  How does this impact security,
 and is it possible for an attacker to perform a "drive-by" enrollment
 procedure of many devices?  How should a device behave in this
 situation?  The safest option (for the user at least) would be to not
 allow the device to work with full functionality if it has not been
 enrolled.  This concern is particularly applicable for cases where
 smart objects are sold with default passwords or passwords using
 semi-public information; an example is Raspberry Pi computers with
 Linux images that use a default password [RaspberryPi].

4. Summary

 Designing for a smart object environment is about making an
 optimization decision that needs to take technical aspects, usage
 scenarios, security threats, and business models into account.  Some
 design constraints may be considered fixed while others are flexible.
 Compromises will need to be made, but they should not be made at the
 expense of security functionality.
 Designing a software update mechanism into the system is crucial to
 ensure that functionality can be enhanced and vulnerabilities can be
 fixed.  Also, security threats are perceived differently over time.
 For example, many people considered pervasive monitoring less
 important prior to the Snowden revelations.
 New research and standardization on cryptographic algorithms (like
 encryption algorithms, hash functions, keyed message digests, and
 public key crypto systems) that are tailored to smart object
 environments was not seen as worthwhile by the participants.  A huge
 range of algorithms already exist, and standardized authentication
 and key exchange protocols can be customized to use almost any
 selection of algorithms available today.
 The integration of various building blocks into a complete system was
 considered important, and this document highlights a number of those
 areas in Section 3.  Searching for a single, universally applicable

Gilger & Tschofenig Informational [Page 14] RFC 7397 Smart Object Security Workshop December 2014

 smart object security architecture was seen as a hopeless journey
 given the large number of use cases, business models, and
 constraints.
 In response to the workshop, follow-up work happened in a number of
 areas (and standardization activities are still ongoing).  Here are a
 few examples:
 o  The Light-Weight Implementation Guidance (LWIG) working group was
    created to offer a venue to collect experiences from implementers
    of IP stacks, including security protocols, in constrained
    devices.  The ability to tune IETF protocols via extensions and
    parameter choices gives implementers a lot of flexibility to meet
    the constraints of a smart object environment.
 o  The DTLS In Constrained Environments (DICE) working group was
    formed to define a DTLS profile that is suitable for Internet of
    Things applications and is reasonably implementable on many
    constrained devices, and to define how the DTLS record layer can
    be used to transmit multicast messages securely.  DTLS is seen as
    an important enabling technology for securing communication
    interactions by smart objects.
 o  A new working group has been formed to standardize an
    authentication and authorization protocol for constrained
    environments offering a dynamic and fine-grained access control
    mechanism where clients and resource servers are constrained and
    therefore have to make use of a trusted third party.  At the time
    of writing this document, the Authentication and Authorization for
    Constrained Environments (ACE) working group has just been
    started.

5. Security Considerations

 This whole document is a report on the 'Smart Object Security
 Workshop'.  The focus of this workshop was on security only; privacy
 was not part of the workshop agenda.

Gilger & Tschofenig Informational [Page 15] RFC 7397 Smart Object Security Workshop December 2014

6. References

6.1. Normative References

 [RFC6574]  Tschofenig, H. and J. Arkko, "Report from the Smart Object
            Workshop", RFC 6574, April 2012,
            <http://www.rfc-editor.org/info/rfc6574>.

6.2. Informative References

 [PaulChilton]
            Chilton, P., "Experiences and Challenges in using
            constrained Smart Objects", March 2012,
            <http://www.lix.polytechnique.fr/hipercom/
            SmartObjectSecurity/papers/PaulChilton.pdf>.
 [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
            Text on Security Considerations", BCP 72, RFC 3552,
            July 2003, <http://www.rfc-editor.org/info/rfc3552>.
 [RFC4101]  Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101,
            June 2005, <http://www.rfc-editor.org/info/rfc4101>.
 [RFC4186]  Haverinen, H. and J. Salowey, "Extensible Authentication
            Protocol Method for Global System for Mobile
            Communications (GSM) Subscriber Identity Modules
            (EAP-SIM)", RFC 4186, January 2006,
            <http://www.rfc-editor.org/info/rfc4186>.
 [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
            RFC 4949, August 2007,
            <http://www.rfc-editor.org/info/rfc4949>.
 [RFC5176]  Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B.
            Aboba, "Dynamic Authorization Extensions to Remote
            Authentication Dial In User Service (RADIUS)", RFC 5176,
            January 2008, <http://www.rfc-editor.org/info/rfc5176>.
 [RFC6272]  Baker, F. and D. Meyer, "Internet Protocols for the Smart
            Grid", RFC 6272, June 2011,
            <http://www.rfc-editor.org/info/rfc6272>.
 [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
            RFC 6749, October 2012,
            <http://www.rfc-editor.org/info/rfc6749>.

Gilger & Tschofenig Informational [Page 16] RFC 7397 Smart Object Security Workshop December 2014

 [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
            Constrained-Node Networks", RFC 7228, May 2014,
            <http://www.rfc-editor.org/info/rfc7228>.
 [RaspberryPi]
            Raspberry Pi Foundation, "Raspberry Pi", February 2013,
            <http://www.raspberrypi.org>.
 [SASL-OAUTH]
            Mills, W., Showalter, T., and H. Tschofenig, "A set of
            SASL Mechanisms for OAuth", Work in Progress,
            draft-ietf-kitten-sasl-oauth-18, November 2014.
 [SMART-OBJECT]
            Tschofenig, H., Arkko, J., Thaler, D., and D. McPherson,
            "Architectural Considerations in Smart Object Networking",
            Work in Progress, draft-iab-smart-object-architecture-06,
            October 2014.

Gilger & Tschofenig Informational [Page 17] RFC 7397 Smart Object Security Workshop December 2014

Appendix A. Program Committee

 The workshop was organized by the following individuals:
 o  Hannes Tschofenig
 o  Jari Arkko
 o  Carsten Bormann
 o  Peter Friess
 o  Cullen Jennings
 o  Antonio Skarmeta
 o  Zach Shelby
 o  Thomas Heide Clausen

Appendix B. Published Workshop Material

 o  Main Workshop Page
    <http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity>
 o  Position Papers
    <http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/
    papers>
 o  Slides
    <http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/
    slides>

Appendix C. Accepted Position Papers

 1.   Michael Richardson, "Challenges in Smart Object Security: too
      many layers, not enough ram"
 2.   Mitsuru Kanda, Yoshihiro Ohba, Subir Das, Stephen Chasko, "PANA
      applicability in constrained environments"
 3.   Randy Bush, "An Operational View of Trust Needs of Moving
      Objects"
 4.   Andrei Gurtov, Ilya Nikolaevsky, Andrey Lukyanenko, "Using HIP
      DEX for Key Management and Access Control in Smart Objects"
 5.   Jens-Matthias Bohli, "Access Tokens for the IoT"
 6.   Martina Brachmann, Oscar Garcia-Morchon, Sye-Loong Keoh, Sandeep
      S. Kumar, "Security Considerations around End-to-End Security in
      the IP-based Internet of Things"
 7.   Kazunori Miyazawa, "Convergence of Smart Objects in industrial
      wireless sensor network"

Gilger & Tschofenig Informational [Page 18] RFC 7397 Smart Object Security Workshop December 2014

 8.   Thomas Bartzsch, Dirk Burggraf, Laura Cristina Gheorghe, Alexis
      Olivereau, Nouha Oualha, Emil Slusanschi, Dan Tudose, Markus
      Wehner, Sven Zeisberg, "AAA-based Infrastructure for Industrial
      Wireless Sensor Networks"
 9.   Fida Khattak, Philip Ginzboorg, Valtteri Niemi, Jan-Erik Ekberg,
      "Role of Border Router in 6LoWPAN Security"
 10.  Thomas Fossati, Angelo Castellani, Salvatore Loreto,
      "(Un)trusted Intermediaries in CoAP"
 11.  Rene Hummen, Christian Roeller, Klaus Wehrle, "Modeling User-
      defined Trust Overlays for the IP-based Internet of Things"
 12.  Sam Hartman, Margaret Wasserman, "Federation, ABFAB and Smart
      Devices"
 13.  Cary Bran, Joseph Stachula, "Device Pairing: Lessons Learned"
 14.  Jan Janak, Hyunwoo Nam, Henning Schulzrinne, "On Access Control
      in the Internet of Things"
 15.  Rene Struik, "Cryptography and Security for Highly Constrained
      Networks"
 16.  Zhen Cao, Hui Deng, Judy Zhu, "The Architecture of Open Security
      Capability"
 17.  Sujing Zhou, Zhenhua Xie, "On Cryptographic Approaches to
      Internet-Of-Things Security"
 18.  Nancy Cam-Winget, Monique Morrow, "Security Implications to
      Smart Addressable Objects"
 19.  Jouni Korhonen, "Applying Generic Bootstrapping Architecture for
      use with Constrained Devices"
 20.  Olaf Bergmann, Stefanie Gerdes, Carsten Bormann, "Simple Keys
      for Simple Smart Objects"
 21.  Mohit Sethi, Jari Arkko, Ari Keranen, Heidi-Maria Rissanen,
      "Practical Considerations and Implementation Experiences in
      Securing Smart Object Networks"
 22.  Paul Chilton, "Experiences and Challenges in using constrained
      Smart Objects"

Gilger & Tschofenig Informational [Page 19] RFC 7397 Smart Object Security Workshop December 2014

 23.  Vladislav Perelman, Mehmet Ersue, "TLS with PSK for Constrained
      Devices"
 24.  Richard Barnes, "Security for Smart Objects beyond COMSEC:
      Principals and Principles"
 25.  Rudolf van der Berg, "OECD Publication on Machine-to-Machine
      Communications: Connecting Billions of Devices", OECD Digital
      Economy Papers, No. 192, OECD Publishing
 26.  Cullen Jennings, "Transitive Trust Enrollment for Constrained
      Devices"
 27.  Barbara Fraser, Paul Duffy, Maik Seewald, "Smart Objects:
      Security Challenges from the Power Sector"
 28.  Hannes Tschofenig, "Smart Object Security: Considerations for
      Transport Layer Security Implementations"
 29.  Johannes Gilger, Ulrike Meyer, "Secure Pairing & Context
      Management"
 30.  Klaas Wierenga, "Scalable Authentication for Smart Objects"
 31.  Dirk Stegemann, Jamshid Shokrollahi, "Security in the Internet
      of Things - Experiences from Use Cases"
 32.  Alper Yegin, "Credentials for Smart Objects: A Challenge for the
      Industry"
 33.  Shahid Raza, Thiemo Voigt, Vilhelm Jutvik, "Lightweight IKEv2: A
      Key Management Solution for both the Compressed IPsec and the
      IEEE 802.15.4 Security"
 34.  Eric Rescorla, "A Brief Survey of Imprinting Options for
      Constrained Devices"
 35.  Fred Baker, "Security in distributed telemetry and control
      networks"

Gilger & Tschofenig Informational [Page 20] RFC 7397 Smart Object Security Workshop December 2014

Appendix D. Workshop Participants

 We would like to thank the following participants for attending the
 workshop:
 o  Jari Arkko
 o  Carsten Bormann
 o  Cullen Jennings
 o  Antonio Skarmeta
 o  Sean Turner
 o  Thomas Heide Clausen
 o  Hannes Tschofenig
 o  Michael Richardson
 o  Yoshihiro Ohba
 o  Subir Das
 o  Randy Bush
 o  Andrei Gurtov
 o  Ilya Nikolaevsky
 o  Andrey Lukyanenko
 o  Jens-Matthias Bohli
 o  Kazunori Miyazawa
 o  Philip Ginzboorg
 o  Fida Khattak
 o  Angelo Castellani
 o  Salvatore Loreto
 o  Rene Hummen
 o  Klaus Wehrle
 o  Sam Hartman
 o  Margaret Wasserman
 o  Cary Bran
 o  Jan Janak
 o  Rene Struik
 o  Zhen Cao
 o  Hui Deng
 o  Zhou Sujing
 o  Xie Zhenhua
 o  Monique Morrow
 o  Nancy Cam-Winget
 o  Jouni Korhonen
 o  Ari Keranen
 o  Paul Chilton
 o  Vladislav Perelman
 o  Mehmet Ersue
 o  Richard Barnes
 o  Rudolf van der Berg
 o  Barbara Fraser
 o  Johannes Gilger
 o  Sye Loong Keoh

Gilger & Tschofenig Informational [Page 21] RFC 7397 Smart Object Security Workshop December 2014

 o  Olaf Bergmann
 o  Stefanie Gerdes
 o  Klaus Hartke
 o  Oualha Nouha
 o  Alexis Olivereau
 o  Alper Yegin
 o  Klaas Wierenga
 o  Jiazi Yi
 o  Juan Antonio Cordero Fuertes
 o  Antonin Bas
 o  David Schinazi
 o  Valerie Lecomte
 o  Ulrich Herberg
 o  Shahid Raza
 o  Stephen Farrell
 o  Eric Rescorla
 o  Thomas Fossati
 o  Mohit Sethi
 o  Alan Duric
 o  Guido Moritz
 o  Sebstian Unger
 o  Hans Loehr

Acknowledgements

 We would like to thank the participants and the authors of the
 position papers for their input.
 Special thanks go to Thomas Heide Clausen and Ecole Polytechnique
 (Paris) for providing the venue and organization.
 Finally, we would like to thank Rudolf van der Berg for his review
 comments.

Gilger & Tschofenig Informational [Page 22] RFC 7397 Smart Object Security Workshop December 2014

Authors' Addresses

 Johannes Gilger
 Mies-van-der-Rohe-Str. 15
 Aachen  52074
 Germany
 Phone: +49 (0)241 80 20 781
 EMail: Gilger@ITSec.RWTH-Aachen.de
 Hannes Tschofenig
 Hall in Tirol  6060
 Austria
 EMail: Hannes.tschofenig@gmx.net
 URI:   http://www.tschofenig.priv.at

Gilger & Tschofenig Informational [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7397.txt · Last modified: 2014/12/13 00:46 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki