Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05

From: Kent Watsen <[email-masked]>
Date: Fri, 7 Apr 2017 01:37:08 +0000

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

---

From: Eliot Lear <[email-masked]>
Date: Fri, 7 Apr 2017 15:12:17 +0200

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.

> which would be a boon for all devices, including the "legacy" devices

Agreed.

> 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.

> 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

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.

> (e.g. a host-based firewall), but neither of these deployment scenarios
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.
>     See
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12#section-4.3.
>

Pretty much.  What would you want to be mandatory?

>   - s/the last time the MUD file was updated/when the MUD file was
Right.
>   - I also have an issue with the detached signature files (see my

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.

>     embedded MUD Controller) supposed to know how to process such

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.

>    to publish MUD files for it?   Do MUD files ever expire?   Is there

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. 
>   - 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.

>     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?

>   - Peeking ahead to Section 12.2 doesn't help much here (more on that

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.
>   - 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?

>   - 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.
>     the MUD file, to verifying the MUD file, and finally actualizing

I think you would like an order of operations, and I think that's fair. 
Will add.

>     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).

>   - '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.

>   - 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?
>   - s/Editor/Author/ in YANG 'contact' listing

Wilco.
>     of firmware/software is loaded on the device.

I'll make sure this is covered.

>     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.

>     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.

>     4) verifying the PKI that signed the MUD file hasn't been revoked,

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.
>     that?  Should it be explicitly forbidden?

As was discussed, we'll add a new container in the front to allow for
extensibility and validation.
>     device's MUD file even though the device has no on-going need to

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.
> https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-12#section-4.7.
I'll take a look.
>   -XML namespaces are supposed to be registered

Can you point me at the correct registry names?

>    - the footer on every page says "MUD YANG Model" but this draft is

Fixed.

>       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

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Apr 2017 20:36:05 +0200

Hi Brian,

Apologies for the late response.

On 3/31/17 6:40 AM, Brian Weis (bew) wrote:
> I support advancing this document, and have the following minor comments.
>
> (1) Section 1.3. LLDP should be referenced at first use. The wording
> at the beginning of Section 11 is nice: "IEEE802.1AB Link Layer
> Discovery Protocol (LLDP) [IEEE8021AB]”.

Fixed.
>
> (2) Section 1.4. An interesting policy example is:
>
> Allow access to host controller.example.com
> <http://controller.example.com> with QoS AF11

>
> I don’t see how QoS markings are defined in MUD. If not, then “ with
> QoS AF11” should be removed. Supporting QoS markings would be a good
> idea though.

Removed for now.  This might be something that we use an extension for.

>
> (3) Section 1.4 and beyond. The word “authority”, “authority
> component”, “authority section” are all used to mean the same thing,
> but without further explanation as to what this means. The
> inconsistency is confusing. But more importantly, it isn’t clear to
> the reader in those earlier sections that each “authority *" is a
> forward reference to the “authority element” in the URL definition
> (Section 5)  It would clearer if these references said something like
> “authority element of the MUD URL”.
I normalized to "authority component" where appropriate, and added a
brief definition.  That component is a domain name, roughly speaking.

>
> (4) Section 1.6. Regarding this text: "In the case of IEEE 802.1X, the
> switch would tunnel the URI via a certificate ….”.  The URI isn’t
> really “tunneled”. How about, "In the case of IEEE 802.1X, the switch
> would present a certificate containing the URI …”.

Corrected.
>
> (5) Section 3.2. For "it should not be necessary to resign a MUD file
> when a new one is released”, I believe you mean that the MUD file does
> not not need to be signed again (“re-sign”). Or do you really mean
> that the manufacturer will “resign” (e.g., “leave” or “stand down”)
> the MUD file by moving it to the archival location? If so, this needs
> to be clearer.
Right.  Re-sign.
>
> (6) Section 3.12. This section mentions "standard classes”. There’s
> should be a reference to what those classes would be, or more text
> describing what is a “standard class”. Should there be an IANA
> registry of “standard classes”?

Yes.  I don't actually have a registry for this, and maybe we need one.

Regards,

Eliot