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 firstname.lastname@example.org or email@example.com mailing lists. This includes the possibility of a wider scope cross-area IoT Operational Security WG that would include MUD.