Reviewer: Christian Huitema Review result: Has Issues Mud URL I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. draft-ietf-opsawg-mud-acceptable-urls-10 defines rules for accepting updated MUD URL from devices. It is part of the MUD architecture defined in RFC 8520, in which: * MUD capable devices publish a MUD URL on the local network, * the "MUD Manager" on the local network uses the MUD URL to retrieve a "MUD File" from the MUD-server managed by the device "manufacturer" (for some definition of manufacturer) * the MUD Manager parses the file and deduces restrictions, such as which URL the device is allowed to contact * the MUD manager programs local switches and routers to prevent the device from accessing network locations not authorized in the MUD File. The goal is to create some kind of "sandbox" around the device and limit the damage that can be caused if the device happens to be affected by a virus. The draft addresses what happens if the device starts publish a new MUD URL. There are legitimate reasons to do that, for example if the device firmware is upgraded and its communication posture changes, if the manufacturer of the device wants to migrate to a new server, or in cases of merger and acquisitions when the new "manufacturer" wants to migrate to a new infrastructure. There are also illegitimate reason, such as a virus on the device trying to publish a new MUD URL leading to much more permissive network configuration. The rules in the draft attempt to distinguish between the legitimate and illegitimate cases. The MUD URL plays a critical role, but the most popular ways to propagate it on the local network are passing it as a client attribute in DHCP requests or advertising it through the Link Local Discovery protocol (LLDP). Both methods are easy to spoof. The draft bases a lot of verification on parsing of the MUD Files, which contain a copy of the MUD URL and an attestation of the validity of that URL signed with credentials of the manufacturer. MUD files are signed by the manufacturer, see section 13 of RFC8520. The proposed solution is to assess the validity of the new MUD URL by comparing it to a reference version, captured during the first use of the device. If the MUD URL is published by an insecure channel such as DHCP or LLDP, this amounts to trust on first use. The proposed rules distinguish between "small changes", such as changing the URL from "https://example.com/widget-x/revision1.html"; to "https://example.com/widget-x/revision2.html";, and "big changes" such as changing to "https://example.com/new-database/widget-x/revision1.html"; (new server organization) or to "https://foo.example/legacy/widget-x/revision1.html"; (new manufacturer name). The rule for "big changes" specifies a multistep process: 1) the manufacturer updates the server so that the old MUD URL points to a new content, which embeds the the new MUD URL. 2) the manufacturer updates the firmware of the device to point to the new URL 3) the MUD manager sees the new URL, but first verify that this is expected by load the MUD file at the old URL. If that file references the new URL, and if it verifies correctly, the MUD Manager accepts the new URL. That process relies on the verification rules for MUD Files and the URL that they contain. It also relies on "conditional HTTP requests" (RFC7232) and HTTP cache control (RFC7234) to ensure that the MUD Manager acquires the up-to-date version of the MUD File at the old URL. If the manufacturer credentials are changing, the MUD file at the old location is signed using the old credentials, but the manufacturer also publishes includes a "detached signature" with the new credentials. This process generally looks sound, but the "detached signature" part is under specified. Is this an implicit reference to PKCS7? How is the MUD Manager supposed to retrieve the detached signature? The rule for small changes are lighter weight. The MUD manager will simply accept the new URL if the old and new URL start with the same prefix. This "common prefix" rule for "small changes" is light weight but has an obvious hole. Suppose that a manufacturer has first published a rather loose rule in "https://example.com/widget-x/revision1.html";, and then upgraded it to a stricter rule in "https://example.com/widget-x/revision2.html";. The common prefix rule will not prevent the virus from "rolling back" to revision1. A simple solution would be for the manufacturer to update the MUD FILE served at the old MUD URL so that it point to the new MUD URL -- which is exactly what the manufacturer would do under the "big change" rules. The "rolling back" problem would of course disappear if the draft proposes just one solution for all changes, and followed the "big changes" rules regardless of how many characters match between old and new URL. I would recommend doing just that. If the authors really want to keep the "small changes" rule, they need to fix its specification. In the current draft, a change is considered small if the old and new URL start with the same prefix. To quote: "remove everything to the right of the last (rightmost) "/" in the URL of "root" MUD file URL, and the proposed new URL." Such description makes me cringe, because it amount to describing a "shotgun parser" (see: https://langsec.org/papers/langsec-cwes-secdev2016.pdf). Compare that to the description of a valid HTTPS URI in RFC 9110: https-URI = "https" "://" authority path-abempty [ "?" query ] And the definitions of path-abempty and query in RFC 3986: path-abempty = *( "/" segment ) segment = *pchar query = *( pchar / "/" / "?" ) The shotgun parser will fail if the query string includes a "/", which can have consequence such as refusing to accept an otherwise valid URL. Please rewrite that description using proper references to RFC 3986 and RFC 9110. Standardizing on a single "big change" rule will avoid the need to mess with the URL syntax, and will also remove the need to request that manufacturers "maintain an orderly layout of MUD files in their web servers, with each unique product having its own directory/pathname." Order there is in the eyes of the beholder, and the recommended 'order" may not feel all that natural for some database or file storage technologies. Regarding the security consideration section, I notice that there is a mild DOS attack possible against MUD Managers and MUD servers. The new MUD URL are advertised using insecure processes, DHCP or LLDP. Attackers with access to the local network can spoof that. The MUD manager will have to retrieve and try to validate the new MUD file, which requires a combination of network access and cryptographic validation, and probably triggers some intrusion detection system. In the security considerations, I would also outline that the comparison between "old" and "new" URL assumes that both can be linked to the same device identity, presumably based on L2 identity such as MAC address. A virus could break that by changing the MAC address of the device. There is some discussion of the device identity issue in the security considerations of RFC8520. It might be useful to outline the identity issue in the security consideration, and point to the relevant content in RFC8520. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
