RFC 7397

Report from the Smart Object Security Workshop

📅 published December 2014, from ietf

Report from the Smart Object Security Workshop 🦋

Okay bestie, the title block tells us this is RFC 7397, an Independent Submission written by J. Gilger and H. Tschofenig 💖 It's in the Informational category and dates from December 2014 📅 Its ISSN is 2070-1721. The header doesn't list anything that it obsoletes or updates, so it's a standalone read ✨

Abstract ✨

This document is a recap of a workshop on 'Smart Object Security' that happened in Paris on March 23, 2012 🇫🇷 The big goal was to get participants sharing their thoughts on whether we can use the security mechanisms that already exist and are widely deployed for smart objects 🧚

The report sums up the discussions and lists the conclusions and recommendations it made for the Internet Engineering Task Force (IETF) community 💅

Status of This Memo

Let's be real, this is not an Internet Standards Track specification. It's published purely for informational purposes 🌸

It's a contribution to the RFC Series that's independent of any other RFC stream. The RFC Editor picked it for publication at their discretion and makes no statement about its value for implementation or deployment 🙈 Docs the RFC Editor approves for publication are not candidates for any level of Internet Standard, see Section 2 of RFC 5741 📚

Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc7397 🔗

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions with respect to this document 🫶

   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 🎀

Okay so, back in early 2011 the Internet Architecture Board (IAB) asked for position statements for a workshop called 'Interconnecting Smart Objects with the Internet' 🌈 The aim was to hear from the wider Internet community about their experience deploying IETF protocols in constrained environments. That workshop happened in Prague on March 25, 2011, and the topics were all over the place: architecture, routing, energy efficiency, and security ⚡ RFC 6574 [RFC6574] wraps up that discussion and suggests several next steps 📝

In the months after that workshop, some new IETF initiatives popped up, like the Light-Weight Implementation Guidance (LWIG) working group. Hackathons were also organized at IETF 80 and IETF 81 so people could swap ideas more easily 🦋

Contributions on security from the IETF Constrained RESTful Environments (CoRE) working group and the IETF Transport Layer Security (TLS) working group made it super clear that security needed more discussion 😭 That talk had to include implementation and deployment experience, plus a shared understanding of how the different building blocks fit into a bigger architecture 🧩

So the 'Smart Object Security' workshop was organized to pull together a bunch of scattered conversations about smart object security happening in different IETF working groups and industry fora 💅 It was a one-day workshop held before IETF 83 in Paris, on March 23, 2012 🇫🇷

The organizers really wanted input on the following topics, as laid out in the call for position papers:

What techniques for issuing credentials have been deployed?
What extensions are useful to make existing security protocols more suitable for smart objects?
What type of credentials are frequently used?
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)?
How can "clever" implementations make security protocols a better fit for constrained devices?
Are there lessons we can learn from existing deployments?

This document lists some of the topics that came up again and again at the workshop 🍓 It also shares recommendations from the workshop participants ✨

Note that this document is a report on the proceedings of the workshop. The views and positions in this report belong to the workshop participants. They 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 💜

Okay this part is giving main character energy 👑 There were 35 accepted position papers, so there was a LOT to talk about in one day 😭 The program committee split 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 get things rolling 🔥 This section sums up the points the invited speakers raised, plus the essence of the discussions that followed 💅

3.1. Requirements and Use Cases ✨

okay bestie, when you're designing a security solution, the first move is figuring out who's talking to who 💬, what the constraints are 🚧, and what security threats are lurking 👀. The typical IETF Security Considerations section only looks at threats, requirements, and solutions for one protocol or one document 📄. But for a smart object deployment you have to zoom way out and look at the whole ecosystem 🌍. The security analysis in [RFC3552] and in [RFC4101] still gives super valuable guidance 💅

The big questions that pop up are:

Who are the involved actors? 🎭

Some usage scenarios look super simple at first, but after a longer investigation they turn out to be quite complex 🌀. The smart meter deployment, for example, is honestly one of the more complex ones because of the history of the energy sector (see [RFC6272]) ⚡

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 🫶

What constraints are imposed on the design? 🧱

For example, one 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 whether end-to-end security to servers in the Internet is required 🤔. A more detailed discussion can be found at [SMART-OBJECT] 📚

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 they may consist of complex, role-based access control policies 🎚️

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 is definitely going up constantly 📈, but user-interface challenges contribute to a large number of security weaknesses of the Internet, so they have to be taken into account 🙈

