Skip to main content
  • New Internet Architecture Board, IETF Trust, IETF LLC and Internet Engineering Task Force Leadership Announced

    Members of the incoming Internet Architecture Board (IAB), the IETF Trust, the IETF Administration LLC (IETF LLC) Board of Directors, and the Internet Engineering Steering Group (IESG)—which provides leadership for the Internet Engineering Task Force (IETF)—have been officially announced, with new members selected by the 2021-2023 IETF Nominating Committee.

      13 Feb 2023
    • Informing the community on third-party correspondence regarding the W3C

      In accordance with our policy of transparency, this blog post is being published in order to keep the community informed about recent correspondence with lawyers acting on behalf of the Movement for an Open Web.

      • Lars EggertIETF Chair
      8 Feb 2023
    • Six Applied Networking Research Prizes Awarded for 2023

      Six network researchers have received Internet Research Task Force Applied Networking Research Prize (ANRP), an award focused on recent results in applied networking research and on interesting new research of potential relevance to the Internet standards community.

      • Grant GrossIETF Blog Reporter
      9 Jan 2023
    • Travel grants allow Ph.D. students to participate at IETF meeting in-person

      Sergio Aguilar Romero and Martine Sophie Lenders, both Ph.D. students in technology fields, attended and participated in the IETF 115 meeting in London with assistance through travel grants from the Internet Research Task Force.

      • Grant GrossIETF Blog Reporter
      7 Jan 2023
    • Impressions from the Internet Architecture Board E-Impact Workshop

      The IAB ran an online workshop in December 2022 to begin to explore and understand the environmental impacts of the Internet. The discussion was active, and it will take time to summarise and produce the workshop report – but the topic is important, so we wanted to share some early impressions of the outcomes.

      • Colin PerkinsIAB Member
      • Jari ArkkoIAB Member
      6 Jan 2023

    Filter by topic and date

    Filter by topic and date

    IETF 105: Internet of Things Wrapup

    • Steve Olshansky

    9 Sep 2019

    Continuing the tradition of activity around the IETF on the Internet of Things (IoT), there was a great deal of work on topics related to or affecting IoT in Montreal at the latest IETF Hackathon and IETF 105 meeting.

    For those interested in following or participating in IoT-related standards development, IETF working groups (WGs) are open to any interested individual. Much of the work of the IETF takes place on mailing lists. Links to details about respective WGs, including email lists, are included throughout this post.

    Getting MUD-y

    Update from Eliot Lear

    The second largest table at the IETF Hackathon was focused on Manufacturer Usage Descriptions (MUD - RFC 8520). Within a span of four hours, a device manufacturer could implement MUD and test against four separate MUD managers. MUD atop the Wifi Alliance’s Device Provisioning Protocol (DPP) specification was also demonstrated. 

    The CIRA Labs team began the redesign of mudmaker.org internals, developing a python version known as muddy. The IETF Hackathon MUD team worked on a tool developed by Paul Watrobski at NIST/University of Maryland that observes packet flows and generates MUD files known as MUDPI.  Finally, we worked on a means to report to manufacturers how MUD-protected devices are, in fact, being protected. This same table featured additional work by Michael Richardson on ANIMA Autonomic Control Plane (ACP).

    Later in the week, several sessions at the IETF 105 meeting focused on IoT onboarding and MUD extensions. The document draft-ietf-anima-bootstrapping-key-infra, which was developed in the ANIMA working group, has subsequently been submitted to the Internet Engineering Steering Group for publication as an RFC. One of the key issues has been what alternate means would be available to onboard a device when the Manufacturer Authorized Signing Authority (MASA) is no longer available. There are a number of proposals on how to do this, some involve replacing trust anchors, others involve chains of RFC 8366 vouchers, but it is far from clear that there is any single choice that satisfies all situations.

    Over in the Operations and Management Area Working Group (OPSAWG) numerous extensions to MUD were proposed, including a profile for Transport Layer Security (TLS) crypto suite identification (draft-reddy-opsawg-mud-tls).  Attackers tend to use their own crypto suites, so a profile that indicates the correct crypto suite is being investigated as a means to identify those attacks.  A new draft draft-richardson-opsawg-mud-iot-dns-considerations aims to provide guidance on how to use DNS from IoT devices in a way that is compatible with MUD. A separate draft,  draft-lear-opsawg-mud-controller-candidates, looks at how to identify candidates to be controllers for different classes of devices. 

    There is now a discussion on whether to establish a separate MUD working group. To participate, you can join the opsawg@ietf.org or mud@ietf.org mailing lists.  This includes the possibility of a wider scope cross-area IoT Operational Security WG that would include MUD.

    Laying Foundations for IoT Security

    Update from Mohit Sethi

    With publication RFC 8576–Internet of Things (IoT) Security: State of the Art and Challenges–the Thing-to-Thing Research Group (T2TRG) documented the current IoT security initiatives at the IETF (and elsewhere). It also discussed some important security challenges that remain. One of the key challenges identified in the document was how the things in IoT networks can be securely configured before they are functional. This step is especially challenging as the number of these things may be large and they often have very limited user interfaces. The initial configuration of things may involve several sub-steps that must be completed before the thing is fully operational. Each of these sub-steps can be viewed in terms of authorization chains that need to be established. In the next phase of its research work, T2TRG will work on documenting the various terminology related to this initial configuration step. 

    For more on the T2TRG session at IETF 105, see the published minutes. You can follow the ongoing the discussion at t2trg@irtf.org.

    Lightweight Implementation Guidance (LWIG)

    Update from Mohit Sethi

    The LWIG working group did not meet at IETF 105. However, there are active discussions on a number of topics underway in the working group. Anyone interested in participating in this important work is encouraged to do so by joining the mailing list. See the LWIG page for more information. 

    EMU takes flight

    Update from Eliot Lear and Mohit Sethi

    In many IoT scenarios, it is often not possible to rely on the existence of a trusted third party or other network infrastructure for bootstrapping, so the EAP Method Update (EMU) working group is currently considering several draft bootstrapping solution proposals for IoT devices which have no pre-configured authentication credentials and which are not yet registered on an authentication server. Nimble out-of-band (OOB) authentication for Extensible Authentication Protocol  (EAP-NOOB) is a generic approach to address the bootstrapping issue. The draft specification defines an EAP method where the authentication is based on a user-assisted OOB channel between the server and peer. EAP-NOOB is more generic than most ad-hoc bootstrapping solutions in that it supports many types of OOB channels, including QR codes, NFC, sound, and blinking lights. The draft already has an open source implementation and has formal security proofs.

    In addition, several drafts relating to BRSKI (Bootstrapping Remote Secure Key Infrastructures) and RFC 8366 were presented in the EMU WG session:

    The EAP Method Update (EMU) working group is in the process of rechartering and to participate in these discussions, you can join the emu@ietf.org working group mailing list and the iot-onboarding@ietf.org mailing list.

    Running code for IoT

    In addition to the IETF Hackathon projects already mentioned, several others included IoT-related work:

    • ANIMA ACP
    • HOMENET/DNSSD build-out
    • MUD
    • Trusted Execution Environment Provisioning (TEEP)
    • IP Wireless Access in Vehicular Environments (IPWAVE) Basic Protocols
    • WISHI (Work on IoT Semantic / Hypermedia Interoperability)
    • LPWAN CoAP/UDP/IPv6 SCHC compression and fragmentation

    The IETF Hackathon wiki has additional details on all the projects worked on in Montreal. The next Hackathon in Singapore for IETF 106 (Nov. 16-17, 2019) promises to continue the trend of several IoT-related projects. For more information, see the Hackathon page.

    About the author

    Steve Olshansky is the Internet Technology Program Manager at the Internet Society, based in Colorado, United States.  

    Bibliography

    • [1]RFC 8366

      A Voucher Artifact for Bootstrapping Protocols

      This document defines a strategy to securely assign a pledge to an owner using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a Cry…

    • [2]RFC 8576

      Internet of Things (IoT) Security: State of the Art and Challenges

      The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well recognized, and many standardization steps to provide security have been taken -- for example, the specif…

    • [3]RFC 7170

      Tunnel Extensible Authentication Protocol (TEAP) Version 1

      This document defines the Tunnel Extensible Authentication Protocol (TEAP) version 1. TEAP is a tunnel-based EAP method that enables secure communication between a peer and a server by using the Transport Layer Security (TLS) protocol to establish a mutually authenticated tunnel. Within the tunne…


    Share this page