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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
