Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-23.txt

From: [email-masked]
Date: Sat, 02 Jun 2018 06:36:54 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Operations and Management Area Working Group WG of the IETF.

        Title           : Manufacturer Usage Description Specification
        Authors         : Eliot Lear
                          Ralph Droms
                          Dan Romascanu
	Filename        : draft-ietf-opsawg-mud-23.txt
	Pages           : 61
	Date            : 2018-06-02

Abstract:
   This memo specifies a component-based architecture for manufacturer
   usage descriptions (MUD).  The goal of MUD is to provide a means for
   end devices to signal to the network what sort of access and network
   functionality they require to properly function.  The initial focus
   is on access control.  Later work can delve into other aspects.

   This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
   LLDP TLV, a URL, an X.509 certificate extension and a means to sign
   and verify the descriptions.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-opsawg-mud-23
https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-23

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Eliot Lear <[email-masked]>
Date: Sat, 2 Jun 2018 15:40:34 +0200

This update contains only the following changes:

  * A correction (signature -> certificate)
  * Slightly change language to make clear that the certificate subject
    must be the sameas the id-pe-mudsigner
  * Updated dates on the YANG files

At this point, I really hope we're done.  Eric, Ben?

And thanks all (including the Sec ADs) for improving the work.

Eliot

On 02.06.18 15:36, [email-masked] wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Jun 2018 10:40:46 -0500

Hi Eliot,

> At this point, I really hope we're done.  Eric, Ben?

I think we're basically done -- I have just one quibble which
hopefully is not problematic, and also noted a handful of editorial
things you can deal with at your leisure.  Thanks for going through
the multiple rounds of changes addressing our concerns -- the
document really is much better for it!

At the start of the Security Considerations, we say:

   Based on how a MUD URL is emitted, a Thing may be able to lie about
   what it is, thus gaining additional network access.  This happens
   when a device emits a MUD URL using DHCP or LLDP, and is either
   inappropriately admitted to a class such as "same-manufacturer" or
   given access to a device such as "my-controller", where such access
   would otherwise be disallowed.

To me, "[t]his happens when" indicates that the subsequent
enumeration is an exhaustive list.  I don't really think we've got
enough experience with this stuff to be able to make such a claim,
and the list should instead be treated as illustrative.  I think
that there was some text emailed around that did this nicely,
something like:

%   Based on how a MUD URL is emitted, a Thing may be able to lie about
%   what it is, thus gaining additional network access.  This can happen
%   in a number of ways when a device emits a MUD URL using DHCP or
%   LLDP, such as being inappropriately admitted to a class such as
%   "same-manufacturer", given access to a device such as
%   "my-controller", or being permitted access to an Internet resource,
%   where such access would otherwise be disallowed.

And, here's the editorial stuff.

Section 1.5

   o  A DHCP option[RFC2131],[RFC3315] that the DHCP client uses to
      inform the DHCP server.  The DHCP server may take further actions,
      such as act as the MUD manager or otherwise pass it along to the
      MUD manager.

nit: We lost the immediately previous "URL" that "it" referred to, so we
may want to specifically say "pass the MUD URL along".

Section 13.2

   Prior to processing the rest of 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.  The Key
   Usage Extension in the signing certificate MUST have the bit
   digitalSignature(0) set.

nit: do we need to go with "MUST be present and have the bit
digitalsignature(0) set"?

                            The subject of this certificate MUST be
   equal to that of the value of id-pe-mudsigner when that extension is
   present in the device certificate.  If these conditions are not met,
   or if it cannot validate the chain of trust to a known trust anchor,
   the MUD manager MUST cease processing the MUD file until an
   administrator has given approval.

nit-level as well, I guess: I might wordsmith this differently.

NEW:

   When the id-pe-mudsigner extension is present in a device's X.509
   certificate, the MUD signature file MUST have been generated by
   a certificate whose subject matches the contents of that
   id-pe-mudsigner extension.  If these conditions are not met,
   or if it cannot validate the chain of trust to a known trust anchor,
   the MUD manager MUST cease processing the MUD file until an
   administrator has given approval.

I might also consider adding something like the following (though
hopefully it would be obvious and thus not necessary to say):

   Before the signature has been validated, both the MUD file and
   the resource retrived from the "mud-signature" URL are unverified
   and should be treated as untrusted input.  In particular, MUD
   managers can impose a cap on the number of bytes they retrieve
   from a "mud-signature" URL, to avoid DoS attacks involving
   presenting a large (invalid) signature file or similar scenarios.

Section 16

   Implementations SHOULD be configurable to
   disallow additive access for devices using MUD-URLs that not emitted
   in a secure fashion such as in a certificate.

nit: "that are not emitted".

   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.  This will be relevant
   when it makes use of primitives such as "manufacturer" for the
   purpose of accessing Things of a particular type.

What is "it" that makes use of primitives such as "manufacturer"?

   [...] If the actual MUD file has changed, the MUD
   manager MAY check the WHOIS database to see if registration ownership
   of a domain has changed.

Do we need a reference for WHOIS?

Appendix C

   In this sample extension we augment the core MUD model to indicate
   whether the device implements DETNET.  If a device claims not to use
   NETNET, but then later attempts to do so, a notification or exception

That's also supposed to be 'D'ETNET, right?

-Benjamin

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 4 Jun 2018 12:57:44 -0500

On Mon, Jun 04, 2018 at 07:50:47PM +0200, Eliot Lear wrote:
> Ben,
> 
> Barring any objections to the below I will issue a new draft with edits
> tomorrow.  Now please see below.

Okay, thanks.  (I'm okay with leaving out the extra text about the
file+signature being untrusted input until the signature is
verifeid.)

-Benjamin

> On 04.06.18 17:40, Benjamin Kaduk wrote:
> > Hi Eliot,
> >
> I think that's fine.
> That is fine.
> Ok.
> I would rather leave this out for the very reasons you state.  The draft
> is already quite wordy.
> >
> > Section 16
> >
> Ok
> the MUD manager.
> I don't think so.  RFC Editor will sort if so.
> >
> > Appendix C
> >
> Indeed.  Thanks.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 4 Jun 2018 23:49:35 +0200

I've been told to resend this message due to a mailing list glitch. 
Please see below.

Subject: Re: [OPSAWG] I-D Action: draft-ietf-opsawg-mud-23.txt
From: Eliot Lear <[email-masked]>
To: Benjamin Kaduk <[email-masked]>
Cc: [email-masked], EKR <[email-masked]>
Date: Mon, 4 Jun 2018 19:50:47 +0200

Ben,

I think that's fine.

That is fine.

Ok.

Ok

the MUD manager.

Indeed.  Thanks.

Eliot