Hi Kent, Thanks very much for taking the time to review the draft. Based on your review, unless the WG objects, I'll include some changes as discussed below.
On 4/7/17 3:37 AM, Kent Watsen wrote: > > Hi, > > > > First off, I think that this is an interesting and useful idea. > However, I have > > found some issues that I'd like to discuss. > > > > First, I think that this draft unnecessarily conflates the MUD file > itself with > > mechanisms for how a device might identify its model type and/or where > > its MUD file can be accessed. The former is fairly innocuous (though > I raise > > issues with it below), whereas the latter raises numerous security > concerns > > that I think need to be addressed before this draft can move forward > as it > > is. But rather than holding the draft back indefinitely, I'd rather > these two > > aspects be separated, enabling the MUD file itself to progress quickly, > > which would be a boon for all devices, including the "legacy" devices > > raised by Tim Polk. > Agreed. > > > As for the parts that concern me, part of it goes to how the device > > identifies itself, but most of it goes to how the network consumes the > > MUD file. As mud-net-lifecycle-00 indicates, best results are had when > > the access is enforced on the port the device is connected to that, > for IoT > > devices, will most likely be a WAP. While not currently mandated by the > > architecture, assuming this would greatly reduce the need for the device > > to be able to prove its identity (really just its model number needs to be > > proved) as then the ability for the MitM/DoS attack I raised at the mic > > during the OPSAWG session. With the need for secure proof of identity > > off the table, even OS-fingerprinting techniques might be used to identity > > the device's model (rather than use a DHCP option or an LLDP extension), > > which could again be a way to gracefully support legacy devices. > I don't see anything wrong with doing OS-fingerprinting, and it seems a good idea to catch liars. I can add some text along these lines if you would like. > > > But for MUD to make a real difference, the enforcement point > > should be configured to assert MUD-based enforcement (unless it's been > > whitelisted). That is, an enforcement point configured this way would > > NOT provide any access by default (read: fail close). > This is a local policy choice, and it may be subtle. "fail close' might involve limited access to certain onboarding functions, for instance. Even without MUD one would assume in today's age that this is the case. > Please note that > > here I'm only referring to L2/L3 access, not anything at the L4-level, > such > > as provided by a device joining a "domain" as part of a bootstrapping > > protocol (e.g., brski). So, this port-level enforcement would actually be > > employed before the bootstrapping protocol and, as a consequence of > > us wanting to enable IoT devices to securely bootstrap, it means that all > > IoT device MUD files would need to outbound tcp/443 access, even if > > the device has no need to initiate HTTPS connections in normal operation. > > Is this what we want? > Continuing from my comment above, the order of operation is closer to "sandbox, bootstrap (perhaps with ANIMA), then implement specific policies with more access". This doesn't require that all MUD files include outbound 443, nor do we want that to be the case. > > > Of course, the enforcement point could also be a few hops away from > > the device (e.g., the WAN egress point), or even on the device itself > > (e.g. a host-based firewall), but neither of these deployment scenarios > > are wholly satisfactory. > In general I agree that the policy should be implemented as close to the device as possible. But (a) that might not be possible in some deployments and (b) that might not be the only place you want to apply the policy. The draft quite intentionally leaves WHERE to implement the access controls precisely so that the concept can stretch to a variety of scenarios. I think this is an important component to preserve. We'll probably want to stretch other aspects of MUD as well, but more around what sort of control knobs manufacturers will want. > > Section 2: > > - Tree diagram notation explanation missing. > > See > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12#section-4.3. > > - the tree diagram shows that all the fields are optional, is this > on purpose? > Pretty much. What would you want to be mandatory? > > > Section 3.1: > > - s/the last time the MUD file was updated/when the MUD file was > generated/ > Right. > > > > Section 3.2: > > - I don't really understand the point of this field > > - I definitely don't understand "Because it should not be necessary > to resign > > a MUD file when a new one is released" - especially when the field > regards > > the *previous* mud file > > - I also have an issue with the detached signature files (see my > comments on > > Section 12) > The idea was to be able to point to a chain of MUD files so that people could review changes. However, I wonder if the mechanism is really all that useful. Furthermore, I would suggest that we drop it and add it back later if people want it. > > > Sections 3.3: > > - others have mentioned this already > > > > Section 3.4 > > - I'm not entirely sure why this field is here, but I object to the > MUD file > > pointing to a BRSKI-specific component. Does this mean we can/should > > litter the file with other bootstrapping protocol data also? - > why stop at > > bootstrapping protocols, maybe other data would be useful too? > Is the > > device supposed to consume this field (how? - since it's not > guaranteed > > devices even get the MUD file) or are 3rd-party switches (i.e., with > > embedded MUD Controller) supposed to know how to process such > > fields? > I think this gets bundled to the concept of how the MASA server is identified in the bootstrapping process. The simplest mechanism is to have another extension in the certificate. And this ties to our discussion in the room as to what sort of URL should be in a cert at all. If the ANIMA folk want this out, then I think we should remove it. If the ANIMA folk want it in, then let's have it in. The nice thing of it being there is that the bootstrap server can be changed. > > > Section 3.5 > > - so, if a device is no longer supported, will the manufacturer continue > > to publish MUD files for it? Do MUD files ever expire? Is there > a replay- > > attack here? > The intent is to indicate that a file will no longer be updated. I think that's what the text states. Is it unclear? In addition, it's nice for administrators to easily be able to spot devices where the manufacturer claims they are not supported. In this sense it is a policy classifier. MUD files do NOT expire. I *think* the attack you are concerned about is someone promulgating an update that indicates the file is no longer supported. > > > > Section 3.6 > > - unclear how this field would be used > > - I know that it says that it's not for programmatic consumption, but > > shouldn't there be a field that contains something like a model-number > > so that the MUD Controller knows it got the right MUD file, and not a > > file for another device? [this is different than the acl 'model' > field below] > > - acronyms should be avoided: s/systeminfo/system-information/ > We agreed in the meeting to change this to change this to a URL pointing to a description (perhaps internationalized) of the device described in the MUD file. > > > Section 3.8 > > - the description in unclear, perhaps break into two sentences? > > - I think the idea is to create an ACL that allows the device to > > connect to its manufacturer, but why wouldn’t a MUD > > file use a something more generic like your dst-dnsname? > The system might not HAVE a dst-dnsname. Think of a bunch of lightbulbs. They're not going to register in DNS. And even if there were names assigned, they might not be aware of them. Also, this intended for an entire class of devices. There could be quite a lot of them. How would you propose to this clarify this point? > > > Section 3.9 > > - I don't understand this description either, but I see now from that it > > has something to do with the 'authority' hostname/FQDN component > > in the URL described in Section 5. > > - I get the impression that you're trying to introduce some mechanism > > whereby the manufacturer can delegate the MUD file signing ability > > to another entity. > > - Maybe not, but it does make me question how a MUD Controller is > > sure that its signer of the MUD File is actually authorized to > sign the > > MUD file? > > - Peeking ahead to Section 12.2 doesn't help much here (more on that > later) > This is nothing more than a shortcut for "manufacturer" where the authority section is exactly the same as that of the device associated with a given MUD URL. So, if I output https://eliot.example.com/...foo as my MUD-URL, same-manufacturer would be any device that output a MUD URL beginning with eliot.example.com. > > > > Section 3.11 > > - this field isn't clear > > - how is this field in the matches expression supposed to be evaluated? > I think we could use a statement about intent here. The intent is that "local-networks" match any system residing on a network within the same administrative scope. You could imagine it being defined to be a list of networks used by an enterprise. How might I word this better? > > > Section 3.12 > > - this field isn't clear > > - why would a [MUD] controller register a URI to an NMS? > > - NMS doesn't show up in Figure 1 or Terminology... > Changed NMS to mud controller. The intent is for controllers to identify themselves for the ease of the network administrator. We have not yet defined a mechanism to do that in an automated fashion, but the comment foreshadows that it is useful. > > > > Section 3.13 > > - also unclear > > > > Section 4 > > - This section needs to be greatly expanded to include everything from > > the MUD Controller being told to obtain a MUD file, to actually > obtaining > > the MUD file, to verifying the MUD file, and finally actualizing > the MUD file. > I think you would like an order of operations, and I think that's fair. Will add. > > > Section 5 > > - I'm generally unclear about the 'authority' field and how it's suppose > > to be used. E.g., is it required that the certificate the signs > the MUD > > file has the same authority value in its commonName or dnsName > > fields? - so then TLS server cert is also the MUDfile signer cert? > Keep in mind, that the MUD controller can process the URL using standard HTTP semantics. Authority is used in that sense. The intent at this point is not to require matching of common name to authority (we had something like that and removed it). > - How is the 'mud-rev' field supposed to work in practice. Let's say I > > by a new lightbulb and the manufacturer decides to use the then > > v2 revision of the MUD file format, but my switch/MUDcontroller > > is running older software and doesn’t know how to parse the new > > v2 fields, what does it do? > > - 'extras' needs to be described, even if just to say it’s a placeholder > > > It's up to future versions of MUD to decide appropriate backward compatibility mechanisms. Let's say that all of YANG gets refactored. v2 of MUD would take that into account, and probably require that manufacturers maintain a v1 version of the file as well. The mechanisms can get infinitely complex or remain relatively simple or something in between. We needn't answer that question today. > Section 6 > > - should remove chairs for YANG 'contact' listing > > - s/Editor/Author/ in YANG 'contact' listing > Wilco. > - should use rc:yang-data to declare a file artifact > Can you send me something more specific out of band? > > > > Section 7.3 > > - should remove chairs for YANG 'contact' listing > > - s/Editor/Author/ in YANG 'contact' listing > Wilco. > > > > Skipping Sections 8, 9 > > > > Section 10 > > - okay, but as mentioned at the mic, putting a URL into the IDevID > > cert is problematic if the URL needs to change based on what version > > of firmware/software is loaded on the device. > I'll make sure this is covered. > - note that many times implementations that support IDevID also > > support LDevID, would deployments then be required to put this > > extension into their LDevID certs? > There are two non-mutually-exclusive mechanisms. Copy the MUD URL into the LDevID or keep a table in the AAA server that associates a MUD URL with a given identity. > - presumably this use of the DevID cert for TEAP (as opposed to either > > the brski or zerotouch drafts, which both also use IDevID certs). I'm > > very concerned that we might have a chicken/egg problem here. > > > > Skipping Section 11 > > > > Section 12 > > - why do you have an external detached signature? since the signature > > is always required and MUST be verified, I'd expect that the MUD file > > would always be a signed CMS... > It's a matter of existing common tooling and readability. I'm happy to change but someone has to point to tooling that doesn't wreck readability. > - it says that new signers be validated, but what does that mean? > > - the verification part is not strong enough with regards to the > verifier > > 1) knowing it's using the right trust anchor, 2) knowing that it > has the > > right MUD file for the device, 3) knowing that the MUD file is not > expired, > > 4) verifying the PKI that signed the MUD file hasn't been revoked, > etc. > I think some of this should be covered in the order of operations to be added. There are two aspects of validation. Verifying that the signature matches the file and validating the signer in some way. We're not specifying the details of the latter at this time. > > > > Section 13 > > - already I mentioned concerns around how IETF revisions of the MUD file > > might be deployed > > - but here is suggests that vendors could create their own augmentations > > of the YANG file, how are 3rd-party MUD Controllers supposed to handle > > that? Should it be explicitly forbidden? > As was discussed, we'll add a new container in the front to allow for extensibility and validation. > > > > Section 14 > > - all [IoT] devices presumably bootstrap, therefore (per > brski/zerotouch) > > all these devices need to access outbound HTTPS. Would this go > into the > > device's MUD file even though the device has no on-going need to > > initiate outbound HTTPS? > See above. You shouldn't need to add it into the file. Also just a note- with BrSKI there is no need for the device to have end to end connectivity with the manufacturer's MASA server. That is what the registrar is for. > > - security considerations for yang modules not following > guidelines. See > > > https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12#section-4.7. > I'll take a look. > > > > Section 15 > > - YANG modules are supposed to be registered > > -XML namespaces are supposed to be registered > Can you point me at the correct registry names? > > > Other: > > - the footer on every page says "MUD YANG Model" but this draft is > > so much more! > Fixed. > - parroting the comment made previously, I'd prefer this draft be > broken > > up into a draft that describes the MUD file artifact that then > other draft(s) > > that describe how devices are identified and MUD files are obtained. > We started there and were told to collapse. That having been said, I'm happy to clarify the architectural components, as I mentioned to Tim. Eliot > > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
