Hi Eliot, Thanks for continuing the conversation. My question is how this fits into the system as a whole.
ISTM that there are two ways in which a MUD policy can affect the network's behavior: - Additive -- it lets the device do things it otherwise might not be permitted to do (e.g., accept incoming TCP connections) - Restrictive -- it stops the device from doing things that it otherwise would be permitted to do (e.g., make connections to IP addresses on non-443 ports) In the former case, it's very important not to be able to forge acceptable MUD policies, but in the latter case, an attacker can just not serve *any* MUD policy and be in a stronger position than they would be if they had a valid policy, Thus, it's only in the former (additive) case where forging a policy is useful to the attacker, and, in fact, it seems like accepting an unsigned MUD policy would be better than no policy. Given the ubiquity of non-MUD devices and the relatively limited capabilities that MUD seems to want to convey, it seems like the additive case isn't very useful. I should mention one use case that I did think of, where additive would be immediately useful: "This device is made by the same manufacturer as another device (and hence they can talk to each other). However, I note that MUD is actually not capable of securely conveying that, because there's no proof that the device in hand actually is made by the manufacturer, only that it possesses a public credential for some device made by that manufacturer. So, I'm actually left wondering how that feature is intended to work. I regret not catching this earlier, but perhaps you could explain? Thanks, -Ekr On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear <l...@cisco.com> wrote: > Hi Eric, > > Trimming. > > On 15.04.18 21:22, Eric Rescorla wrote: > > > > > >> 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). >> >> >> Yes, configuration is intended to be removed when a device disconnects or >> a session terminates. This would be considered normal garbage collection. >> But whether or not you can simply replace the firmware and gain the same >> access will depend on how the MUD-URL is learned. If it is in a >> manufacturer certificate, for instance, that's not something an attacker >> will easily replace. If the assertion is coming via LLDP, or DHCP, then >> one has to apply the mitigations discussed in the security considerations >> section (and they are numerous). >> > > I'm not following you here. Say it's in a manufacturer certificate, what > stops me from getting my own certificate for Attacker LLC and then serving > a wide open policy? The mitigations don't really seem to do much to > counteract this. > > > I believe this point and one down below, where you write: > > This doesn't seem to address my concern, which is that there's no > realistic way of knowing > what trust anchors apply. If it's not WebPKI, then what? > > are related, and so I propose to address them together, and this text > could go into security considerations. The *intent* is that mud managers > or their providers will keep a list of known trusted signers. Examples are > likely to include certification bodies (we are aware of at least one that > is very interested), the MUD manager vendor themselves, and perhaps > others. Because these are early days, I don't want to be too declarative, > but we can say this: > > NEW: > > --- > MUD managers and their administrators MUST NOT automatically trust a > manufacturer's certificate simply because it validates. Rather, the > certificate MUST be signed by an entity that has previously established > trust for this explicit purpose. In particular, the WebPKI alone is not > appropriate. > --- > > > That means that just because Joe Evil signed the darn thing doesn't mean > that we should believe it. On the other hand, I might trust a security > company to vet this stuff. Would this address your concern? Also, I'll > correct the previous factual error. > > And again, I view this as early days. The architecture is going to need > some time to mature and evolve. > > > > > > >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> >> 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. >> >> >> How about "end devices"? That makes it clear in the abstract. I don't >> propose to do a global substitute, because we scope the term well in the >> introduction, as you note directly below. >> > > To be honest, I would do a search and replace, but I agree that theis > would resolve the ambiguity here. > >> >> 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.) >> >> >> That these objects might happen to use a general purpose CPU or >> operations system doesn't in and of itself make them general purpose >> devices. As a complete SKU they are sold with a single or small number of >> uses in mind. That is what is posited. Is there a way to make that >> clearer? >> > > Perhaps "not intended to be used for general purpose computing tasks" > > > Ok. > > >> >> 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. >> >> >> I think this statement is predicated on your previous comment, and would >> prefer not to change text at this time. >> > > Hmmm.... No, I don't think you're reading me right here. I'm just saying > that it would be useful upfront to say that MUD > is about saying "this is what communications pattern these devices are > expected to have" > > > Ok. I think that's a good add, and propose to add a statement based on > your quoted text. > > Thanks again, > > Eliot >
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
