Re: [OPSAWG] Eric Rescorla's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

[Eliot Lear <[e-mail]>]

Hi Eric,

On 16.04.18 14:25, Eric Rescorla wrote:
> 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)

What you describe is the choice of the network administrator, and not
the standard nor the manufacturer.  You are essentially asking, “what is
the default policy?” and that will vary based on deployment.  It could
be "additive", "restrictive", or something else.  It could be a
walled-off IoT network.  Consider the cases:

  * This device has a MUD file and will be segmented accordingly.
  * This device has no MUD file and we may,
      o 1: give it no access,
      o 2: give it all access,
      o 3: give it some limited access,
      o 4: ask, or
      o 5: other.

All of these are perfectly valid approaches, depending on the deployment.
>
> 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,[...]

And so that will depend on the deployment.  And many of the attacks
would be detectable.  All?  I would never be so bold.  But also, MUD is
not an acronym for "magic bullet".  I really did try to spell that out
in the draft.

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

That is the point of building out a PKI, and as I wrote, there are some
interested in providing what amounts to a certification for this
purpose.  This is also something the MUD manager can take on: as time
goes on it can white list signers, and it can flag devices that are not
recognized as being risky.  In addition, if you have someone willing to
take accountability for that device to lay a claim, it may not be
"proof", but that is  good enough in an enterprise environment, where
someone can be called to account for having added the device.

And we have to start somewhere.  The goal here it to establish a “walk
before we run” approach in several dimensions.  I just ask that we be
allowed to walk ;-)

With that, how would you like to proceed?  I've proposed text but could
go further if you like.

Eliot