rfc9238.original | rfc9238.txt | |||
---|---|---|---|---|
Network Working Group M. Richardson | Independent Submission M. Richardson | |||
Internet-Draft Sandelman Software Works | Request for Comments: 9238 Sandelman Software Works | |||
Intended status: Informational J. Latour | Category: Informational J. Latour | |||
Expires: 22 September 2022 CIRA Labs | ISSN: 2070-1721 CIRA Labs | |||
H. Habibi Gharakheili | H. Habibi Gharakheili | |||
UNSW Sydney | UNSW Sydney | |||
21 March 2022 | May 2022 | |||
On loading MUD URLs from QR codes | Loading Manufacturer Usage Description (MUD) URLs from QR Codes | |||
draft-richardson-mud-qrcode-07 | ||||
Abstract | Abstract | |||
This informational document details a protocol to load MUD | This informational document details a protocol to load Manufacturer | |||
definitions for devices which have no integrated Manufacturer Usage | Usage Description (MUD) definitions from RFC 8520 for devices that do | |||
Description (MUD) as described in RFC8520. | not have them integrated. | |||
This document is published to inform the Internet community of this | This document is published to inform the Internet community of this | |||
mechanism to allow interoperability and to serve as a basis of other | mechanism to allow interoperability and to serve as a basis of other | |||
standards work if there is interest. | standards work if there is interest. | |||
// RFC-EDITOR-please-remove: This work is tracked at | ||||
// https://github.com/mcr/mud-qrcode | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at https://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This is a contribution to the RFC Series, independently of any other | |||
and may be updated, replaced, or obsoleted by other documents at any | RFC stream. The RFC Editor has chosen to publish this document at | |||
time. It is inappropriate to use Internet-Drafts as reference | its discretion and makes no statement about its value for | |||
material or to cite them other than as "work in progress." | implementation or deployment. Documents approved for publication by | |||
the RFC Editor are not candidates for any level of Internet Standard; | ||||
see Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on 22 September 2022. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
https://www.rfc-editor.org/info/rfc9238. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2022 IETF Trust and the persons identified as the | Copyright (c) 2022 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents | |||
license-info) in effect on the date of publication of this document. | (https://trustee.ietf.org/license-info) in effect on the date of | |||
Please review these documents carefully, as they describe your rights | publication of this document. Please review these documents | |||
and restrictions with respect to this document. Code Components | carefully, as they describe your rights and restrictions with respect | |||
extracted from this document must include Revised BSD License text as | to this document. | |||
described in Section 4.e of the Trust Legal Provisions and are | ||||
provided without warranty as described in the Revised BSD License. | ||||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology | |||
3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Protocol | |||
3.1. The SQRL Protocol . . . . . . . . . . . . . . . . . . . . 4 | 3.1. The SQRL Protocol | |||
3.2. Manufacturer Usage Descriptions in SQRL . . . . . . . . . 5 | 3.2. Manufacturer Usage Descriptions in SQRL | |||
3.2.1. B000 Company Name . . . . . . . . . . . . . . . . . . 6 | 3.2.1. B000 Company Name | |||
3.2.2. B001 Product Name . . . . . . . . . . . . . . . . . . 6 | 3.2.2. B001 Product Name | |||
3.2.3. B002 Model Number . . . . . . . . . . . . . . . . . . 6 | 3.2.3. B002 Model Number | |||
3.2.4. MUD URL Data Record . . . . . . . . . . . . . . . . . 6 | 3.2.4. MUD URL Data Record | |||
3.2.5. Device MAC Address . . . . . . . . . . . . . . . . . 7 | 3.2.5. Device MAC Address | |||
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 | 4. Applicability | |||
5. Generic URL or Version Specific URL . . . . . . . . . . . . . 8 | 5. Generic URL or Version-Specific URL | |||
6. Crowd Supply of MUD Files . . . . . . . . . . . . . . . . . . 8 | 6. Crowd Supply of MUD Files | |||
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 | 7. Privacy Considerations | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 8. Security Considerations | |||
8.1. QR codes are not assurances . . . . . . . . . . . . . . . 9 | 8.1. QR Codes Are Not Assurances | |||
8.2. MUD files can have signatures . . . . . . . . . . . . . . 10 | 8.2. MUD Files Can Have Signatures | |||
8.3. URL Shortening services can change content . . . . . . . 10 | 8.3. URL Shortening Services Can Change Content | |||
8.4. MUD QR code stickers could be confused . . . . . . . . . 11 | 8.4. MUD QR Code Stickers Could Be Confused | |||
8.5. QR code can include MAC address . . . . . . . . . . . . . 11 | 8.5. QR Code Can Include a MAC Address | |||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 | 9. IANA Considerations | |||
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 | 10. References | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 10.1. Normative References | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 12 | 10.2. Informative References | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 12 | Acknowledgements | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
The Manufacturer Usage Description (MUD) [RFC8520] defines a YANG | The Manufacturer Usage Description (MUD) [RFC8520] defines a YANG | |||
data model to express what sort of access a device requires to | data model to express what sort of access a device requires to | |||
operate correctly. That document additionally defines three ways for | operate correctly. That document additionally defines three ways for | |||
the device to to communicate to a network enforcement point the MUD | the device to communicate the MUD URL (i.e., the URL of the resulting | |||
URL, i.e., the URL of the resulting MUD file in JSON [RFC8259]: DHCP, | MUD file in JSON [RFC8259]) to a network enforcement point: via DHCP, | |||
within an X.509 certificate extension, and via LLDP. | within an X.509 certificate extension, and via the Link Local | |||
Discovery Protocol (LLDP). | ||||
Each of the above mechanism conveys the MUD URL in-band, and requires | Each of the above mechanisms conveys the MUD URL in band and requires | |||
modifications to the device firmware. Most small IoT devices do not | modifications to the device firmware. Most small Internet of Things | |||
have LLDP, and often have very restricted DHCP clients. Adding the | (IoT) devices do not have LLDP and often have very restricted DHCP | |||
LLDP or DHCP options requires at least some minimal configuration | clients. Adding LLDP or DHCP options requires at least some minimal | |||
change, and possibly entire new subsystems. Meanwhile, use of the | configuration change and possibly entirely new subsystems. | |||
PKIX certification extension only makes sense as part of a larger | Meanwhile, use of the PKIX certification extension only makes sense | |||
IDevID based [ieee802-1AR] deployment such as [RFC8995]. | as part of a larger deployment based on an Initial Device Identifier | |||
(IDevID) [IEEE802-1AR], for instance, as described in [RFC8995]. | ||||
In the above cases these mechanisms can only be implemented by | In the above cases, these mechanisms can only be implemented by | |||
persons with access to modify and update the firmware of the device. | persons with access to modify and update the firmware of the device. | |||
In the meantime there is a chicken or egg problem ([chickenegg]): | In the meantime, there is a chicken or egg problem [chickenegg]. | |||
manufacturers are not motivated to (and thus likely do not) include | That is, manufacturers are not motivated to (and thus likely do not) | |||
MUD URLs in their products, as they believe that there are no | include MUD URLs in their products, as they believe that there are no | |||
gateways using those URLs. At the same time, gateways have little | gateways using those URLs. At the same time, gateways have little | |||
incentive to (and thus likely do not) include code that processes MUD | incentive to (and thus likely do not) include code that processes MUD | |||
URLs, as it is believed that no products have and disseminate them. | URLs, as it is believed that no products have or disseminate URLs. | |||
The protocol described in this document allows any person with | The protocol described in this document allows any person with | |||
physical access to the device to affix a reference to a MUD URL that | physical access to the device to affix a reference to a MUD URL that | |||
can later be scanned by an end user. | can later be scanned by an end user. | |||
The QR-based protocol is presented as a convenient alternative when | The QR-based protocol is presented as a convenient alternative when | |||
the mechanisms from RFC 8520 are not available to use, on the device | the mechanisms from [RFC8520] are not available to use on the device | |||
or the gateway. | or the gateway. | |||
Affixing a sticker can be done by | Affixing a sticker can be done by: | |||
* the marketing department of the Manufacturer, | * the marketing department of the manufacturer, | |||
* an outsourced assembler plant, | * an outsourced assembler plant, | |||
* value added resellers (perhaps in response to a local RFP), | * value-added resellers (perhaps in response to a local request for | |||
proposal (RFP)), | ||||
* a company importing the product (possibly to comply with a local | * a company importing the product (possibly to comply with a local | |||
regulation), | regulation), | |||
* a network administrator (perhaps before sending devices home with | * a network administrator (perhaps before sending devices home with | |||
employees, or to remote sites), | employees or to remote sites), and | |||
* a retailer as a value added service. | * a retailer as a value-added service. | |||
QRcodes are informally described in [qrcode] and formally defined in | QR codes are informally described in [qrcode] and formally defined in | |||
[isoiec18004]. The protocol described in this document uses a QRcode | [isoiec18004]. The protocol described in this document uses a QR | |||
to encode the MUD URL. Specifically, the protocol leverages the data | code to encode the MUD URL. Specifically, the protocol leverages the | |||
format from the Reverse Logistics Association's Standardized Quick | data format from the Reverse Logistics Association's Standardized | |||
Response for Logistics [SQRL]. | Quick Response for Logistics [SQRL]. | |||
SQRL codes are being put on devices via sticker or via laser etching | SQRL codes are being put on devices via a sticker or via laser | |||
into the case in order to deal with many situations, but specifically | etching into the case in order to deal with many situations but | |||
for end-of-life processing for the device. An important idea behind | specifically for end-of-life processing for the device. An important | |||
the effort is that clearly identifying a product permits appropriate | idea behind the effort is that clearly identifying a product permits | |||
disposal, refurbishment or recycling of the components of the | appropriate disposal, refurbishment, or recycling of the components | |||
product. | of the product. | |||
There are also use cases for SQRL described in which the codes are | There are also use cases for SQRL in which the codes are used as part | |||
used as part of regular maintenance for a product. | of regular maintenance for a product. | |||
SQRL is an application of the 12N Data Identifier system specified by | SQRL is an application of the 12N Data Identifier system specified by | |||
the ANSI MH10.8.2 Committee [mh10] in a format appropriate for | the ANSI MH10.8.2 Committee [mh10] in a format appropriate for QR | |||
QRcodes as well as other things like NFCs transmissions. | codes, as well as other things like Normalization Form C (NFC) | |||
transmissions. | ||||
QRcode generators are available as web services [qrcodewebservice], | QR code generators are available as web services or as programs, such | |||
or as programs such as [qrencode]. | as [qrencode]. | |||
Section 5 summarizes the considerations contained in | Section 5 summarizes the considerations contained in "Updating files | |||
[I-D.ietf-opsawg-mud-acceptable-urls] section 6.1 ("Updating MUD URLs | vs Updating MUD URLs" (Section 7.1 of [MUD-URLS]). Due to the | |||
vs Updating MUD files"). Due to the immutable nature of the QRcode, | immutable nature of the QR code, MUD URLs in this document will need | |||
MUD URLs in this document will need to be non-firmware specific. | to be non-firmware specific. | |||
2. Terminology | 2. Terminology | |||
Although this document is not an IETF Standards Track publication, it | Although this document is not an IETF Standards Track publication, it | |||
adopts the conventions for normative language to provide clarity of | adopts the conventions for normative language to provide clarity of | |||
instructions to the implementer. The key words "MUST", "MUST NOT", | instructions to the implementer. The key words "MUST", "MUST NOT", | |||
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", | |||
"RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this | "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in BCP 14 [RFC2119] | document are to be interpreted as described in BCP 14 [RFC2119] | |||
[RFC8174] when, and only when, they appear in all capitals, as shown | [RFC8174] when, and only when, they appear in all capitals, as shown | |||
here. | here. | |||
Readers should be familiar with the terminology in [RFC8520], | Readers should be familiar with the terminology in [RFC8520], | |||
including: MUD file, MUD URL, Manufacturer and MUD manager and | including: MUD file, MUD URL, manufacturer, MUD manager, and | |||
controller. | controller. | |||
3. Protocol | 3. Protocol | |||
This QRcode protocol builds upon the work by [SQRL]. That protocol | The QR code protocol builds upon the work by [SQRL]. That protocol | |||
is very briefly described in Section 3.1. Then the list of needed | is very briefly described in Section 3.1. Then, the list of needed | |||
Data Records to be filled in is explained. | Data Records to be filled in is explained. | |||
3.1. The SQRL Protocol | 3.1. The SQRL Protocol | |||
[SQRL] documents an octet protocol that can be efficiently encoded | [SQRL] documents an octet protocol that can be efficiently encoded | |||
into QRcodes using a sequence of ASCII bytes, plus six control codes | into QR codes using a sequence of US-ASCII bytes, plus six control | |||
(see section 3.1 of [SQRL]): | codes (see Section 3.1 of [SQRL]): | |||
* <RS> Record Separator (ASCII 30) | * <RS> Record Separator (US-ASCII 30) | |||
* <EoT> End of Transmission (ASCII 4) | * <EoT> End of Transmission (US-ASCII 4) | |||
* <FS> Field Separator (ASCII 28) | * <FS> Field Separator (US-ASCII 28) | |||
* <GS> Group Separator (ASCII 29) | * <GS> Group Separator (US-ASCII 29) | |||
* <US> Unit Separator (ASCII 31), | * <US> Unit Separator (US-ASCII 31) | |||
* Concatenation Operator (ASCII 43: "+"). | * Concatenation Operator (US-ASCII 43: "+") | |||
Section 7.2 of [SQRL] gives the details, which can be summarized as: | Section 7.2 of [SQRL] gives the details, which can be summarized as: | |||
1. The QR code header starts with: | 1. The QR code header starts with: | |||
"[)>" <RS> "06" <GS> "12N" | "[)>" <RS> "06" <GS> "12N" | |||
1. Include one or more Data Records. This consists of a four letter | 2. Include one or more Data Records. This consists of a four-letter | |||
Field Identifiers followed by ASCII characters terminated with a | Field Identifier, followed by US-ASCII characters terminated with | |||
<Unit Separator>. | a <Unit Separator>. | |||
2. End with: | 3. End with: | |||
<RS><EoT> | <RS><EoT> | |||
There are additionally optional flags that may be present in every | Additionally, there are optional flags that may be present in every | |||
Data Record as described in section 7.4 of [SQRL]. These flags have | Data Record, as described in Section 7.4 of [SQRL]. These flags have | |||
no bearing on MUD processing. A parser which is only collecting MUD | no bearing on MUD processing. A parser that is only collecting MUD | |||
URLs will not need to parse those flags. A general purpose SQRL | URLs will not need to parse those flags. A general-purpose SQRL | |||
parser will need more complexity. | parser will need more complexity. | |||
Field Separator characters are used in SQRL to signify the beginning | Field Separator characters are used in SQRL to signify the beginning | |||
of a new unit of data. A MUD specific parser that encounters a Field | of a new unit of data. A MUD-specific parser that encounters a Field | |||
Separator and has not yet collected the right MUD information MUST | Separator and has not yet collected the right MUD information MUST | |||
ignore the characters collected so far and then restart. | ignore the characters collected so far and then restart. | |||
Environment records, as described in [SQRL] section 7.4, look and act | Environment records, as described in Section 7.4 of [SQRL], look and | |||
exactly as fields, with a special Field Identifier. They serve no | act exactly as fields, with a special Field Identifier. They serve | |||
purpose when looking for MUD information, and MAY be ignored. | no purpose when looking for MUD information and MAY be ignored. | |||
3.2. Manufacturer Usage Descriptions in SQRL | 3.2. Manufacturer Usage Descriptions in SQRL | |||
3.2.1. B000 Company Name | 3.2.1. B000 Company Name | |||
The B000 Data Record is mandatory in [SQRL]. It MUST be in ASCII | The B000 Data Record is mandatory in [SQRL]. It MUST be in US-ASCII | |||
representation. It should be a representation of the company or | representation. It should be a representation of the company or | |||
brand name. It SHOULD match the ietf-mud/mud/mfg-name in the MUD | brand name. It SHOULD match the ietf-mud/mud/mfg-name in the MUD | |||
file, however the MUD file can contain arbitrary UTF8 for this name, | file; however, the MUD file can contain arbitrary UTF-8 for this | |||
while the SQRL files are expected to be 7-bit US-ASCII. | name, while the SQRL files are expected to be 7-bit US-ASCII. | |||
3.2.2. B001 Product Name | 3.2.2. B001 Product Name | |||
The B001 Data Record is optional in [SQRL]. It is the Product Name | The B001 Data Record is optional in [SQRL]. It is the Product Name | |||
in ASCII. Its presence is RECOMMENDED. Some third parties that | in US-ASCII. Its presence is RECOMMENDED. Some third parties that | |||
create QRcode stickers might not know the product name with 100% | create QR code stickers might not know the product name with 100% | |||
certainty, and MAY prefer to omit this rather than create further | certainty and MAY prefer to omit this rather than create further | |||
confusion. | confusion. | |||
3.2.3. B002 Model Number | 3.2.3. B002 Model Number | |||
The B002 Data Record is optional in [SQRL], but is MANDATORY in this | The B002 Data Record is optional in [SQRL] but is MANDATORY in this | |||
profile. It is the Model Name in ASCII. It SHOULD match the | profile. It is the Model Name in US-ASCII. It SHOULD match the | |||
optional ietf-mud/mud/model-name in the MUD file if that entry is | optional ietf-mud/mud/model-name in the MUD file if that entry is | |||
present in the MUD file. MUD files can contain arbitrary UTF8 for | present in the MUD file. MUD files can contain arbitrary UTF-8 for | |||
the model-name, while the SQRL files are expected to be 7-bit US- | the model-name, while the SQRL files are expected to be 7-bit US- | |||
ASCII. | ASCII. | |||
If a third party that is creating QRcodes can not locate an official | If a third party that is creating QR codes cannot locate an official | |||
model number when creating their MUD file and QRcode, then the third | model number when creating their MUD file and QR code, then the third | |||
party SHOULD make one up. | party SHOULD make one up. | |||
3.2.4. MUD URL Data Record | 3.2.4. MUD URL Data Record | |||
A new Field Identifier has been assigned by the Reverse Logistics | A new Field Identifier has been assigned by the Reverse Logistics | |||
Association (RLA), which is "M180" This record MUST be filled with | Association, which is "M180". This record MUST be filled with the | |||
the MUD URL. | MUD URL. | |||
Short URLs are easier to encode into QRcode because they require | Short URLs are easier to encode into a QR code because they require | |||
fewer pixels of QRcode. More content in the QRcode requires a bigger | fewer pixels of QR code. More content in the QR code requires a | |||
image. | bigger image. | |||
Use of URL shortening services (see [URLshorten]) can be useful | Use of URL shortening services (see [URLshorten]) can be useful, | |||
provided that the service is stable throughout the lifetime of the | provided that the service is stable throughout the lifetime of the | |||
device and QRcode, and that the privacy stance of the service is well | device and QR code and that the privacy stance of the service is well | |||
understood. The Security Considerations section of [RFC3986] | understood. The Security Considerations section of [RFC3986] | |||
applies, particularly section 7.1. | applies, particularly Section 7.1. | |||
Section 8.1 of [SQRL] also has some good advice on longevity concerns | Section 8.1 of [SQRL] also has some good advice on longevity concerns | |||
with URLs. | with URLs. | |||
The URL provided MUST NOT have a query (?) portion present. If one | The URL provided MUST NOT have a query (?) portion present. If one | |||
is present, the query portion MUST be removed before processing. | is present, the query portion MUST be removed before processing. | |||
3.2.5. Device MAC Address | 3.2.5. Device MAC Address | |||
If a MAC address is used as a unique device identifier (which is | If a Media Access Control (MAC) address is used as a unique device | |||
RECOMMENDED if possible), then it MUST be included in this Data | identifier (which is RECOMMENDED if possible), then it MUST be | |||
Record. | included in this Data Record. | |||
[SQRL] section 9.10 defines the Data Record: "M06C" as the MAC | Section 9.10 of [SQRL] defines the Data Record "M06C" as the MAC | |||
address. No format for the MAC address is provided in that document. | address. No format for the MAC address is provided in that document. | |||
This document RECOMMENDS 12 (or 16) hex octets are used with no | In this document, it is RECOMMENDED that 12 (or 16) hex octets are | |||
spaces or punctuation. (16 octets are used in the IEEE OUI-64 format | used with no spaces or punctuation. (16 octets are used in the IEEE | |||
used in 802.15.4, and some next generation Ethernet proposals) This | 64-bit Extended Unique Identifier (EUI-64) format used in | |||
document RECOMMENDS use of upper-case hexadecimal letters. | [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 ("-"), or | Parsers that find punctuation (such as colons (":"), dashes ("-"), | |||
white space) MUST skip over it. Parses MUST tolerate hexadecimal in | US-ASCII Space (32), US-ASCII TAB (0), US-ASCII linefeed (10), or US- | |||
both upper, lower and even mixed case. Systems SHOULD canonicalize | ASCII carriage return (13)) MUST skip over the punctuation. Parsers | |||
it to upper case. | MUST tolerate hexadecimal in uppercase, lowercase, and even mixed | |||
case. Systems SHOULD canonicalize it to uppercase. | ||||
4. Applicability | 4. Applicability | |||
The use of stickers to convey MUD URLs would appear to have little | The use of stickers to convey MUD URLs would appear to have little | |||
value when the stickers are applied by the end user organization and | value when the stickers are applied by the end-user organization and | |||
consumed by the same. This is particularly the case when the QR code | consumed by the same. This is particularly the case when the QR code | |||
does not include the device MAC address. In such a situation the | does not include the device MAC address. In such a situation, the | |||
installer handling the device would scan the QR code to get the | installer handling the device would scan the QR code to get the | |||
appropriate MUD file reference, and have to input the associated MAC | appropriate MUD file reference and have to input the associated MAC | |||
address as well. | address as well. | |||
In such a case, one might wonder why the installer couldn't just | In such a case, one might wonder why the installer couldn't just | |||
enter the appropriate MAC address and select the appropriate ACLs for | enter the appropriate MAC address and select the appropriate Access | |||
the device. No MUD file or QR code to convey it would be useful at | Control Lists (ACLs) for the device. Then a MUD file or QR code to | |||
all. | convey the MAC address would not be needed. However, the use of a | |||
MUD file (or QR code or other way to convey the MAC address) is | ||||
The use of a MUD file (or QR code other other way to convey it) has | advantageous because it offers several layers of indirection: | |||
the advantage that it offers several layers of indirection: | ||||
1. The list of ACLs for a given device may be added or removed. | 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 | 2. The ACLs may refer to DNS names, which may map to IPv4 or IPv6 | |||
addresses. | addresses. | |||
3. The entire file may be replaced, and may also include supply | 3. The entire file may be replaced and may also include supply chain | |||
chain information, such as Software Bill of Materials (SBOM). | information, such as Software Bill of Materials (SBOM). | |||
In addition, the mechanism to install a new device (MAC address) to | In addition, the mechanism to install a new device (MAC address) to | |||
MUD file mapping does not need to permit any other network security | MUD file mapping does not need to permit any other network security | |||
settings to be alterable by the person doing the installation. | settings to be alterable by the person doing the installation. | |||
5. Generic URL or Version Specific URL | 5. Generic URL or Version-Specific URL | |||
MUD URLs which are communicated in-band by the device, and which are | MUD URLs that are communicated in band by the device and that are | |||
programmed into the device's firmware may provide a firmware specific | programmed into the device's firmware may provide a firmware-specific | |||
version of the MUD URL. This has the advantage that the resulting | version of the MUD URL. The advantage of this is that the resulting | |||
Access Control Lists (ACLs) enforced in the network are specific to | ACLs enforced in the network are specific to the needs of that | |||
the needs of that version of the firmware. | version of the firmware. | |||
A MUD URL which is affixed to the device with a sticker, or etched | A MUD URL that is affixed to the device with a sticker or etched into | |||
into the case can not be changed. | the case cannot be changed. | |||
Given the considerations of [I-D.ietf-opsawg-mud-acceptable-urls] | Given the considerations of "Updating MUD URLs vs Updating MUD files" | |||
section 6.1 ("Updating MUD URLs vs Updating MUD files"), it is | (Section 6.1 of [MUD-URLS]), it is prudent to use a MUD URL that | |||
prudent to use a MUD URL which points to a MUD file which will only | points to a MUD file that will only have new features added over time | |||
have new features added over time, and never have features removed. | and never have features removed. To recap, if a feature is removed | |||
To recap, if a feature is removed from the firmware, and the MUD file | from the firmware and the MUD file still permits it, then there is a | |||
still permits it then there is a potential hole that could perhaps be | potential hole that could perhaps be exploited. The opposite | |||
exploited. The opposite situation, where a MUD file wrongly forbids | situation, where a MUD file wrongly forbids something, leads to false | |||
something leads to false positives in the security system, and | positives in the security system, and the evidence is that this | |||
evidence is that this results in the entire system being ignored. | results in the entire system being ignored. Preventing attacks on | |||
Preventing attacks on core infrastructure may be more important than | core infrastructure may be more important than getting the ACL | |||
getting the ACL perfect. | perfect. | |||
When the firmware eventually receives built-in MUD URL support, then | When the firmware eventually receives built-in MUD URL support, then | |||
a more specific URL may be used. | a more-specific URL may be used. | |||
Note that in many cases it will be third parties who are generating | Note that in many cases, it will be third parties who are generating | |||
these QRcodes, so the MUD file may be hosted by the third party. | these QR codes, so the MUD file may be hosted by the third party. | |||
6. Crowd Supply of MUD Files | 6. Crowd Supply of MUD Files | |||
At the time of writing, the IETF MUD is a new IETF Proposed Standard. | At the time of writing, the IETF MUD is a new IETF Proposed Standard. | |||
Hence, IoT device manufacturers have not yet provided MUD profiles | Hence, IoT device manufacturers have not yet provided MUD profiles | |||
for their devices. A research group at the University of New South | for their devices. A research group at the University of New South | |||
Wales (UNSW Sydney) has developed an open-source tool, called MUDgee | Wales (UNSW Sydney) has developed an open-source tool, called MUDgee | |||
([MUDgee]), which automatically generates a MUD file (profile) for an | [MUDgee], which automatically generates a MUD file (profile) for an | |||
IoT device from its traffic trace in order to make this process | IoT device from its traffic trace in order to make this process | |||
faster, easier, and more accurate. Note that the generated profile | faster, easier, and more accurate. Note that the generated profile | |||
completeness solely depends on the completeness of the input traffic | completeness solely depends on the completeness of the input traffic | |||
traces. MUDgee assumes that all the activity seen is intended and | traces. MUDgee assumes that all the activity seen is intended and | |||
benign. | benign. | |||
UNSW researchers have applied MUDgee to about 30 consumer IoT devices | UNSW researchers have applied MUDgee to about 30 consumer IoT devices | |||
from their lab testbed, and publicly released their MUD files | from their lab testbed and publicly released their MUD files | |||
([MUDfiles]). MUDgee can assist IoT manufacturers in developing and | [MUDfiles]. MUDgee can assist IoT manufacturers in developing and | |||
verifying MUD profiles, while also helping adopters of these devices | verifying MUD profiles, while also helping adopters of these devices | |||
to ensure they are compatible with their organisational policies. | to ensure they are compatible with their organizational policies. | |||
Similar processes have been done in a number of other public and | Similar processes have been done in a number of other public and | |||
private labs. One of the strong motivations for this specification | private labs. One of the strong motivations for this specification | |||
is to allow for this work to leave the lab, and to be applied in the | is to allow for this work to leave the lab and to be applied in the | |||
field. | field. | |||
7. Privacy Considerations | 7. Privacy Considerations | |||
The presence of the MUD URL in the QR code reveals the manufacturer | The presence of the MUD URL in the QR code reveals the manufacturer | |||
of the device, the type or model of the device, and possibly the | of the device, the type or model of the device, and possibly the | |||
firmware version of the device. | firmware version of the device. | |||
The MAC address of the device will also need to be present, and this | The MAC address of the device will also need to be present, and this | |||
is potentially Personally Identifiable Information (PII). Such | is potentially Personally Identifiable Information (PII). Such QR | |||
QRcodes should not be placed on the outside of the packaging, and | codes should not be placed on the outside of the packaging and only | |||
only on the device itself, ideally on a non-prominent part of the | on the device itself, ideally on a non-prominent part of the device | |||
device. (e.g., the bottom). | (e.g., the bottom). | |||
The QR code sticker should not be placed on any part of the device | 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 might become visible to machine vision systems in the same area. | |||
This includes security systems, robotic vacuum cleaners, anyone | This includes security systems, robotic vacuum cleaners, or anyone | |||
taking a picture with a camera. Such systems may store the | taking a picture with a camera. Such systems may store the | |||
picture(s) in such a way that a future viewer of the image will be | picture(s) in such a way that a future viewer of the image will be | |||
able to decode the QR code, possibly through assembly of multiple | able to decode the QR code, possibly through an assembly of multiple | |||
pictures. Of course, the QR code is not, however, a certain | pictures. Of course, the QR code is not, however, a certain | |||
indicator that the device is present, only that the QR code sticker | indicator that the device is present, only that the QR code sticker | |||
that came with the device is present. | that came with the device is present. | |||
The use of URL shorting services discussed in Section 3.2.4 may | The use of URL shorting services discussed in Section 3.2.4 may | |||
result in trading convenience and efficiency with privacy, since the | result in trading convenience and efficiency with privacy, since the | |||
service provider might leverage per-device or per-customer short URLs | service provider might leverage per-device or per-customer, short | |||
to track and correlate requests. | URLs to track and correlate requests. | |||
8. Security Considerations | 8. Security Considerations | |||
8.1. QR codes are not assurances | 8.1. QR Codes Are Not Assurances | |||
The mere presence of a QRcode on a device does not in itself create | The mere presence of a QR code on a device does not in itself create | |||
any security issues on its own. Neither an attached paper sticker or | any security issues on its own. Neither an attached paper sticker | |||
a laser etched code in a plastic case will affect the device | nor a laser-etched code in a plastic case will affect the device | |||
operation. | operation. | |||
The QRcode is not active, it is not in general able to communicate on | The QR code is not active; in general, it is not able to communicate | |||
nearby networks. It is conceivable that something more active is | using nearby networks. It is conceivable that something more active | |||
concealed in the sticker: an NFC or RFID tag for instance. But, any | is concealed in the sticker, e.g., an NFC or a Radio Frequency | |||
sticker could contain such a thing: on some university campuses | Identification (RFID) tag. But, any sticker could contain such a | |||
stickers are often used as part of political campaigns, and can be | thing, e.g., on some university campuses, stickers are often used as | |||
found attached all over the place. | part of political campaigns and can be found attached all over the | |||
place. | ||||
Security issues that this protocol create are related to assumptions | Security issues that this protocol creates are related to assumptions | |||
that the presence of the QRcode might imply. The presence of the | that the presence of the QR code might imply. The presence of the QR | |||
QRcode may imply to some owners or network operators that the | code may imply to some owners or network operators that the behavior | |||
behaviour of the device has been vetted by some authority. It is | of the device has been vetted by some authority. It is here that | |||
here that some caution is required. | some caution is required. | |||
A possibly bigger risk from application of MUD file stickers to | A possibly bigger risk from application of MUD file stickers to | |||
devices is that they may begin to convey a sense of safety to users | devices is that they may begin to convey a sense of safety to users | |||
of the device. The presence of the sticker, possibly with the logo | of the device. The presence of the sticker, possibly with the logo | |||
of the physical establishment in which the device is located could | of the physical establishment in which the device is located, could | |||
convey to occupants of the establishment that this device is an | convey to occupants of the establishment that this device is an | |||
official device. For instance, a university which only deploys | official device, for instance, a university that only deploys sensors | |||
sensors on the university campus that have been vetted for compliance | on the university campus that have been vetted for compliance against | |||
against a MUD definition. | a MUD definition. | |||
The risk is then of social engineering: any device with a reasonable | The risk is then of social engineering, e.g., any device with a | |||
looking QRcode may be seen as a trusted device (even though such | reasonable-looking QR code may be seen as a trusted device (even | |||
trust is not justified based on that evidence.) An attacker that | though such trust is not justified based on that evidence). An | |||
wishes to infiltrate their own devices need only suitably camouflage | attacker that wishes to infiltrate their own devices need only | |||
the device with an appropriate sticker in order to convey legitimacy. | suitably camouflage the device with an appropriate sticker in order | |||
to convey legitimacy. | ||||
8.2. MUD files can have signatures | 8.2. MUD Files Can Have Signatures | |||
The network operator who takes the MUD file designated by the QRcode | The network operator who takes the MUD file designated by the QR code | |||
needs to be careful that they are validating the signature on the MUD | needs to be careful that they are validating the signature on the MUD | |||
file. Not only that the file is intact, but that the signer of the | file. The network operator needs to verify that the file is intact | |||
file is authorized to sign MUD files for that vendor, or that the | and that the signer of the file is authorized to sign MUD files for | |||
network operator has some trust if the MUD file is a crowd sourced | that vendor, or if a MUD file is a crowd-sourced definition, they | |||
definition. At the time of writing, [RFC8520] does not define any | need to establish if it can be trusted. [RFC8520] does not define | |||
infrastructure to authenticate or authorize MUD file signers. | any infrastructure to authenticate or authorize MUD file signers. | |||
8.3. URL Shortening services can change content | 8.3. URL Shortening Services Can Change Content | |||
If a URL shorterning service is used, it is possible that the MUD | If a URL shortening service is used, it is possible that the MUD | |||
Controller is redirected to another MUD file with different content. | controller will be redirected to another MUD file with different | |||
The use of MUD signatures can detect attacks on the integrity of the | content. The use of MUD signatures can detect attacks on the | |||
file. To do this, the MUD controller needs to be able to verify the | integrity of the file. To do this, the MUD controller needs to be | |||
signature on the file. | able to verify the signature on the file. | |||
If a Trust On First Use (TOFU) policy is used for signature trust | If a Trust-On-First-Use (TOFU) policy is used for signature trust | |||
anchors, then the URL shortening service can still attack, if it | anchors, then the URL shortening service can still attack if it | |||
substitutes content and signature on the first use. MUD controllers | substitutes content and signature on the first use. MUD controllers | |||
and the people operating them need to be cautious when using TOFU. | and the people operating them need to be cautious when using TOFU. | |||
8.4. MUD QR code stickers could be confused | 8.4. MUD QR Code Stickers Could Be Confused | |||
Another issue with the stickers is that the wrong sticker could be | Another issue with the stickers is that the wrong sticker could be | |||
applied to a device by a reseller or other trusted party, either in | applied to a device by a reseller or another trusted party, either in | |||
error, or via some physical or socially engineered attack against | error or via some physical or socially engineered attack against that | |||
that party. The network operator now onboards a device, and applies | party. The network operator now onboards a device and applies what | |||
what they think is a legitimate network policy for the device in | they think is a legitimate network policy for the device in their | |||
their hands, only it is in fact a policy for another kind of device. | hands, only it is in fact a policy for another kind of device. | |||
Careful examination of stickers is in order! | Careful examination of stickers is in order! | |||
8.5. QR code can include MAC address | 8.5. QR Code Can Include a MAC Address | |||
Inclusion of the device specific MAC address (described in | Inclusion of the device-specific MAC address (described in | |||
Section 3.2.5) in the QRcode makes use of the MUD code much easier as | Section 3.2.5) in the QR code makes use of the MUD code much easier, | |||
it identifies the device specifically. If the MAC address is not | as it identifies the device specifically. If the MAC address is not | |||
included, then a network operator, having the device in their hands, | included, then a network operator, having the device in their hands, | |||
has to associate the policy with the device through some other | has to associate the policy with the device through some other | |||
interface. | interface. | |||
Despite the significant advantage of having the MAC address included, | Despite the significant advantage of having the MAC address included, | |||
it is unlikely that third party stickers will include that. | it is unlikely that third-party stickers will include it. Including | |||
Including the MAC address requires that a unique sticker with a | the MAC address requires that a unique sticker with a QR code be | |||
QRcode be created for each device. This is possible if the sticker | created for each device. This is possible if the sticker is applied | |||
is applied by a manufacturer: it is already common to have a serial | by a manufacturer; it is already common to have a serial number and | |||
number and MAC address on the outside of the device. In that case, | MAC address on the outside of the device. In that case, if the QR | |||
if the QRcode is part of that sticker, then the customization problem | code is part of that sticker, then the customization problem is not | |||
is not that complex. | that complex. | |||
For cases where a third party has produced the QRcode, it is likely | For cases where a third party has produced the QR code, it is likely | |||
that every device of a particular model will have the same QRcode | that every device of a particular model will have the same QR code | |||
applied, omitting the MAC address. This increases the possibility | applied, omitting the MAC address. This increases the possibility | |||
that the wrong policy will be applied to a device. | that the wrong policy will be applied to a device. | |||
9. IANA Considerations | 9. IANA Considerations | |||
This document makes no request for IANA actions. | This document has no IANA actions. | |||
10. Acknowledgements | ||||
This work was supported by the Canadian Internet Registration | ||||
Authority (cira.ca). | ||||
11. References | 10. References | |||
11.1. Normative References | 10.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage | [RFC8520] Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage | |||
Description Specification", RFC 8520, | Description Specification", RFC 8520, | |||
DOI 10.17487/RFC8520, March 2019, | DOI 10.17487/RFC8520, March 2019, | |||
<https://www.rfc-editor.org/info/rfc8520>. | <https://www.rfc-editor.org/info/rfc8520>. | |||
[SQRL] Reverse Logistics Association, "SQRL Codes: Standardized | [SQRL] Reverse Logistics Association, "SQRL Codes: Standardized | |||
Quick Response for Logistics, Using the 12N Data | Quick Response for Logistics, Using the 12N Data | |||
Identifier", February 2017, | Identifier", February 2017, | |||
<https://rla.org/resource/12n-documentation>. | <https://rla.org/resource/12n-documentation>. | |||
11.2. Informative References | 10.2. Informative References | |||
[chickenegg] | [chickenegg] | |||
Wikipedia, "Chicken or the egg", December 2019, | Wikipedia, "Chicken or the egg", April 2022, | |||
<https://en.wikipedia.org/wiki/Chicken_or_the_egg>. | <https://en.wikipedia.org/w/ | |||
index.php?title=Chicken_or_the_egg&oldid=1081728488>. | ||||
[I-D.ietf-opsawg-mud-acceptable-urls] | [IEEE.802.15.4] | |||
Richardson, M., Pan, W., and E. Lear, "Authorized update | IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE | |||
to MUD URLs", Work in Progress, Internet-Draft, draft- | Std. 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875, | |||
ietf-opsawg-mud-acceptable-urls-04, 6 October 2021, | April 2016, | |||
<https://www.ietf.org/archive/id/draft-ietf-opsawg-mud- | <https://ieeexplore.ieee.org/document/7460875>. | |||
acceptable-urls-04.txt>. | ||||
[ieee802-1AR] | [IEEE802-1AR] | |||
IEEE Standard, "IEEE 802.1AR Secure Device Identifier", | IEEE, "IEEE Standard for Local and Metropolitan Area | |||
2009, <http://standards.ieee.org/findstds/ | Networks - Secure Device Identity", IEEE Std 802.1AR-2018, | |||
standard/802.1AR-2009.html>. | August 2018, | |||
<https://standards.ieee.org/ieee/802.1AR/6995/>. | ||||
[isoiec18004] | [isoiec18004] | |||
ISO/IEC, "Information technology - Automatic | ISO/IEC, "Information technology - Automatic | |||
identification and data capture techniques - QR Code bar | identification and data capture techniques - QR Code bar | |||
code symbology specification (ISO/IEC 18004)", February | code symbology specification", ISO/IEC 18004:2015, | |||
2015. | February 2015. | |||
[mh10] "ANSI MH10.8.2 Committee", May 2021, | [mh10] ANSI, "Data Identifier and Application Identifier | |||
Standard", ANSI MH10.8.2-2016, June 2016, | ||||
<https://webstore.ansi.org/Standards/MHIA/ANSIMH102016>. | <https://webstore.ansi.org/Standards/MHIA/ANSIMH102016>. | |||
[MUDfiles] UNSW Sydney, "MUD Profiles", July 2019, | [MUD-URLS] Richardson, M., Pan, W., and E. Lear, "Authorized update | |||
to MUD URLs", Work in Progress, Internet-Draft, draft- | ||||
ietf-opsawg-mud-acceptable-urls-04, 6 October 2021, | ||||
<https://datatracker.ietf.org/doc/html/draft-ietf-opsawg- | ||||
mud-acceptable-urls-04>. | ||||
[MUDfiles] UNSW Sydney, "MUD Profiles", | ||||
<https://iotanalytics.unsw.edu.au/mud/>. | <https://iotanalytics.unsw.edu.au/mud/>. | |||
[MUDgee] Hamza, A., "MUDgee", July 2019, | [MUDgee] "MUDgee", commit f63a88d, July 2019, | |||
<https://github.com/ayyoob/mudgee>. | <https://github.com/ayyoob/mudgee>. | |||
[qrcode] Wikipedia, "QR Code", December 2019, | [qrcode] Wikipedia, "QR code", April 2022, | |||
<https://en.wikipedia.org/wiki/QR_code>. | <https://en.wikipedia.org/w/ | |||
index.php?title=QR_code&oldid=1082559657>. | ||||
[qrcodewebservice] | ||||
Internet, "QR Code Generators", December 2019, | ||||
<https://duckduckgo.com/?q=QR+code+web+generator>. | ||||
[qrencode] Fukuchi, K., "QR encode", December 2019, | [qrencode] "libqrencode", commit 715e29f, September 2020, | |||
<https://fukuchi.org/works/qrencode/index.html.en>. | <https://github.com/fukuchi/libqrencode>. | |||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifier (URI): Generic Syntax", STD 66, | Resource Identifier (URI): Generic Syntax", STD 66, | |||
RFC 3986, DOI 10.17487/RFC3986, January 2005, | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
<https://www.rfc-editor.org/info/rfc3986>. | <https://www.rfc-editor.org/info/rfc3986>. | |||
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data | |||
Interchange Format", STD 90, RFC 8259, | Interchange Format", STD 90, RFC 8259, | |||
DOI 10.17487/RFC8259, December 2017, | DOI 10.17487/RFC8259, December 2017, | |||
<https://www.rfc-editor.org/info/rfc8259>. | <https://www.rfc-editor.org/info/rfc8259>. | |||
[RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., | [RFC8995] Pritikin, M., Richardson, M., Eckert, T., Behringer, M., | |||
and K. Watsen, "Bootstrapping Remote Secure Key | and K. Watsen, "Bootstrapping Remote Secure Key | |||
Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, | Infrastructure (BRSKI)", RFC 8995, DOI 10.17487/RFC8995, | |||
May 2021, <https://www.rfc-editor.org/info/rfc8995>. | May 2021, <https://www.rfc-editor.org/info/rfc8995>. | |||
[URLshorten] | [URLshorten] | |||
Wikipedia, "URL shortening", May 2021, | Wikipedia, "URL shortening", April 2022, | |||
<https://en.wikipedia.org/wiki/URL_shortening>. | <https://en.wikipedia.org/w/ | |||
index.php?title=URL_shorteningg&oldid=1084979184>. | ||||
Acknowledgements | ||||
This work was supported by the Canadian Internet Registration | ||||
Authority (cira.ca). | ||||
Authors' Addresses | Authors' Addresses | |||
Michael Richardson | Michael Richardson | |||
Sandelman Software Works | Sandelman Software Works | |||
Email: mcr+ietf@sandelman.ca | Email: mcr+ietf@sandelman.ca | |||
Jacques Latour | Jacques Latour | |||
CIRA Labs | CIRA Labs | |||
Email: Jacques.Latour@cira.ca | Email: Jacques.Latour@cira.ca | |||
End of changes. 112 change blocks. | ||||
297 lines changed or deleted | 305 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |