RFC 9238

Loading Manufacturer Usage Description (MUD) URLs from QR Codes

📅 published May 2022, from ietf

RFC 9238: Loading Manufacturer Usage Description (MUD) URLs from QR Codes 🎀

okay bestie, first the vibe check 💅 RFC 9238 is an Independent Submission, published in May 2022. It's in the Informational category, so it's not a standard (more on that in the Status section ✨). The authors are M. Richardson from Sandelman Software Works, J. Latour from CIRA Labs, and H. Habibi Gharakheili from UNSW Sydney 🫶. The ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates, so it's standing completely solo 🦋.

Abstract ✨

okay so this informational doc spills the tea on a protocol for loading MUD definitions from RFC 8520, for devices that don't have them built in 🍓

it's published so the Internet community knows this mechanism exists, which helps with interoperability. it's also meant as a starting point for other standards work, if people are interested 💜

Status of This Memo 📚

this is not a Standards Track spec. it's just published for info, no cap 💅

this is a contribution to the RFC Series, separate from any other RFC stream. the RFC Editor picked to publish it at their discretion, and they make no claims about whether you should implement or deploy it. docs the RFC Editor approves aren't candidates for any level of Internet Standard, see Section 2 of RFC 7841 🌸

for the latest status, errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9238 🔗

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. 💖

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. read those carefully, because they spell out your rights and restrictions for this doc 🙈

Table of Contents 🧚

   1.  Introduction
   2.  Terminology
   3.  Protocol
     3.1.  The SQRL Protocol
     3.2.  Manufacturer Usage Descriptions in SQRL
       3.2.1.  B000 Company Name
       3.2.2.  B001 Product Name
       3.2.3.  B002 Model Number
       3.2.4.  MUD URL Data Record
       3.2.5.  Device MAC Address
   4.  Applicability
   5.  Generic URL or Version-Specific URL
   6.  Crowd Supply of MUD Files
   7.  Privacy Considerations
   8.  Security Considerations
     8.1.  QR Codes Are Not Assurances
     8.2.  MUD Files Can Have Signatures
     8.3.  URL Shortening Services Can Change Content
     8.4.  MUD QR Code Stickers Could Be Confused
     8.5.  QR Code Can Include a MAC Address
   9.  IANA Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction 💅

okay so MUD [RFC8520] is basically a YANG data model that says what kind of access a device needs to work properly 🧚 that same doc gives three ways for the device to tell a network enforcement point its MUD URL (the link to the resulting MUD file, written in JSON [RFC8259]): over DHCP, inside an X.509 certificate extension, or through the Link Local Discovery Protocol (LLDP) 💜

all three of those send the MUD URL in band and need changes to the device firmware. most small Internet of Things (IoT) devices don't have LLDP and often have super restricted DHCP clients 😭 adding LLDP or DHCP options means at least some config changes, and maybe entirely new subsystems. meanwhile, the PKIX certification extension only really makes sense as part of a bigger setup built on an Initial Device Identifier (IDevID) [IEEE802-1AR], like the one described in [RFC8995] 🎀

so in all of those cases, only people who can modify and update the device's firmware can actually use these mechanisms 🔒

and then there's the chicken or egg problem [chickenegg] 🐔🥚 manufacturers aren't motivated to (so they likely don't) put MUD URLs in their products, because they think no gateways use them. at the same time, gateways have little reason to (so they likely don't) include code that processes MUD URLs, because they figure no products have or spread URLs 🙃

this protocol lets anyone with physical access to the device stick on a reference to a MUD URL, which an end user can scan later 🦋

the QR-based protocol is a convenient alternative for when the mechanisms from [RFC8520] aren't available on the device or the gateway ✨

affixing a sticker can be done by:

  • the marketing department of the manufacturer,
  • an outsourced assembler plant,
  • value-added resellers (perhaps in response to a local request for proposal (RFP)),
  • a company importing the product (possibly to comply with a local regulation),
  • a network administrator (perhaps before sending devices home with employees or to remote sites), and
  • a retailer as a value-added service.

QR codes are informally described in [qrcode] and formally defined in [isoiec18004] 🤓 this protocol uses a QR code to encode the MUD URL. specifically, it borrows the data format from the Reverse Logistics Association's Standardized Quick Response for Logistics [SQRL] 🍓

SQRL codes go on devices as a sticker or laser-etched into the case, mostly for end-of-life processing. the big idea is that clearly identifying a product makes it easier to dispose of, refurbish, or recycle its components properly ♻️

SQRL codes are also used for regular maintenance of a product, which is a whole other vibe 🧰

SQRL is an application of the 12N Data Identifier system specified by the ANSI MH10.8.2 Committee [mh10], formatted for QR codes and other things like Normalization Form C (NFC) transmissions 💜

there are QR code generators as web services or as programs, like [qrencode] 🌸

Section 5 summarizes the considerations in "Updating files vs Updating MUD URLs" (Section 7.1 of [MUD-URLS]). because the QR code is immutable, MUD URLs in this doc will need to be non-firmware specific 🔐

2. Terminology 💖

even though this doc isn't an IETF Standards Track publication, it uses the normative language conventions so implementers get clear instructions 🫶 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ✨

readers should already know the terms from [RFC8520], like: MUD file, MUD URL, manufacturer, MUD manager, and controller 📚

3. Protocol 🧚

the QR code protocol is built on top of [SQRL]. Section 3.1 gives a quick summary of that protocol. after that, we go through the list of Data Records you need to fill in 💅

3.1. The SQRL Protocol

[SQRL] documents an octet protocol that can be efficiently encoded into QR codes using a sequence of US-ASCII bytes, plus six control codes (see Section 3.1 of [SQRL]) 🌈

  • <RS> Record Separator (US-ASCII 30)
  • <EoT> End of Transmission (US-ASCII 4)
  • <FS> Field Separator (US-ASCII 28)
  • <GS> Group Separator (US-ASCII 29)
  • <US> Unit Separator (US-ASCII 31)
  • Concatenation Operator (US-ASCII 43: "+")

Section 7.2 of [SQRL] has the full details, which boil down to:

  1. The QR code header starts with:
"[)>" <RS> "06" <GS> "12N"
  1. Include one or more Data Records. Each one is a four-letter Field Identifier, followed by US-ASCII characters terminated with a <Unit Separator>. 🎀
  2. End with:
<RS><EoT>

there are also optional flags that can show up in every Data Record, as described in Section 7.4 of [SQRL] 🌸 those flags have no bearing on MUD processing. a parser that only collects MUD URLs won't need to parse them, but a general-purpose SQRL parser will need more complexity 🧠

Field Separator characters mark the start of a new unit of data. a MUD-specific parser that hits a Field Separator and hasn't collected the right MUD info yet MUST ignore the characters collected so far and then restart. no dragging old junk along 🙅‍♀️

Environment records, as described in Section 7.4 of [SQRL], look and act exactly like fields, just with a special Field Identifier. they serve no purpose when you're looking for MUD info and MAY be ignored 💀

3.2. Manufacturer Usage Descriptions in SQRL

3.2.1. B000 Company Name

the B000 Data Record is mandatory in [SQRL]. it MUST be in US-ASCII representation. it should be a representation of the company or brand name 🏢 it SHOULD match the ietf-mud/mud/mfg-name in the MUD file. the MUD file can hold arbitrary UTF-8 for this name, but SQRL files are expected to be 7-bit US-ASCII, so, yeah, it's a bit of a mismatch 🙈

3.2.2. B001 Product Name

the B001 Data Record is optional in [SQRL]. it's the Product Name in US-ASCII. including it is RECOMMENDED 💜 some third parties making QR code stickers might not know the product name with 100% certainty, and they MAY prefer to skip it rather than add more confusion 🌀

3.2.3. B002 Model Number

the B002 Data Record is optional in [SQRL] but is MANDATORY in this profile 🎀 it's the Model Name in US-ASCII. it SHOULD match the optional ietf-mud/mud/model-name in the MUD file, if that entry is there. again, MUD files can hold arbitrary UTF-8 for the model-name, while SQRL files are expected to be 7-bit US-ASCII 🙃

if a third party making QR codes can't find an official model number when creating their MUD file and QR code, then they SHOULD make one up 🫣

3.2.4. MUD URL Data Record

a new Field Identifier was assigned by the Reverse Logistics Association: M180 🦋 this record MUST be filled with the MUD URL.

short URLs are way easier to encode into a QR code, because they need fewer pixels. more content in the QR code means you need a bigger image 📏

URL shortening services (see [URLshorten]) can be useful, as long as the service stays stable for the whole life of the device and QR code, and its privacy stance is well understood 🔍 the Security Considerations section of [RFC3986] applies here, especially Section 7.1 🔐

Section 8.1 of [SQRL] also has good advice on longevity concerns with URLs 🧚

heads up, bestie: the URL MUST NOT have a query (?) portion. if one is there, the query portion MUST be removed before processing. no ? allowed, periodt 💅

3.2.5. Device MAC Address

okay bestie, if a Media Access Control (MAC) address is used as a unique device identifier (which is RECOMMENDED if possible 💅), then it MUST be included in this Data Record 🎀.