To illustrate the differences, think about a mass-market deployment for end customers compared to a deployment that targets enterprise customers 🏢. In the enterprise case, system administrators are likely to use 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 are a huge 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 harder it is to get security right 😭. For this reason, and because of the required usability, light bulbs might just be the perfect example for testing 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 🚗. Mobile cellular networks are attractive because they have adequate coverage and capacity on a global scale 🌍. To make use of mobile networks, you need to use authentication based on Subscriber Identity Modules (SIMs) 📱. At this moment, though, 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 😬

Furthermore, this is a technology that will be deployed by both 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 architecture 🏗️. Between these two, the security requirements differ significantly, and so do the threats 🔥. It is difficult, if not impossible, to develop a single security architecture that fulfills the needs of all users while also 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, they will likely not do it 🙃. Consumer products will often be retrofitted into existing infrastructure, bought, and installed by consumers themselves 🛒. This means devices will have to come pre-installed to some extent, and they will most likely interoperate only with the infrastructure provided by the vendor. In other words, 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, since they have been extensively tested and often come with factory-configured security credentials 📦. The problems come 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 for a device to be in a vulnerable, but Internet-connected, state before it has been correctly configured by a consumer 🚨. It's easy to imagine many consumers not configuring their devices properly, which may 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 which security requirements can be identified and which security properties are desirable for the solution 📝. As part of this process, a conscious decision needs to be made 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 out-of-scope and, therefore, no technical protection is applied 🙅‍♀️. Different businesses are likely to reach different conclusions about the priorities for protection and about which security requirements will be derived 💼

Which security threats are worth protecting against is certainly in the eye of the beholder, and it remains an entertaining debate even among security specialists 🍿. For some workshop 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 systems evolve and become more pervasive, additional security features may be required, and they may be difficult to incorporate into the already installed base, particularly if smart objects have no software update mechanism built into their initial design 🔧. Smart objects that require human interaction to perform software updates will likely be problematic in the future 😵‍💫. This is especially true for devices that are expected to have service schedules of five to twenty-five years ⏳. Experience shows that security breaches considered "pranks" usually evolve very rapidly into 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 🎁. These include the 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 ✨

okay so the second slot of the workshop was all about real implementation stories 🔧 Like, people who actually built stuff, not just theorizing. Lots of participants sent in position papers about different security protocols and crypto primitives 📝 Then there were three invited talks 🎤: tiny implementations of the Constrained Application Protocol (CoAP) protected by Datagram Transport Layer Security (DTLS) 🌸, a TLS implementation that uses raw public keys 🔑, and general experience with putting public key cryptography on smart object devices 💜

All three presenters showed that running IETF security protocols on constrained devices is totally doable 💅 Other participants confirmed it too, so it's not just one person's win. The overall code size and performance of a finished product depend on which feature set you pick 🎀 Obviously, more features means a more complex result, no cap 😭 The good news? IETF security protocols (TLS and DTLS very much included) can be customized in a bunch of ways to fit a specific deployment environment 🦋 So an engineer has to decide which features actually matter for their scenario and what trade-offs they're willing to make ⚖️ People also felt that these protocols give you useful customization options, like picking different ciphersuites in TLS and DTLS, so you can choose the exact mix of algorithms and cryptographic primitives you want 🧚 Meanwhile, the idea of optimizing existing security protocols even further, or inventing brand-new cryptographic primitives for smart objects, got questioned. Many participants didn't think that was worthwhile 🙈

There are three big constraints for security on smart objects: code size, energy consumption, and bandwidth 🍓 How much each one matters depends on where the device lives. Tackling all three at once can be really hard. For example, minimizing memory use may end up increasing communication overhead 🌈

Here's the thing: waiting for the next generation of hardware typically does not magically make today's constraints disappear 😤 The workshop folks repeated a message from the earlier smart object workshop [RFC6574] about where smart object tech is headed:

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.

This isn't just a security thing. It applies to smart object designs in general 🫶 So designers are going to keep dealing with these constraints for the foreseeable future. If you want a rundown of the different classes of smart objects, check out [RFC7228], which also gives security-related guidance 📚 Participants also pointed out that making security protocols suitable for smart objects must not water them down. Security functionality takes up some of your code size, affects how fast communication happens, uses more energy, and honestly makes the whole product more complicated 💀 Still, skipping security just because of constraints is not an option 🚫 The implementation experience was encouraging, even though people noted that teams need to make architectural design decisions about which protocols and protocol extensions to pick, and everyone has to agree on that set 🤝 Sometimes the biggest constraint is energy consumption, and other times it's main memory, CPU performance, or bandwidth. Either way, if you want to optimize, you have to look at the entire system, not just one protocol or one specific algorithm 👑

