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

[Eliot Lear <[e-mail]>]

Hi Eric,


On 15.04.18 13:32, Eric Rescorla wrote:
> Eric Rescorla 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:
> ----------------------------------------------------------------------
>
> Re-posted due to pilot error.
>
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3106
>
>
> The threat model for MUD doesn't seem clear, at least to me. It seems
> like there are at least two potential threat models:  - Telling the
> network how to configure access control to prevent the device from
> being compromised - Telling the network how to configure access
> control the limit the damage in case a device is compromised (e.g.,
> avoiding its use in a botnet).  Are both of these in scope?  If so, the
> latter seems to need substantially more analysis -- and perhaps
> mechanism -- because it seems relatively easy for the attacker to
> evade access control limits once it has replaced the firmware on the
> device (as noted below). In either case, the document needs to be
> clear about this, whether in the security considerations or elsewhere.

MUD is primarily intended to address the former, but provides some
benefit against the latter in some cases.  In particular, MUD is
intended to keep devices from getting infected in the first place.  As a
side-effect, if a device *is* broken into, it may be possible to either
prevent additional access, or otherwise detect the break-in based on a
change in profile.  I propose to state this more clearly in the
introduction, as follows:

NEW:

MUD primarily addresses threats to the device rather than the device as
a threat.  In some circumstances, however, MUD may offer some protection
in the latter case, depending on the MUD-URL is communicated, and how
devices and their communications are authenticated.