Section 9.10 of [SQRL] defines the Data Record M06C as the MAC address. That document doesn't give a format for the MAC address, though 🤷‍♀️

In this document, it is RECOMMENDED that 12 (or 16) hex octets are used with no spaces or punctuation. The 16-octet version is the IEEE 64-bit Extended Unique Identifier (EUI-64) format used in [IEEE.802.15.4] and some next generation Ethernet proposals ✨. In this document, it is RECOMMENDED that uppercase hexadecimal letters be used 🔥.

Parsers that find punctuation (such as colons (":"), dashes ("-"), US-ASCII Space (32), US-ASCII TAB (0), US-ASCII linefeed (10), or US-ASCII carriage return (13)) MUST skip over the punctuation 🧹. Parsers MUST tolerate hexadecimal in uppercase, lowercase, and even mixed case 🌈. Systems SHOULD canonicalize it to uppercase 💖.

4. Applicability ✨

Stickers that carry MUD URLs don't seem to add much value when the end-user organization applies them and also reads them. This is especially true when the QR code doesn't include the device MAC address 🙈. In that case, the installer would scan the QR code to get the right MUD file reference and would still have to type in the associated MAC address.

So you might be wondering why the installer can't just type in the MAC address and pick the right Access Control Lists (ACLs) for the device 🤔. Then there'd be no need for a MUD file or a QR code to convey the MAC address. But using a MUD file (or a QR code or another way to convey the MAC address) is worth it because it gives you several layers of indirection 🧅:

  1. The ACLs for a given device may be added or removed.
  2. The ACLs may refer to DNS names, which may map to IPv4 or IPv6 addresses.
  3. The entire file may be replaced and may also include supply chain information, such as Software Bill of Materials (SBOM).

Also, the way you map a new device (MAC address) to a MUD file doesn't have to let the person doing the installation change any other network security settings 🔒.

5. Generic URL or Version-Specific URL 🦋

MUD URLs that the device sends in band and that are programmed into its firmware may point to a firmware-specific version of the MUD URL. The perk is that the ACLs enforced on the network are tailored to what that firmware version actually needs 🎯.

A MUD URL that's stuck on the device with a sticker or etched into the case can't be changed 😭.

Given the considerations in "Updating MUD URLs vs Updating MUD files" (Section 6.1 of [MUD-URLS]), it's prudent to use a MUD URL that points to a MUD file that only ever gets new features added over time and never has features removed 🧠. Here's the tea: if a feature is removed from the firmware but the MUD file still permits it, that's a potential hole that could maybe get exploited 💀. The opposite case, where a MUD file wrongly forbids something, causes false positives in the security system, and the evidence shows this leads to the entire system being ignored 🙃. Preventing attacks on core infrastructure may matter more than getting the ACL perfect 👑.

When the firmware eventually gets built-in MUD URL support, a more-specific URL may be used 🌸.

Also, in lots of cases it'll be third parties making these QR codes, so the MUD file may be hosted by the third party 📦.

6. Crowd Supply of MUD Files 🌍

At the time of writing, the IETF MUD is a new IETF Proposed Standard. So IoT device manufacturers haven't provided MUD profiles for their devices yet 😤. A research group at the University of New South Wales (UNSW Sydney) built an open-source tool called MUDgee [MUDgee], which automatically generates a MUD file (profile) for an IoT device from its traffic trace. That makes the whole process faster, easier, and more accurate 🚀. Keep in mind that the completeness of the generated profile depends entirely on the completeness of the input traffic traces 🧐. MUDgee assumes that all the activity it sees is intended and benign 🫶.

UNSW researchers ran MUDgee on about 30 consumer IoT devices from their lab testbed and publicly released their MUD files [MUDfiles] 🎉. MUDgee can help IoT manufacturers develop and verify MUD profiles, and it can also help adopters of these devices make sure the devices fit their organizational policies 💼.

Lots of other public and private labs have done similar work 🧪. One of the big motivations for this specification is letting that work leave the lab and get applied out in the field 🌟.

7. Privacy Considerations 🙈

The MUD URL in the QR code reveals the manufacturer of the device, the type or model of the device, and possibly the firmware version of the device 👀.

The MAC address of the device also needs to be present, and that's potentially Personally Identifiable Information (PII) 🚨. So these QR codes should not be placed on the outside of the packaging, only on the device itself, ideally on a non-prominent part of the device (e.g., the bottom) 🤫.

The QR code sticker should not be placed on any part of the device that might become visible to machine vision systems in the same area 📸. That includes security systems, robotic vacuum cleaners, or anyone taking a picture with a camera 🧹. Those systems may store the pictures in a way that lets a future viewer decode the QR code, possibly by stitching together multiple pictures 🧩. Of course, the QR code isn't a sure sign that the device is present. It only tells you the QR code sticker that came with the device is there 🫠.