Code size isn't the only thing that matters. Other design decisions are just as important: the communication model, the number of communication partners, the interoperability requirements, and the threats being dealt with 👀

Mohit Sethi pointed out that even relatively expensive operations, like generating and verifying asymmetric signatures, take an acceptable amount of time on very constrained devices like an Arduino UNO ⏱️ Still, public key cryptography will likely only be used for the initial communication setup, to establish symmetric session keys 🗝️ Plot twist: the energy cost of sending data wirelessly actually dwarfs even pricey computations like public key crypto 🤯 Since wireless reception is the most power-hungry task on a smart object, protocols have to be designed with that in mind 🔋

The workshop participants agreed that a security protocol's complexity comes from the features you want 🎯 If you redesign a protocol with the same set of features, you'll quite likely end up with a similar outcome for code size, memory consumption, and performance 🔁 It was also acknowledged, though, that the security properties offered by DTLS, TLS, and IKEv2-IPsec may not be needed in every deployment environment 🌸 DTLS, for example, offers an authentication and key exchange framework combined with channel security. That channel security gives you data-origin authentication, integrity protection, and (optionally) confidentiality protection 💖

The biggest code size win comes from looking at the complete protocol stack, not just the cryptographic algorithms 📦 That includes software update mechanisms and configuration mechanisms, and all of them have to work together 🧩 Cross-layer and cross-protocol optimization might not have been explored enough yet, and we also need to think about how many protocols for security setup we actually want 🤔 Because everyone wants to standardize generic building blocks, the ability to optimize for specific deployment environments has been reduced 🙃

Last but not least, scalability of security protocols does not imply usability 🎀 So even though smart object tech might be getting developed in large industrial environments right now, it should be just as usable for consumers who want to equip their home with just a few light bulbs 💡✨

For details about the protocol implementations that were investigated, check out the position papers, like the ones by Bergmann et al., Perelman et al., Tschofenig, and Raza et al. (see Appendix C) 📖🦋

3.3. Authorization ✨

okay so this section was meant to give us a vibe check on what kinds of authorization decisions are common in smart object networks 💅 first up, authorization is defined as an "approval that is granted to a system entity to access a system resource" [RFC4949] 🎀

Authorization needs the whole smart object lifecycle in view 🦋 like, when and how a device got added to an environment, what permissions it was given, and how users are allowed to interact with it 🌸 highkey there are two big types of schemes. First, the ones that take an authenticated identifier and match it against an access control list 📝. Second, the trait-based mechanisms, which split the authenticated identifier from the authorization rights and use roles and other attributes to decide whether to grant or deny access to a protected resource 👑

Richard Barnes looked at older communication security work and argued that the model dominating the web today is not going to be enough for smart object environments 😭 Identifying users by their credentials and servers by their certificates doesn't translate well here, because it binds every capability to the credentials 💀 access control is moving toward granting third parties certain capabilities, and OAuth [RFC6749] is an example of a deployed technology doing that ✨ access through OAuth can be based purely on the capabilities rather than on the authenticated identifier 🫶

At the time of the workshop, OAuth was very focused on HTTP-based protocols, with early efforts to bring it into the Simple Authentication and Security Layer (SASL) and the Generic Security Service Application Program Interface (GSS-API) [SASL-OAUTH] 🧚 more investigation is needed to figure out whether OAuth is a good protocol for smart object environments 🔥

Richard believed it's important to separate authentication from authorization right from the start 💜 he also wanted us to think about how users interact with these devices to bring them into their usage environment (and provision them with credentials), and how to manage access from different parties 🍓

The relationship between the policy enforcement point and the policy decision point matters a lot for standardization needs and for the kind of information that has to be passed 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 asking for access to a network or some application-level services has been authenticated 🦋 the decision to grant (or reject) access is then communicated from the AAA server to the AAA client at the end of the network access authentication procedure 💖 the AAA client typically enforces that decision for the lifetime of the granted user session ✨ the dynamic authorization extension [RFC5176] to RADIUS, for example, also lets the RADIUS server make dynamic changes to a session that's already granted 🔥 that includes disconnecting users and changing the authorizations that apply to a user session 💅

