Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
Hopefully this will be an easy DISCUSS to clear. Partially guided by some of the discussion that has already happened, it seems like there are three places where authentication/identity validation occurs in the MUD flow: the (CMS) signature alongside the MUD file, the TLS connection used to retrieve the MUD file, and the binding between the MUD URL and the device itself. The last one seems pretty important, especially given some of the points in Ekr's DISCUSS about limiting damage in case of compromised/malicious device. The security considerations already give some coverage in the first paragraph, but basically limited to the "manufacturer" groupings, and only covers the usage of the certificate extension for binding a MUD URL to a specific device. There's also some related text when considering what to do if the MUD URL for a given MAC address changes, but I didn't see any coverage for the general case. The entity using the MUD contents needs to be aware of the provenance of the URL and the risks of using a "spoofed" MUD from an attacker.
It's pretty exciting to have the prospect of getting this kind of information out there in a standard, machine-readable format. That said ... there's been a decent amount of talk of "still getting feet wet", "need to get experience how this unfolds", etc., so I have to ask: are we confident that this is better as Proposed Standard than Experimental? Adding the ability to use DNS names in ACL 'match' patterns should probably be accompanied by some note about the (lack of) veracity of DNS information. This is not a DISCUSS since the DNS name is expected to be what the Thing actually attempts to use, and the DNS resolver used by the Thing is likely to be the same one as used by the network, so in that sense the ACL will still "work as intended" even in the face of spoofed DNS. But we can probably mention that it's still a risk. I echo Ekr's question about CMS vs. JWS. Please consider using the BCP 14/RFC8174 boilerplate. Other comments (in document order, sorry about the interspersed nits). Section 1 o Substantially reduce the threat surface on a device entering a network to those communications intended by the manufacturer. Comma after 'network'? Section 1.5 [...] The DHCP server may take further actions, such as retrieve the URL or otherwise pass it along to network management system or controller. Retrieve the resource from the URL? Section 1.7 my-controller: Devices associated with the MUD URL of a device that the administrator admits. I'm probably just being dumb, but I am failing to parse what this means. Section 1.8 The information returned by the MUD file server (a web server) is valid for the duration of the Thing's connection, or as specified in the description. Thus if the Thing is disconnected, any associated configuration in the switch can be removed. Similarly, from time to time the description may be refreshed, based on new capabilities or communication patterns or vulnerabilities. This feels slightly internally inconsistent about valid/refreshed. Section 12.2 "Prior to retrieving a MUD file [...] validating the signature across the MUD file" is internally inconsistent. Perhaps the first pargaraph is stale, since the second paragraph basically duplicates it? Also, [...] For another, what is more important is the accountability of the recommendation, and not the cryptographic relationship between the device and the file. seems not really true. An example: % openssl cms -verify -in mudfile.p7s -inform DER -content % mudfile Note the additional step of verifying the common trust root. The additional step that's not included in the example? Maybe it could be included? Section 15 Lots of tiny comments, so I'll quote and put inline. % Based on how a MUD URL is emitted, a Thing may be able to lie about s/emitted/conveyed to the network/? % what it is, thus gaining additional network access. There are s/thus/potentially/ And maybe clarify ", based on the (false) MUD that is claimed"? % several means to limit risk in this case. The most obvious is to % only believe Things that make use of certificate-based authentication % such as IEEE 802.1AR certificates. When those certificates are not % present, Things claiming to be of a certain manufacturer SHOULD NOT % be included in that manufacturer grouping without additional % validation of some form. This will occur when it makes use of "occur" sounds more like it refers to the validation than the "claiming to be of a certain manufacturer"; maybe "be relevant"? % primitives such as "manufacturer" for the purpose of accessing Things % of a particular type. Similarly, network management systems may be % able to fingerprint the Thing. In such cases, the MUD URL can act as % a classifier that can be proven or disproven. Fingerprinting may % have other advantages as well: when 802.1AR certificates are used, % because they themselves cannot change, fingerprinting offers the % opportunity to add artificats to the MUD URL. The meaning of such typo ^^^^^^^^^^ This is the "reserved" field in the MUD URL? Maybe best to say so explicitly. % artifacts is left as future work. % % Network management systems SHOULD NOT accept a usage description for % a Thing with the same MAC address that has indicated a change of % authority without some additional validation (such as review by a % network administrator). New Things that present some form of This sentence could probably be tightened up. % unauthenticated MUD URL SHOULD be validated by some external means % when they would be otherwise be given increased network access. I'd suggest replacing "otherwise" with a more concrete condition. % It may be possible for a rogue manufacturer to inappropriately % exercise the MUD file parser, in order to exploit a vulnerability. % There are three recommended approaches to address this threat. The % first is to validate the signature of the MUD file. The second is to How does this help -- can't a rogue manufacturer sign whatever malformed blob it wants? % have a system do a primary scan of the file to ensure that it is both % parseable and believable at some level. MUD files will likely be % relatively small, to start with. The number of ACEs used by any % given Thing should be relatively small as well. It may also be % useful to limit retrieval of MUD URLs to only those sites that are % known to have decent web or domain reputations. % [...] % % The release of a MUD URL by a Thing reveals what the Thing is, and % provides an attacker with guidance on what vulnerabilities may be % present. It also seems to be permitted for the manufacturer to give Things unique MUD URLs and perform (e.g., location) tracking based on accesses to that URL... % While the MUD URL itself is not intended to be unique to a specific % Thing, the release of the URL may aid an observer in identifying % individuals when combined with other information. This is a privacy % consideration. ...even though you disclaim that intent. I suspect that any normative guidance on making MUD URLs non-identifying would not really be enforcable, but it may be worth mentioning this consideration earlier in the document (e.g., in Sections 5 and 10). Also, it's not necessarily just the "release" of the MUD URL, but the actual accesses by the MUD controller, that give the MUD URL's origin server real data about where the device being tracked is located/used. % In addressing both of these concerns, implementors should take into % account what other information they are advertising through % mechanisms such as mDNS[RFC6872], how a Thing might otherwise be % identified, perhaps through how it behaves when it is connected to % the network, whether a Thing is intended to be used by individuals or % carry personal identifying information, and then apply appropriate % data minimization techniques. One approach is to make use of TEAP % [RFC7170] as the means to share information with authorized % components in the network. Network elements may also assist in % limiting access to the MUD URL through the use of mechanisms such as % DHCPv6-Shield [RFC7610]. [...] Appendix C In this sample extension we augment the core MUD model to indicate whether the device implements DETNET. If a device later attempts to make use of DETNET, an notification or exception might be generated. Presumably this should say that if a device *claims to not use DETNET* but then later does?
Re-posted due to pilot error. Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3106 The threat model for MUD doesn't seem clear, at least to me. It seems like there are at least two potential threat models: - Telling the network how to configure access control to prevent the device from being compromised - Telling the network how to configure access control the limit the damage in case a device is compromised (e.g., avoiding its use in a botnet). Are both of these in scope? If so, the latter seems to need substantially more analysis -- and perhaps mechanism -- because it seems relatively easy for the attacker to evade access control limits once it has replaced the firmware on the device (as noted below). In either case, the document needs to be clear about this, whether in the security considerations or elsewhere. IMPORTANT > The certificate extension is described below. > > The information returned by the MUD file server (a web server) is > valid for the duration of the Thing's connection, or as specified in > the description. Thus if the Thing is disconnected, any associated > configuration in the switch can be removed. Similarly, from time to IMPORTANT: What does "disconnected" mean in this context? Does a reboot count? What if I am wireless? This is a critical question if MUD is intended as a post-compromise mechanism. Say that an attacker compromises the firmware for a device and then forces a reboot followed by a 2 hour pause before the wireless NIC is activated. Will this result in configuration removal? If so, MUD seems of limited use, because it can then make itself appear to be a new device with a new MUD configuration. (This is of course true in general in a wireless context if the firmware can change the client's L2 address). > https://example.com/lightbulbs/colour/v1 > > The MUD URL identifies a Thing with a specificity according to the > manufacturer's wishes. It could include a brand name, model number, > or something more specific. It also could provide a means to > indicate what version the product is. IMPORTANT: Are you just using "identify" loosely here? I see how it can be *based* on those characteristics, but absent a schema it doesn't seem like the MUD controller can infer any of those characteristics from the URL. > -in mudfile -binary -outform DER - \ > -certfile intermediatecert -out mudfile.p7s > > Note: A MUD file may need to be re-signed if the signature expires. > > 12.2. Verifying a MUD file signature IMPORTANT: This seem underspecified. Is the intention that these certificates will be rooted in the WebPKI? Something else? I realize that IETF tends to be kind of vague about where trust anchors come from, but at the end of the day its hard to see how to implement this interoperably without some more guidance.
> > Abstract > > This memo specifies a component-based architecture for manufacturer > usage descriptions (MUD). The goal of MUD is to provide a means for > Things to signal to the network what sort of access and network I realize that "Things" has become a marketing term, but it's opaque and unnecessary here. "elements" would be the conventional term. > it continues to make sense for general purpose computing devices > today, including laptops, smart phones, and tablets. > > [RFC7452] discusses design patterns for, and poses questions about, > smart objects. Let us then posit a group of objects that are > specifically not general purpose computers. These devices, which I don't think this makes sense. These devices usually *are* general purpose computers (turing complete, etc.) and not infrequently run the same operating systems (Android, for instance), but they're intended for specific purposes. In fact the core of the problem is that they are general purpose computers but embedded in a limited purpose device. > specifically not general purpose computers. These devices, which > this memo refers to as Things, have a specific purpose. By > definition, therefore, all other uses are not intended. The > combination of these two statements can be restated as a manufacturer > usage description (MUD) that can be applied at various points within > a network. I would make the point here that the purpose of the MUD is to describe the communications pattern. You only really get that by the statement in S 1.1 that the communication pattern of other devices is too complicated to profile. > can say about that light bulb, then, is that all other network access > is unwanted. It will not contact a news service, nor speak to the > refrigerator, and it has no need of a printer or other devices. It > has no social networking friends. Therefore, an access list applied > to it that states that it will only connect to the single rendezvous > service will not impede the light bulb in performing its function, This *might* be true, but imagine that I wanted to control my light bulbs over Tor and then I would want it to act as a Tor hidden service. > a public key. In these cases, manufacturers may be able to map those > identifiers to particular MUD URLs (or even the files themselves). > Similarly, there may be alternative resolution mechanisms available > for situations where Internet connectivity is limited or does not > exist. Such mechanisms are not described in this memo, but are > possible. Implementors should allow for this sort of flexibility of Do you mean SHOULD? > 1.6. Processing of the MUD URL > > MUD controllers that are able to do so SHOULD retrieve MUD URLs and > signature files as per [RFC7230], using the GET method [RFC7231]. > They MUST validate the certificate using the rules in [RFC2618], > Section 3.1. ITYM 2818. > > The files that are retrieved are intended to be closely aligned to > existing network architectures so that they are easy to deploy. We > make use of YANG [RFC7950] because of the time and effort spent to > develop accurate and adequate models for use by network devices. > JSON is used as a serialization for compactness and readability, Nit: "serialization format" > domain reputation service, and it may test any hosts within the > file against those reputation services, as it deems fit. > > 4. The MUD controller may query the administrator for permission to > add the Thing and associated policy. If the Thing is known or > the Thing type is known, it may skip this step. What is a "Thing type"? > > 2.1. The IETF-MUD YANG Module > > This module is structured into three parts: > > o The first container "mud" holds information that is relevant to This appears to be the only container. > > o The third component augments the tcp-acl container of the ACL > model to add the ability to match on the direction of initiation > of a TCP connection. > > A valid MUD file will contain two root objects, a "mud" container and MUST contain? > extension example can be found in Appendix C. > > 3.9. manufacturer > > This node consists of a hostname that would be matched against the > authority component of another Thing's MUD URL. In its simplest form In what encoding? > the expression as is appropriate in their deployments. > > 3.13. controller > > This URI specifies a value that a controller will register with the > MUD controller. The node then is expanded to the set of hosts that The use of "controller" and "MUD controller" is very unfortunate terminology. Could you perhaps rename one of these? Given that "controller" is encoded in the YANG model, perhaps "MUD agent"? > corresponding direction. [RFC6092] specifies IPv6 guidance best > practices. While that document is scoped specifically to IPv6, its > contents are applicable for IPv4 as well. When this flag is set, and > the system has no reason to believe a flow has been initiated it MUST > drop the packet. This node may be implemented in its simplest form > by looking at naked SYN bits, but may also be implemented through SYN seems over-specific here, as it doesn't apply to UDP-based protocols. > reserved = 1*( CHAR ) ; from [RFC5234] > > The entire option MUST NOT exceed 255 octets. If a space follows the > MUD URL, a reserved string that will be defined in future > specifications follows. MUD controllers that do not understand this > field MUST ignore it. This is a matter of taste I suppose, but why not just have two chunks in the option. The cost would be one byte in the non-extension case but then you would be able to handle extensions that brought the total length above 255. > 9.2. Server Behavior > > A DHCP server may ignore these options or take action based on > receipt of these options. If a server successfully parses the option > and the URL, it MUST return the option with length field set to zero > and a corresponding null URL field as an acknowledgment. Even in What this means here is "no URL field"? Generally, the use of "null" is confusing in the context of string processing because of C semantics. > > Because MUD files contain information that may be used to configure > network access lists, they are sensitive. To insure that they have > not been tampered with, it is important that they be signed. We make > use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for > this purpose. It's very odd to be using CMS here when you are serializing in JSON. This is a decision for the WG, but why aren't you using JWS?
Thank you for addressing the Gen-ART review.
I'm a Yes who's watching Discussions with other ADs, but that's still a Yes. Thanks for doing this work. I do have some questions and comments. I don't think this requires any changes to the current document, but I note that 3.15. direction-initiated When applied this matches packets when the flow was initiated in the corresponding direction. [RFC6092] specifies IPv6 guidance best practices. While that document is scoped specifically to IPv6, its contents are applicable for IPv4 as well. When this flag is set, and the system has no reason to believe a flow has been initiated it MUST drop the packet. This node may be implemented in its simplest form by looking at naked SYN bits, but may also be implemented through more stateful mechanisms. it's not clear that "looking at naked SYN bits" will have an analogy in HTTP/2 over QUIC, and I'm a bit suspicious of "may also be implemented through more stateful mechanisms" in 2018. Do the right thing, of course. Does 3.5. is-supported This boolean is an indication from the manufacturer to the network administrator as to whether or not the Thing is supported. In this context a Thing is said to not be supported if the manufacturer intends never to issue an update to the Thing or never update the MUD file. A MUD controller MAY still periodically check for updates. ever mean anything except "is-updated"? "Supported" covers a lot of ground … If a manufacturer sells off one product line (so, flobbidy.example.com covered multiple product lines, but now flobbidy.example.com/mark1/lightbulb will be maintained by a manufacturer that isn't flobbidy.example.com), is there a good plan for what comes next? I'm not sure what happens to is-supported, for instance. I'm sensitive to Eliot's "walk before trying to run" comment on another ballot thread, but I'm thinking that 3.11. model This string matches the entire MUD URL, thus covering the model that is unique within the context of the authority. It may contain not only model information, but versioning information as well, and any other information that the manufacturer wishes to add. The intended use is for devices of this precise class to match, to permit or deny communication between one another. might usefully result in a BCP about naming models, after the community has some experience with MUD. So, that's not intended to affect the current draft text, only the working group that produced it ;-) And, double ;-) ;-) but I wrote that before I saw this text in Section 14: A caution about some of the classes: admission of a Thing into the "manufacturer" and "same-manufacturer" class may have impact on access of other Things. Put another way, the admission may grow the access-list on switches connected to other Things, depending on how access is managed. Some care should be given on managing that access-list growth. Alternative methods such as additional network segmentation can be used to keep that growth within reason. So, when people know enough to describe best practices, I hope they do.
I was the RAD until Benoit stepped down and OpsAWG transferred to Ignas, did the AD review, etc.; any issues / blame should be directed at me.
Minor comments: 1) "is-supported" confused me a bit at the beginning. Maybe "is-maintained" could be a better name? 2) Why does the MUD file contain the MUD URL? Is this meant to be used as an identifier? 3) Given this document talks quite often about possible future extensions, I'm also wondering if this should be Experimental. However, I assume the framework/architecture that is defined in this doc is not suppoed to change and as such PS might be good as well. 4) I understand that the use of YANG is quite convinent for ACLs, however, I'm wondering if it is still the right choice if the MUD File would be used to describe more detailed behavior/traffic patterns. However, that should probably not be changed now, but might be another reason to go for experimental. Annother solution would be to further separate the architecture from the MUD file format (maybe into different doc?) and include a versioning mechanism in the MUD URL.
3.6. systeminfo This is a textual UTF-8 description of the Thing to be connected. The intent is for administrators to be able to see a localized name associated with the Thing. systeminfo is provided by the manufacturer (or whoever generated the MUD file), right? Why would it be *localized* for the administrator? Think of a manufacturer from China and a sysadmin in Russia. 3.13. controller This URI specifies a value that a controller will register with the MUD controller. The node then is expanded to the set of hosts that are so registered. This node may also be a URN. In this case, the URN describes a well known service, such as DNS or NTP. You don't list the DNS/NTP URNs until much later in the document. Please either add a forward reference or list them here. As per response from Eliot, my earlier comments should have been addressed in editor's copy: 16.4. MIME Media-type Registration for MUD files The following media-type is defined for transfer of MUD file: o Type name: application o Subtype name: mud+json o Required parameters: n/a o Optional parameters: n/a o Encoding considerations: 8bit; application/mud+json values are represented as a JSON object; UTF-8 encoding SHOULD be employed. I am tempted to say "MUST be UTF-8 encoded". o Security considerations: See Security Considerations of this document. o Interoperability considerations: n/a o Published specification: this document Nit: IANA Media Type registration templates need to have fully qualified references. Use "[RFCXXXX]" instead of "this document" here, so that when the RFC is published, the registration template can be posted to IANA website and will have correct reference. o Applications that use this media type: MUD controllers as specified by this document. As above. o Fragment identifier considerations: n/a o Additional information: Magic number(s): n/a File extension(s): n/a Macintosh file type code(s): n/a o Person & email address to contact for further information: Eliot Lear <email@example.com>, Ralph Droms <firstname.lastname@example.org> I think Ralph's address is wrong in 2 places. o Intended usage: COMMON o Restrictions on usage: none o Author: Eliot Lear <email@example.com> Ralph Droms <firstname.lastname@example.org> o Change controller: IESG o Provisional registration? (standards tree only): No. UTF-8 needs to be a Normative reference (RFC 3629).
I would like to thank everyone who worked on this document, and the authors in particular for clear, easy-to-read prose. The described mechanism seems quite useful. --------------------------------------------------------------------------- §1.3: > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > document are to be interpreted as described in [RFC2119]. This document also uses lowercase forms of these words. Consider using the boilerplate from RFC 8174. --------------------------------------------------------------------------- §1.6: > Section 5.3.2) containing "application/mud+json", an "Accept- > Language" header ([RFC7231], Section 5.3.5), and a "User-Agent" > header ([RFC7231], Section 5.5.3). s/header/header field/ (three times) --------------------------------------------------------------------------- §1.7: > JSON is used as a serialization for compactness and readability, Perhaps cite RFC 7159 here? --------------------------------------------------------------------------- §3.5: > A MUD controller MAY still periodically check for updates. I'm surprised to see this as a "MAY" rather than a "SHOULD." For example, even an unsupported device may be the subject of a CERT security advisory, and the manufacturer would presumably (if possible) take whatever mitigating steps would make sense. --------------------------------------------------------------------------- §8: > "ietf-acldns:src-dnsname": "test.com", The domain "test.com" is registered by an entity known as TESTCOM Inc. It's probably best to avoid its use in an example. I would propose "test.example.org" or something else reserved by RFC 6761. (This applies to three other locations in the document as well) --------------------------------------------------------------------------- §9: > reserved = 1*( CHAR ) ; from [RFC5234] Is there a reason to restrict this to be only 7 bits? --------------------------------------------------------------------------- §11: > The LLDP vendor specific frame has the following format: > > +--------+--------+----------+---------+-------------- > |TLV Type| len | OUI |subtype | MUD URL > | =127 | |= 00 00 5E| = 1 | > |(7 bits)|(9 bits)|(3 octets)|(1 octet)|(1-255 octets) > +--------+--------+----------+---------+-------------- Should this final field be a MUD URL? Or should it be the (extensible) MUDstring defined in §9? --------------------------------------------------------------------------- §12.2: > Prior to retrieving a MUD file the MUD controller SHOULD retrieve the > MUD signature file by retrieving the value of "mud-signature" and > validating the signature across the MUD file. I'm really confused about how this works. My understanding so far is that the Thing will provide a URL that points to the MUD file. Inside this MUD file is a "mud-signature" that points to the signature discussed in this section. So, to get to the MUD signature, the MUD controller has to first retrieve the MUD file. But the text above says that it SHOULD retrieve the signature before it retrieves the MUD file. How? --------------------------------------------------------------------------- §12.2: I'm surprised to see no discussion in here of duration of signature validity. I presume these will typically be cached by the MUD controller. --------------------------------------------------------------------------- §16.4: > o Security considerations: See Security Considerations > of this document. Ideally, this would also cite RFC 7159, section 12.
S2.1: Valid MUD file will contain "mud" and "acls" containers - what if it does not, especially if it does not contain an ACL container - how will the connectivity requirement be interpreted then? A few nits: s/MUR-URL/MUD-URL s/yang/YANG in the document and module description fields. s/dns/DNS in the modules. S1, MUD building blocks section: "A URL that is can be used"
Substantive: §1.6, 2nd paragraph: Why is the SHOULD not a MUST? §1.8, 4th paragraph: "The web server is typically run by or on behalf of the manufacturer. Its domain name is that of the authority found in the MUD URL. " These URLS are likely to be hardcoded, correct? This seems to point to operational considerations, especially around Thing lifecycle and ownership. Editorial/Nits: Abstract: I'm not sure the use of the term "Things" will be obvious to a reader of the abstract in isolation from the rest of the document. (Abstracts should be able to stand alone.) §1.1 : first paragraph: The idea that a Thing might have highly restricted communication patterns seems core to the document. It would be helpful to mention that earlier in §1. §1.3, definition of "Manufacturer": The definition says that "Manufacturer" may not necessarily be the entity that constructed the Thing. But that's the plain English meaning of the word "manufacturer". If you don't want it to mean that, please consider choosing a different term. ( for example, "authority") §1.4: "... we assume that a device has so few capabilities that it will implement the least necessary capabilities to function properly." That's a bit circular. Perhaps one of the two instances of "capabilities" should have been "requirements"? §1.8 4th paragraph: The 2nd (and last) sentence is a comma splice, and otherwise difficult to parse. §1.9, list item 7: are we talking about transient disconnect or permanent removal? §2: "A MUD file consists of a YANG model ..." A model instance, right? That is, not the model itself? §3.8, 2nd sentence: Consider reformulating this as a construction of MUST. §4: The idea of a "default" in bullet 2 seems in tension with the idea of "Anything not explicitly permitted is forbidden" in bullet 1. §14: Please define the concept of "east-west infection".
* Section 1.6 I looked at RFC2618 and there is nothing even remotely resembling certificate validation. I think this reference is wrong. Please fix. * Section 9.1 Who enforces this given that the DHCPv4 and DHCPv6 servers are separate? "In the case where both v4 and v6 DHCP options are emitted, the same URL MUST be used."