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

[Benjamin Kaduk <[e-mail]>]

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?