Authorization decisions can range from "only devices with passwords can use the network" all the way to super detailed application-specific policies 🎀 they're likely to get more sophisticated when device ownership can be transferred from one person to another, group membership may be needed, access rights may need to be revocable, and fine-grained access rights have to be used 👑 decisions can also factor in environmental stuff like how close devices are to each other, the physical location of the device asking for access, or the level of authentication 🌸 configuring these policies raises questions about who creates them and where they're stored 🤔 which immediately brings up how devices are identified and who's allowed to create these policies 🙈

Smart objects may be limited in code size, persistent storage, and Internet connectivity, so established authorization schemes may not be a great fit 🥺 delegating every authorization decision to another node in the network adds real network overhead, while storing sophisticated access control policies directly on the smart object can be prohibitive because of how big that ruleset gets 😤 Jan Janak presented one approach for distributing access control policies to smart objects within a single administrative domain 🧚

When access control decisions are bound to device identifiers and humans need to create or verify those policies, the choice of identifier matters for readability and accessibility 💜

A single mechanism probably won't cover the wide range of authorization tasks 🫶 from the discussions, it wasn't clear whether we need new authorization mechanisms or whether existing ones can be reused 🤷‍♀️ examples of protocols with built-in authorization mechanisms are Kerberos, OAuth, EAP/AAA, attribute certificates, etc. ✨ in many cases it's even conceivable that authorization decisions stay internal to the system, so there'd be no need to standardize any additional authorization mechanisms or protocols at all 🦋 in fact, many authentication and key exchange protocols already have authorization mechanisms built in 🌈

3.4. Provisioning of Credentials 🎀

When a smart object is introduced into an environment, like a home or an enterprise network, it usually has to be provisioned with some credentials first 🏠 the credentials 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 includes some identifier of the smart object, keying material, and other configuration info (e.g., specific servers it has to interact with) 📦

Some devices come pre-configured with default security codes or passwords, or with per-device or per-user credentials, when they're bought or when they arrive at the customer 🛍️

There's a limited set of solutions available, based on the interface support 💀 the imprinting solutions vary between enterprise and consumer household scenarios 🏡 for large-scale deployments, the time needed to pair two objects rules out other schemes that rely on manual steps ⏱️

Johannes Gilger covered the basic ideas behind pairing schemes, including the kinds of out-of-band channels that could be used and their limitations 🧠 imprinting and pairing protocols usually set up a security association between two equal devices, like Bluetooth-equipped cell phones 📱 to deal with man-in-the-middle attacks during this phase, there are various extra verification checks 🕵️‍♀️ for example, devices with a display can show numeric values on each device and let the user check whether they match 👀 devices with a keypad may need the user to enter a PIN ⌨️ where and how a smart object gets paired with other devices in the network can differ a lot depending on the use case and the hardware 🔧 pairing isn't necessarily something that happens just once in a device's lifetime 🔄 is group pairing something we should look at? or can any group key establishment be reduced to pairwise pairing with a central master device? 🤔

Cullen Jennings presented a model 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's first switched on 🏠📡 that first interaction can then be used to manage the device and provision keying material for later use 🔐 proof of ownership could be done by identifying the user who bought the device 🧾 this is an approach that's getting more and more popular today 📈 another option is some kind of secret info enclosed in the packaging 📦

For interface-constrained devices, using (semi)-public information together with an online manufacturer during imprinting seems like a possible solution 💡 this approach sparked a lot of discussion among participants, because it assumes an Internet connection and means the manufacturer effectively knows the trust relationships of every device it sells 😳

A few questions came up with this model: Will there be third parties with a business interest in providing something like key distribution and key escrow over a smart object's lifetime? 🤨 for constrained devices, will it always be possible to fall back on the existing security associations between device and manufacturer to create new associations? 🤔 obviously we don't want a smart object's lifetime limited by the manufacturer's product support lifespan 😤 what happens if a manufacturer goes bankrupt, changes its business scope, or gets bought by another company? 😱 will end customers be unable to use their smart objects anymore in that case, or lose the ability to resell their devices because ownership can no longer be transferred? 💔

One important design decision is that compromise of the manufacturer must not have any impact on smart objects that have already been imprinted to their new owners 🚨 the question also 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 ownership is an absolute necessity 💎

