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.
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.
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). 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?
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.
A) Having a remote enforcement point is not in anyway bad, but it
immediately triggers in my mind the need for the device to *securely*
identify its model type (MUD file location), which can get messy (e.g.,
if DevID, then how, and what if customer has installed an LDevID?),
and it raises the issue of how the remote enforcement point (or a
MUD Controller) obtains this information (esp. if it's not in the path
of the DHCP request and/or LLDP message). The draft explains that
such information could be forwarding from the switch the device is
physically connected to the MUD Controller, but then it raises the
question on why the switch wouldn't do the enforcement itself.
B) Having the device itself being an enforcement point is also not bad
but 1) devices don't really need a MUD file to know what access they
need and 2) self-enforcement somewhat defeats the point of what I
think makes MUD most interesting. Regarding devices not needing a
MUD file to know what access is needed, it’s understood that a MUD
file could be used to update the device's understanding even after it's
been shipped, but I find this highly unlikely, and certainly not likely
enough that a manufacturer would write code to support it.
Okay, so that's it for my high-level concerns, here are some more
detailed concerns:
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?
Section 3.1:
- s/the last time the MUD file was updated/when the MUD file was generated/
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)
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?
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?
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/
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?
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)
Section 3.11
- this field isn't clear
- how is this field in the matches expression supposed to be evaluated?
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...
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.
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?
- 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
Section 6
- should remove chairs for YANG 'contact' listing
- s/Editor/Author/ in YANG 'contact' listing
- should use rc:yang-data to declare a file artifact
Section 7.3
- should remove chairs for YANG 'contact' listing
- s/Editor/Author/ in YANG 'contact' listing
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.
- note that many times implementations that support IDevID also
support LDevID, would deployments then be required to put this
extension into their LDevID certs?
- 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 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.
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?
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?
- security considerations for yang modules not following guidelines. See
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12#section-4.7.
Section 15
- YANG modules are supposed to be registered
-XML namespaces are supposed to be registered
Other:
- the footer on every page says "MUD YANG Model" but this draft is
so much more!
- 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.
Skipped remaining sections in draft.
Thanks,
Kent
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