**
>
>
>
>
>
> IMPORTANT
>>      The certificate extension is described below.
>>
>>      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
> IMPORTANT: What does "disconnected" mean in this context? Does a
> reboot count? What if I am wireless? This is a critical question if
> MUD is intended as a post-compromise mechanism. Say that an attacker
> compromises the firmware for a device and then forces a reboot
> followed by a 2 hour pause before the wireless NIC is activated. Will
> this result in configuration removal? If so, MUD seems of limited use,
> because it can then make itself appear to be a new device with a new
> MUD configuration. (This is of course true in general in a wireless
> context if the firmware can change the client's L2 address).

Yes, configuration is intended to be removed when a device disconnects
or a session terminates.  This would be considered normal garbage
collection.  But whether or not you can simply replace the firmware and
gain the same access will depend on how the MUD-URL is learned.  If it
is in a manufacturer certificate, for instance, that's not something an
attacker will easily replace.  If the assertion is coming via LLDP, or
DHCP, then one has to apply the mitigations discussed in the security
considerations section (and they are numerous).


>
>
>>        https://example.com/lightbulbs/colour/v1
>>
>>      The MUD URL identifies a Thing with a specificity according to the
>>      manufacturer's wishes.  It could include a brand name, model number,
>>      or something more specific.  It also could provide a means to
>>      indicate what version the product is.
> IMPORTANT: Are you just using "identify" loosely here? I see how it
> can be *based* on those characteristics, but absent a schema it
> doesn't seem like the MUD controller can infer any of those
> characteristics from the URL.

This is a bit of an artifact from some changes in earlier versions,
which did indeed have a schema.  I propose to replace that paragraph as
follows:

A manufacturer may construct a MUD URL in any way, so long as it makes
use of the "https" schema.

 
>
>>                    -in mudfile -binary -outform DER - \
>>                    -certfile intermediatecert -out mudfile.p7s
>>
>>      Note: A MUD file may need to be re-signed if the signature expires.
>>
>>   12.2.  Verifying a MUD file signature
> IMPORTANT: This seem underspecified. Is the intention that these
> certificates will be rooted in the WebPKI? Something else? I realize
> that IETF tends to be kind of vague about where trust anchors come
> from, but at the end of the day its hard to see how to implement this
> interoperably without some more guidance.

Indeed.  I've proposed some additional text to Robert in his genart
review along the following lines:

NEW:

>    It is expected that the Key Usage extension would contain "Digital
>    Signature" and that the extended key usage would include either "code
>    signing" or "email protection".  What is important is simply that the
>    verification step match the purpose of the signing certificate to its
>    use.  It is not expected that the normal Web PKI will be used.  For
>    one thing, typically key usage does not allow signatures.

I would expect future versions of MUD to refine this, as we're just
getting started.

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
>>   Abstract
>>
>>      This memo specifies a component-based architecture for manufacturer
>>      usage descriptions (MUD).  The goal of MUD is to provide a means for
>>      Things to signal to the network what sort of access and network
> I realize that "Things" has become a marketing term, but it's opaque
> and unnecessary here. "elements" would be the conventional term.

How about "end devices"?  That makes it clear in the abstract.  I don't
propose to do a global substitute, because we scope the term well in the
introduction, as you note directly below.

>
>
>>      it continues to make sense for general purpose computing devices
>>      today, including laptops, smart phones, and tablets.
>>
>>      [RFC7452] discusses design patterns for, and poses questions about,
>>      smart objects.  Let us then posit a group of objects that are
>>      specifically not general purpose computers.  These devices, which
> I don't think this makes sense. These devices usually *are* general
> purpose computers (turing complete, etc.)

That these objects might happen to use a general purpose CPU or
operations system doesn't in and of itself make them general purpose
devices.  As a complete SKU they are sold with a single or small number
of uses in mind.  That is what is posited.  Is there a way to make that
clearer?


>
>
>>      specifically not general purpose computers.  These devices, which
>>      this memo refers to as Things, have a specific purpose.  By
>>      definition, therefore, all other uses are not intended.  The
>>      combination of these two statements can be restated as a manufacturer
>>      usage description (MUD) that can be applied at various points within
>>      a network.
> I would make the point here that the purpose of the MUD is to describe
> the communications pattern. You only really get that by the statement
> in S 1.1 that the communication pattern of other devices is too
> complicated to profile.

I think this statement is predicated on your previous comment, and would
prefer not to change text at this time.

>
>
>>      can say about that light bulb, then, is that all other network access
>>      is unwanted.  It will not contact a news service, nor speak to the
>>      refrigerator, and it has no need of a printer or other devices.  It
>>      has no social networking friends.  Therefore, an access list applied
>>      to it that states that it will only connect to the single rendezvous
>>      service will not impede the light bulb in performing its function,
> This *might* be true, but imagine that I wanted to control my light
> bulbs over Tor and then I would want it to act as a Tor hidden
> service.

I would be happy to add a statement that MUD works best where both
endpoints can be identified in some fashion.

>
>
>>      a public key.  In these cases, manufacturers may be able to map those
>>      identifiers to particular MUD URLs (or even the files themselves).
>>      Similarly, there may be alternative resolution mechanisms available
>>      for situations where Internet connectivity is limited or does not
>>      exist.  Such mechanisms are not described in this memo, but are
>>      possible.  Implementors should allow for this sort of flexibility of
> Do you mean SHOULD?

No I didn't.  While I don't feel that strongly,  I do believe in the
advice we are giving here, it is not required for interoperability or
security, and so I tend to shy away from normative language in such
cases.  To avoid confusion, how about: “Implementors are encouraged to
allow...”, and as a bonus I propose to unscramble the rest of that
sentence which reads a little funny, editorially.

>
>
>>   1.6.  Processing of the MUD URL
>>
>>      MUD controllers that are able to do so SHOULD retrieve MUD URLs and
>>      signature files as per [RFC7230], using the GET method [RFC7231].
>>      They MUST validate the certificate using the rules in [RFC2618],
>>      Section 3.1.
> ITYM 2818.

Yes I do, thank you.

>
>
>>      The files that are retrieved are intended to be closely aligned to
>>      existing network architectures so that they are easy to deploy.  We
>>      make use of YANG [RFC7950] because of the time and effort spent to
>>      develop accurate and adequate models for use by network devices.
>>      JSON is used as a serialization for compactness and readability,
> Nit: "serialization format"
>
>
Ok by me.

>>          domain reputation service, and it may test any hosts within the
>>          file against those reputation services, as it deems fit.
>>
>>      4.  The MUD controller may query the administrator for permission to
>>          add the Thing and associated policy.  If the Thing is known or
>>          the Thing type is known, it may skip this step.
> What is a "Thing type"?

Propose: “or the administrator has established a policy for things
matching this URL” (noting security considerations below).

>
>
>>   2.1.  The IETF-MUD YANG Module
>>
>>      This module is structured into three parts:
>>
>>      o  The first container "mud" holds information that is relevant to
> This appears to be the only container.

Propose s/container/component/ as the next two state.
>
>
>>      o  The third component augments the tcp-acl container of the ACL
>>         model to add the ability to match on the direction of initiation
>>         of a TCP connection.
>>
>>      A valid MUD file will contain two root objects, a "mud" container and
> MUST contain
I could envision a manufacturer not wanting to specify access controls,
but still wanting to indicate perhaps the meta-information.  I can
clarify this as follows:

A valid MUD file MUST contain a "mud" container and MAY contain an
optional access-lists container that will be present whenever access
controls are to be requested.


>
>
>>      extension example can be found in Appendix C.
>>
>>   3.9.  manufacturer
>>
>>      This node consists of a hostname that would be matched against the
>>      authority component of another Thing's MUD URL.  In its simplest form
> In what encoding?

This is stated in the YANG.
>
>
>>      the expression as is appropriate in their deployments.
>>
>>   3.13.  controller
>>
>>      This URI specifies a value that a controller will register with the
>>      MUD controller.  The node then is expanded to the set of hosts that
> The use of "controller" and "MUD controller" is very unfortunate
> terminology. Could you perhaps rename one of these? Given that
> "controller" is encoded in the YANG model, perhaps "MUD agent"?


Ok.  You're the last person who's going to complain about this ;-).
"Agent" is probably isn't what we're looking for because it is generally
used a term for a process that runs on a managED device.  How about MUD
manager?
>
>
>>      corresponding direction.  [RFC6092] specifies IPv6 guidance best
>>      practices.  While that document is scoped specifically to IPv6, its
>>      contents are applicable for IPv4 as well.  When this flag is set, and
>>      the system has no reason to believe a flow has been initiated it MUST
>>      drop the packet.  This node may be implemented in its simplest form
>>      by looking at naked SYN bits, but may also be implemented through
> SYN seems over-specific here, as it doesn't apply to UDP-based
> protocols.