Using the URL shortening services discussed in Section 3.2.4 may mean trading convenience and efficiency for privacy 🍓. The service provider might use per-device or per-customer short URLs to track and correlate requests 👁️.

8. Security Considerations 🔐

8.1. QR Codes Are Not Assurances 🎀

Just having a QR code on a device doesn't create any security issues on its own ✨. A paper sticker stuck on the device or a laser-etched code in a plastic case won't affect how the device operates 💅.

The QR code isn't active. In general, it can't communicate over nearby networks 📡. It's conceivable that something more active is hidden in the sticker, like an NFC or a Radio Frequency Identification (RFID) tag. But any sticker could contain that kind of thing. For example, on some university campuses, stickers are used for political campaigns and get stuck all over the place 🪧.

The security issues this protocol creates come from assumptions that the QR code's presence might suggest. The QR code might lead some owners or network operators to believe the device's behavior has been vetted by some authority 🧐. This is where some caution is required ⚠️.

A possibly bigger risk with MUD file stickers on devices is that they can start to give users of the device a false sense of safety 😬. A sticker, maybe with the logo of the physical establishment where the device lives, could tell the people in that establishment that this device is official. Think of a university that only deploys sensors on campus that have been vetted for compliance against a MUD definition 🎓.

That opens the door to social engineering. Any device with a reasonable-looking QR code may be seen as trusted, even though that trust isn't justified by that evidence 🙃. An attacker who wants to sneak their own devices in only needs to camouflage the device with a suitable sticker to look legitimate 🥷.

8.2. MUD Files Can Have Signatures 🖊️

The network operator who takes the MUD file designated by the QR code needs to be careful to validate the signature on the MUD file 🔍. The operator needs to verify that the file is intact and that the signer is authorized to sign MUD files for that vendor. If the MUD file is a crowd-sourced definition, they need to figure out whether it can be trusted 🤷‍♀️. [RFC8520] doesn't define any infrastructure to authenticate or authorize MUD file signers 🫣.

8.3. URL Shortening Services Can Change Content 🔗

If a URL shortening service is used, the MUD controller could get redirected to another MUD file with different content 😱. The use of MUD signatures can detect attacks on the integrity of the file. To do that, the MUD controller needs to be able to verify the signature on the file 🔐.

If a Trust-On-First-Use (TOFU) policy is used for signature trust anchors, the URL shortening service can still attack by substituting both the content and the signature on the first use 💀. MUD controllers and the people operating them need to be cautious when using TOFU 🫡.

8.4. MUD QR Code Stickers Could Be Confused 🙀

Another problem with the stickers is that a reseller or another trusted party could apply the wrong sticker to a device, either by mistake or because of a physical or socially engineered attack on that party 😵. The network operator then onboards a device and applies what they think is a legitimate network policy for the device in their hands. Turns out it's actually a policy for a different kind of device 😩.

Careful examination of stickers is in order! 🔎✨

8.5. QR Code Can Include a MAC Address 🧷

Including the device-specific MAC address (described in Section 3.2.5) in the QR code makes the MUD code way easier to use, because it identifies the device specifically 🎯. If the MAC address isn't included, a network operator who has the device in their hands has to link the policy to the device through some other interface 🫤.

Even though having the MAC address included is a big advantage, third-party stickers probably won't include it 😔. Including the MAC address means a unique sticker with a QR code has to be made for each device. That's doable if a manufacturer applies the sticker, since it's already common to have a serial number and MAC address on the outside of the device 🏭. If the QR code is part of that sticker, then customization isn't that complicated 💜.

When a third party has produced the QR code, every device of a particular model will probably have the same QR code applied, without the MAC address. That raises the chance that the wrong policy gets applied to a device 😬.

9. IANA Considerations 📋

This document has no IANA actions 🌷.

10. References 📚

10.1. Normative References

okay so these are the must-read receipts 🧾 you need before the spec makes sense bestie 💅

10.2. Informative References

these ones are the extra reading 📚🌸 helpful, not required, but lowkey iconic if you check them out

Acknowledgements 🫶

This work was supported by the Canadian Internet Registration Authority (cira.ca). thank you CIRA, you're the real MVPs 👑

Authors' Addresses 🎀

Michael Richardson Sandelman Software Works Email: mcr+ietf@sandelman.ca

Jacques Latour CIRA Labs Email: Jacques.Latour@cira.ca

Hassan Habibi Gharakheili UNSW Sydney Email: h.habibi@unsw.edu.au

📦 where this page comes from