Subject: [OPSAWG] Benjamin Kaduk's Discuss on draft-ietf-opsawg-mud-20: (with DISCUSS and COMMENT)

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 17 Apr 2018 08:31:00 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-opsawg-mud-20: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hopefully this will be an easy DISCUSS to clear.

Partially guided by some of the discussion that has already happened, it seems
like there are three places where authentication/identity validation occurs in
the MUD flow: the (CMS) signature alongside the MUD file, the TLS connection
used to retrieve the MUD file, and the binding between the MUD URL and the
device itself.  The last one seems pretty important, especially given some of
the points in Ekr's DISCUSS about limiting damage in case of
compromised/malicious device.  The security considerations already give some
coverage in the first paragraph, but basically limited to the "manufacturer"
groupings, and only covers the usage of the certificate extension for binding a
MUD URL to a specific device.  There's also some related text when considering
what to do if the MUD URL for a given MAC address changes, but I didn't see any
coverage for the general case.  The entity using the MUD contents needs to be
aware of the provenance of the URL and the risks of using a "spoofed" MUD from
an attacker.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's pretty exciting to have the prospect of getting this kind of information
out there in a standard, machine-readable format.  That said ... there's been a
decent amount of talk of "still getting feet wet", "need to get experience how
this unfolds", etc., so I have to ask: are we confident that this is better as
Proposed Standard than Experimental?

Adding the ability to use DNS names in ACL 'match' patterns should probably be
accompanied by some note about the (lack of) veracity of DNS information.  This
is not a DISCUSS since the DNS name is expected to be what the Thing actually
attempts to use, and the DNS resolver used by the Thing is likely to be the
same one as used by the network, so in that sense the ACL will still "work as
intended" even in the face of spoofed DNS.  But we can probably mention that
it's still a risk.

I echo Ekr's question about CMS vs. JWS.

Please consider using the BCP 14/RFC8174 boilerplate.

Other comments (in document order, sorry about the interspersed nits).

Section 1

   o  Substantially reduce the threat surface on a device entering a
      network to those communications intended by the manufacturer.

Comma after 'network'?

Section 1.5

      [...] The DHCP server may take further actions,
      such as retrieve the URL or otherwise pass it along to network
      management system or controller.

Retrieve the resource from the URL?

Section 1.7

   my-controller:  Devices associated with the MUD URL of a device that
      the administrator admits.

I'm probably just being dumb, but I am failing to parse what this
means.

Section 1.8

   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
   time the description may be refreshed, based on new capabilities or
   communication patterns or vulnerabilities.

This feels slightly internally inconsistent about valid/refreshed.

Section 12.2

"Prior to retrieving a MUD file [...] validating the signature
across the MUD file" is internally inconsistent.  Perhaps the first
pargaraph is stale, since the second paragraph basically duplicates
it?

Also,
   [...] For another, what is more important
   is the accountability of the recommendation, and not the
   cryptographic relationship between the device and the file.
seems not really true.

   An example:

   % openssl cms -verify -in mudfile.p7s -inform DER -content
   % mudfile

   Note the additional step of verifying the common trust root.

The additional step that's not included in the example?  Maybe it
could be included?

Section 15

Lots of tiny comments, so I'll quote and put inline.

% Based on how a MUD URL is emitted, a Thing may be able to lie about

s/emitted/conveyed to the network/?

% what it is, thus gaining additional network access.  There are

s/thus/potentially/
And maybe clarify ", based on the (false) MUD that is claimed"?

% several means to limit risk in this case.  The most obvious is to
% only believe Things that make use of certificate-based authentication
% such as IEEE 802.1AR certificates.  When those certificates are not
% present, Things claiming to be of a certain manufacturer SHOULD NOT
% be included in that manufacturer grouping without additional
% validation of some form.  This will occur when it makes use of

"occur" sounds more like it refers to the validation than the
"claiming to be of a certain manufacturer"; maybe "be relevant"?

% primitives such as "manufacturer" for the purpose of accessing Things
% of a particular type.  Similarly, network management systems may be
% able to fingerprint the Thing.  In such cases, the MUD URL can act as
% a classifier that can be proven or disproven.  Fingerprinting may
% have other advantages as well: when 802.1AR certificates are used,
% because they themselves cannot change, fingerprinting offers the
% opportunity to add artificats to the MUD URL.  The meaning of such