Industrial users are fine relying on the manufacturer during the imprinting phase, but they want to be in exclusive control of their devices afterwards 🏭

There are many classes of devices where we can assume online connectivity is present, otherwise those devices wouldn't 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 close enough 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 isn't enrolled by the customer but is still connected in a "naked" state? 😨 how does this affect security, and is it possible for an attacker to perform a "drive-by" enrollment of many devices? 🚗💨 how should a device behave in this situation? 🤷‍♀️ the safest option (for the user at least) would be to not let the device work with full functionality if it hasn't been enrolled 🛡️ this concern is especially relevant when 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 🌸

okay so designing for a smart object environment is basically one big optimization puzzle 🧩 you've gotta juggle technical stuff, usage scenarios, security threats, and business models all at once. Some design constraints are set in stone and others are flexible. Compromises will happen, bestie, but they should not come at the expense of security functionality 🔐

Designing a software update mechanism into the system is crucial 💅 that's how functionality gets enhanced and vulnerabilities get fixed. Also, security threats are seen differently over time. Like, lots of people didn't think pervasive monitoring was that big of a deal before the Snowden revelations 👀

The workshop participants didn't think new research and standardization on cryptographic algorithms was worth it for smart object environments 🙅‍♀️ (we're talking encryption algorithms, hash functions, keyed message digests, and public key crypto systems). There's already a huge range of algorithms out there, and standardized authentication and key exchange protocols can be customized to use almost any selection of them today ✨

Putting the building blocks together into a complete system was considered super important 🧱 and this document highlights a bunch of those areas in Section 3. Searching for one universal smart object security architecture was seen as a hopeless journey 😭 because there are just so many use cases, business models, and constraints.

After the workshop, follow-up work happened in a bunch of areas (and standardization is still ongoing!) 🦋 here are a few highlights:

The Light-Weight Implementation Guidance (LWIG) working group was created to be a venue where implementers of IP stacks, including security protocols, in constrained devices can share their experiences 🧚 The ability to tune IETF protocols via extensions and parameter choices gives implementers lots of flexibility to meet the constraints of a smart object environment.
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 💜 It also defines 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, and it's giving main character energy 👑
A new working group has been formed to standardize an authentication and authorization protocol for constrained environments 🎀 It offers a dynamic and fine-grained access control mechanism where clients and resource servers are constrained, so they have to make use of a trusted third party. When this document was written, the Authentication and Authorization for Constrained Environments (ACE) working group had just started 🥹

5. Security Considerations 🔐

this whole document is a report on the 'Smart Object Security Workshop' 🫶 and the focus of that workshop was on security only. Privacy was not part of the workshop agenda, so it's not covered here 🙈 that's a big deal, bestie, and it's worth keeping in mind ⚠️

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.