The mechanism is only appropriate for TCP and SYN is merely intended as
an example. Will make this more clear in the text.

>
>
>>       reserved = 1*( CHAR ) ; from [RFC5234]
>>
>>      The entire option MUST NOT exceed 255 octets.  If a space follows the
>>      MUD URL, a reserved string that will be defined in future
>>      specifications follows.  MUD controllers that do not understand this
>>      field MUST ignore it.
> This is a matter of taste I suppose, but why not just have two chunks
> in the option. The cost would be one byte in the non-extension case
> but then you would be able to handle extensions that brought the total
> length above 255.

This came as part of a late discussion with mnot and Adam, and it would
require a lot of recoding for one byte.  If you were to look in previous
versions you would have found this to be part of the URL, causing us
some issues with BCP 190.  We should have the discussion about BCP 190,
but want to move forward in the meantime without a big implementation
impact.

>
>
>>   9.2.  Server Behavior
>>
>>      A DHCP server may ignore these options or take action based on
>>      receipt of these options.  If a server successfully parses the option
>>      and the URL, it MUST return the option with length field set to zero
>>      and a corresponding null URL field as an acknowledgment.  Even in
> What this means here is "no URL field"? Generally, the use of "null"
> is confusing in the context of string processing because of C
> semantics.

This text is rewritten based on the GENART review.  The requirement for
an acknowledgment is proposed to be removed.  Please see the thread with
Robert for the text.
>
>
>>      Because MUD files contain information that may be used to configure
>>      network access lists, they are sensitive.  To insure that they have
>>      not been tampered with, it is important that they be signed.  We make
>>      use of DER-encoded Cryptographic Message Syntax (CMS) [RFC5652] for
>>      this purpose.
> It's very odd to be using CMS here when you are serializing in JSON.
> This is a decision for the WG, but why aren't you using JWS?

For our purposes we are talking about a file, and its format isn't
really at issue (which is good because it has changed in the life of
this document, and could change again at some point).  The file just
needs signing, and the goal was to integrate with commonly used and
available tool sets.  This having been said, I could easily envision
this evolving in future versions.

Eliot