typo                 ^^^^^^^^^^
This is the "reserved" field in the MUD URL?  Maybe best to say so
explicitly.

% artifacts is left as future work.
%
% Network management systems SHOULD NOT accept a usage description for
% a Thing with the same MAC address that has indicated a change of
% authority without some additional validation (such as review by a
% network administrator).  New Things that present some form of

This sentence could probably be tightened up.

% unauthenticated MUD URL SHOULD be validated by some external means
% when they would be otherwise be given increased network access.

I'd suggest replacing "otherwise" with a more concrete condition.

% It may be possible for a rogue manufacturer to inappropriately
% exercise the MUD file parser, in order to exploit a vulnerability.
% There are three recommended approaches to address this threat.  The
% first is to validate the signature of the MUD file.  The second is to

How does this help -- can't a rogue manufacturer sign whatever
malformed blob it wants?

% have a system do a primary scan of the file to ensure that it is both
% parseable and believable at some level.  MUD files will likely be
% relatively small, to start with.  The number of ACEs used by any
% given Thing should be relatively small as well.  It may also be
% useful to limit retrieval of MUD URLs to only those sites that are
% known to have decent web or domain reputations.
%
[...]
%
% The release of a MUD URL by a Thing reveals what the Thing is, and
% provides an attacker with guidance on what vulnerabilities may be
% present.

It also seems to be permitted for the manufacturer to give Things
unique MUD URLs and perform (e.g., location) tracking based on
accesses to that URL...

% While the MUD URL itself is not intended to be unique to a specific
% Thing, the release of the URL may aid an observer in identifying
% individuals when combined with other information.  This is a privacy
% consideration.

...even though you disclaim that intent.  I suspect that any
normative guidance on making MUD URLs non-identifying would not
really be enforcable, but it may be worth mentioning this
consideration earlier in the document (e.g., in Sections 5 and 10).
Also, it's not necessarily just the "release" of the MUD URL, but
the actual accesses by the MUD controller, that give the MUD URL's
origin server real data about where the device being tracked is
located/used.

% In addressing both of these concerns, implementors should take into
% account what other information they are advertising through
% mechanisms such as mDNS[RFC6872], how a Thing might otherwise be
% identified, perhaps through how it behaves when it is connected to
% the network, whether a Thing is intended to be used by individuals or
% carry personal identifying information, and then apply appropriate
% data minimization techniques.  One approach is to make use of TEAP
% [RFC7170] as the means to share information with authorized
% components in the network.  Network elements may also assist in
% limiting access to the MUD URL through the use of mechanisms such as
% DHCPv6-Shield [RFC7610].
[...]

Appendix C

   In this sample extension we augment the core MUD model to indicate
   whether the device implements DETNET.  If a device later attempts to
   make use of DETNET, an notification or exception might be generated.

Presumably this should say that if a device *claims to not use
DETNET* but then later does?

---

From: Eliot Lear <[email-masked]>
Date: Tue, 17 Apr 2018 19:54:08 +0200

Hi Ben,

Maybe we can swat two birds with one stone here, so to speak.  I think
both EKR and I have been ruminating on the right text, and hopefully
between the three of us, and perhaps others from the community we can
zero in on what is needed.  

> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

I think EKR's last statement jibes well with what you are saying.  I
propose an amended first paragraph of the security considerations
section, to address that last point as follows:
> Devices emitting MUD URLs that are not signed by someone else may lie,
> potentially gaining additional network access by pretending to be
> something it is not.  In these cases, while we describe some
> mitigations below, a risk of lying remains in some circumstances,
> particularly when a device may masquerade as another device that has
> already been approved to be on the network, but it isn't currently
> connected.  There are two overarching mitigations for this case:
>
>  * Best mitigation: devices should migrate to the use of  802.1AR
> certificate.
>  * 2nd best mitigation: do not grant such devices access to critical
>    resources, recognizing that attackers may be masquerading as
>    them.
>
> In addition, even those    devices    that do    have manufacturer
> certificates
> may be attackers.  MUD managers    that do    not recognize a  
>  signer MUST
> seek approval of the administrator prior to further processing.
>
> Additional mitigations are described below.
>
> When certificates are not present, Things claiming to be of a certain
> manufacturer SHOULD NOT be included in that manufacturer grouping
> without additional validation of some form. 

--

The LLDP and DHCP options are not nothing.  In the context of a
physically secure environment they can go a long way and at least deter
if not stop a fair amount of nonsense.  But they are by no means perfect.

With this having been said, I hope you would both be comfortable with
the above text, or perhaps with some additional suggestions.

There's good reason to get to proposed.  We will never get enough
manufacturers to get the operational experience we need to get to the
next stage if it is not.  Vendors in this arena simply don't move on
experimental work.

> I echo Ekr's question about CMS vs. JWS.

Please see my response in that context.

> Please consider using the BCP 14/RFC8174 boilerplate.

I propose to make that change.

>       network to those communications intended by the manufacturer.

I propose to trim this to:

 * Substantially reduce the threat surface on a device to those
   communications intended by the manufacturer.

I propose the following:

> The DHCP server may take further actions, such as
>    act as the MUD manager or otherwise pass it along to the MUD manager.

> I'm probably just being dumb, but I am failing to parse what this

Would the following be clearer?

> Devices intended to serve as controllers for the MUD-URL that    the
> thing emitted.

> This feels slightly internally inconsistent about valid/refreshed.

There are two concepts at play here:

  * When the device goes away or is unplugged
  * When the MUD file itself has been updated.

We am attempting to capture both.  Apparently badly.

How about the following:

> The information returned by the MUD file server is valid for as long
> as the Thing is connected.  There is no expiry.  However, if the MUD
> manager has detected that the MUD file for a Thing has changed, it
> SHOULD update the policy expeditiously, taking into account whatever
> approval flow is required in a deployment.  In this way, new
> recommendations from the manufacturer can be processed in a timely
> fashion.

Totally.  I propose to remove the SHOULD and leave the MUST, as follows:
> Prior to retrieving a MUD file the MUD manager MUST retrieve the MUD
> signature file by retrieving the value of "mud-signature" and
> validating the signature across the MUD file.  A MUD manager MUST
> cease processing of that file it cannot validate the chain of trust to
> a known trust anchor until an administrator has given approval.

> The additional step that's not included in the example?  Maybe it

That essentially means installing a trust anchor for this purpose.  Let
me see what I can do.

> s/emitted/conveyed to the network/?

I believe this text is about to change.

Assuming this text remains...  edited as follows:
>  Thing may be able
> to lie about what it is, potentially gaining additional network access
> by pretending to be something it is not.

> "claiming to be of a certain manufacturer"; maybe "be relevant"?

ok.
> This is the "reserved" field in the MUD URL?  Maybe best to say so

ok: propose

>  Fingerprinting may have
> other advantages as well: when 802.1AR certificates are used, because
> they themselves cannot change, fingerprinting offers the opportunity
> to add artifacts to the MUD URL in the form of the reserved field
> discussed in {{dhcpopt}}.

> This sentence could probably be tightened up.

Will try with small edits.

> I'd suggest replacing "otherwise" with a more concrete condition.

I think the best way to deal with this is to delete "otherwise".

> How does this help -- can't a rogue manufacturer sign whatever

Let's restate that:

The first is to validate that the signer of the MUD file is known to and
trusted by the MUD manager.

> unique MUD URLs and perform (e.g., location) tracking based on

It's not the best method.  For one thing, the MUD manager may be nowhere
near where the device is.  For another, if the device can communicate
with the manufacturer at all, it can directly convey that information
without going through MUD.  But it might be possible.  It can also be
remediated, as it happens.  See below.
> origin server real data about where the device being tracked is

I propose to (a) list this risk and (b) propose the following
remediations to address this sort of release:

There is the risk of the MUD manager itself being spied
on to determine what things are connected    to the network.  To address
this risk, MUD managers    may choose to make use of TLS proxies that
they trust that would aggregate other information.

> DETNET* but then later does?
Righto.

Thanks!

Eliot