[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.

Appendix A. Program Committee 💖

the workshop was organized by the following individuals 🧑‍🤝‍🧑

Hannes Tschofenig
Jari Arkko
Carsten Bormann
Peter Friess
Cullen Jennings
Antonio Skarmeta
Zach Shelby
Thomas Heide Clausen

Appendix B. Published Workshop Material 🌈

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

Appendix C. Accepted Position Papers 📝

Michael Richardson, "Challenges in Smart Object Security: too many layers, not enough ram"
Mitsuru Kanda, Yoshihiro Ohba, Subir Das, Stephen Chasko, "PANA applicability in constrained environments"
Randy Bush, "An Operational View of Trust Needs of Moving Objects"
Andrei Gurtov, Ilya Nikolaevsky, Andrey Lukyanenko, "Using HIP DEX for Key Management and Access Control in Smart Objects"
Jens-Matthias Bohli, "Access Tokens for the IoT"
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"
Kazunori Miyazawa, "Convergence of Smart Objects in industrial wireless sensor network"
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"
Fida Khattak, Philip Ginzboorg, Valtteri Niemi, Jan-Erik Ekberg, "Role of Border Router in 6LoWPAN Security"
Thomas Fossati, Angelo Castellani, Salvatore Loreto, "(Un)trusted Intermediaries in CoAP"
Rene Hummen, Christian Roeller, Klaus Wehrle, "Modeling User-defined Trust Overlays for the IP-based Internet of Things"
Sam Hartman, Margaret Wasserman, "Federation, ABFAB and Smart Devices"
Cary Bran, Joseph Stachula, "Device Pairing: Lessons Learned"
Jan Janak, Hyunwoo Nam, Henning Schulzrinne, "On Access Control in the Internet of Things"
Rene Struik, "Cryptography and Security for Highly Constrained Networks"
Zhen Cao, Hui Deng, Judy Zhu, "The Architecture of Open Security Capability"
Sujing Zhou, Zhenhua Xie, "On Cryptographic Approaches to Internet-Of-Things Security"
Nancy Cam-Winget, Monique Morrow, "Security Implications to Smart Addressable Objects"
Jouni Korhonen, "Applying Generic Bootstrapping Architecture for use with Constrained Devices"
Olaf Bergmann, Stefanie Gerdes, Carsten Bormann, "Simple Keys for Simple Smart Objects"
Mohit Sethi, Jari Arkko, Ari Keranen, Heidi-Maria Rissanen, "Practical Considerations and Implementation Experiences in Securing Smart Object Networks"
Paul Chilton, "Experiences and Challenges in using constrained Smart Objects"
Vladislav Perelman, Mehmet Ersue, "TLS with PSK for Constrained Devices"
Richard Barnes, "Security for Smart Objects beyond COMSEC: Principals and Principles"
Rudolf van der Berg, "OECD Publication on Machine-to-Machine Communications: Connecting Billions of Devices", OECD Digital Economy Papers, No. 192, OECD Publishing
Cullen Jennings, "Transitive Trust Enrollment for Constrained Devices"
Barbara Fraser, Paul Duffy, Maik Seewald, "Smart Objects: Security Challenges from the Power Sector"
Hannes Tschofenig, "Smart Object Security: Considerations for Transport Layer Security Implementations"
Johannes Gilger, Ulrike Meyer, "Secure Pairing & Context Management"
Klaas Wierenga, "Scalable Authentication for Smart Objects"
Dirk Stegemann, Jamshid Shokrollahi, "Security in the Internet of Things - Experiences from Use Cases"
Alper Yegin, "Credentials for Smart Objects: A Challenge for the Industry"
Shahid Raza, Thiemo Voigt, Vilhelm Jutvik, "Lightweight IKEv2: A Key Management Solution for both the Compressed IPsec and the IEEE 802.15.4 Security"
Eric Rescorla, "A Brief Survey of Imprinting Options for Constrained Devices"
Fred Baker, "Security in distributed telemetry and control networks"

Appendix D. Workshop Participants 🎀

okay bestie, this is the guest list! 💖 the RFC says a big thank you to everyone who came to the workshop, and honestly the list is iconic. 🧚

Jari Arkko
Carsten Bormann
Cullen Jennings
Antonio Skarmeta
Sean Turner
Thomas Heide Clausen
Hannes Tschofenig
Michael Richardson
Yoshihiro Ohba
Subir Das
Randy Bush
Andrei Gurtov
Ilya Nikolaevsky
Andrey Lukyanenko
Jens-Matthias Bohli
Kazunori Miyazawa
Philip Ginzboorg
Fida Khattak
Angelo Castellani
Salvatore Loreto
Rene Hummen
Klaus Wehrle
Sam Hartman
Margaret Wasserman
Cary Bran
Jan Janak
Rene Struik
Zhen Cao
Hui Deng
Zhou Sujing
Xie Zhenhua
Monique Morrow
Nancy Cam-Winget
Jouni Korhonen
Ari Keranen
Paul Chilton
Vladislav Perelman
Mehmet Ersue
Richard Barnes
Rudolf van der Berg
Barbara Fraser
Johannes Gilger
Sye Loong Keoh
Olaf Bergmann
Stefanie Gerdes
Klaus Hartke
Oualha Nouha
Alexis Olivereau
Alper Yegin
Klaas Wierenga
Jiazi Yi
Juan Antonio Cordero Fuertes
Antonin Bas
David Schinazi
Valerie Lecomte
Ulrich Herberg
Shahid Raza
Stephen Farrell
Eric Rescorla
Thomas Fossati
Mohit Sethi
Alan Duric
Guido Moritz
Sebstian Unger
Hans Loehr

Acknowledgements ✨

the authors really wanted to thank the participants AND the people who wrote the position papers, because their input made this whole thing happen 🫶

they also gave a special shoutout to Thomas Heide Clausen and Ecole Polytechnique (Paris) for providing the venue and organizing everything. main character organizers 👑

and last but not least, Rudolf van der Berg gets a thank you for his review comments 💅

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

📦 where this page comes from

ietf: rfc7397 2014-12
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms