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

[Eliot Lear <[e-mail]>]

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.  


On 17.04.18 17:31, Benjamin Kaduk wrote:
> 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.

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.


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

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.

> 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 see my response in that context.

>
> Please consider using the BCP 14/RFC8174 boilerplate.

I propose to make that change.

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

I propose to trim this to:

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

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

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.

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

Would the following be clearer?

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

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

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.


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

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.


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

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


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

I believe this text is about to change.
>
> % what it is, thus gaining additional network access.  There are
>
> s/thus/potentially/
> And maybe clarify ", based on the (false) MUD that is claimed"?

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.


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

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

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

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

Will try with small edits.

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

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

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

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.

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

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

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.

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

Thanks!

Eliot