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

[Spencer Dawkins at IETF <[e-mail]>]

I haven't balloted yet, and this is EKR's ballot thread, but one point is
worth bringing up here ...

On Mon, Apr 16, 2018 at 7:25 AM, Eric Rescorla <[e-mail]> wrote:

> Hi Eliot,
>
> Thanks for continuing the conversation. My question is how this fits into
> the system as a whole.
>
> ISTM that there are two ways in which a MUD policy can affect the
> network's behavior:
>
> - Additive -- it lets the device do things it otherwise might not be
> permitted to do (e.g., accept incoming TCP connections)
> - Restrictive -- it stops the device from doing things that it otherwise
> would be permitted to do (e.g., make connections to IP addresses on non-443
> ports)
>

I've read previous versions of this draft and some of the mailing list
discussion, but not a lot. Having said that, I hadn't heard anyone express
the possibility of the additive case described here. The context I always
heard about, was roughly "we've gotta keep all the coke machines on campus
from doing anything except reporting that they need to be refilled", or
whatever variation of cameras, printers, or *mumble* have access to your
network for a specific reason, are running some arbitrary version of some
OS stack that included TCP or UDP capabilities, aren't being maintained
enough to be current on security patches, and aren't being managed, so are
ripe for attacks to create botnets.

Perhaps I need to get out more. Almost certainly. But ... the possibility
of additive policies is interesting, and new to me.

I'll be interested to watch this discussion. Eric, thanks for asking the
question.

Spencer

In the former case, it's very important not to be able to forge acceptable
> MUD policies, but in the latter case, an attacker can just not serve *any*
> MUD policy and be in a stronger position than they would be if they had a
> valid policy, Thus, it's only in the former (additive) case where forging a
> policy is useful to the attacker, and, in fact, it seems like accepting an
> unsigned MUD policy would be better than no policy. Given the ubiquity of
> non-MUD devices and the relatively limited capabilities that MUD seems to
> want to convey, it seems like the additive case isn't very useful.
>
> I should mention one use case that I did think of, where additive would be
> immediately useful: "This device is made by the same manufacturer as
> another device (and hence they can talk to each other). However, I note
> that MUD is actually not capable of securely conveying that, because
> there's no proof that the device in hand actually is made by the
> manufacturer, only that it possesses a public credential for some device
> made by that manufacturer. So, I'm actually left wondering how that feature
> is intended to work. I regret not catching this earlier, but perhaps you
> could explain?
>
> Thanks,
> -Ekr
>
>
> On Sun, Apr 15, 2018 at 11:27 PM, Eliot Lear <[e-mail]> wrote:
>
>> Hi Eric,
>>
>> Trimming.
>>
>> On 15.04.18 21:22, Eric Rescorla wrote:
>>
>>
>>
>>
>>
>>> 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).
>>>
>>
>> I'm not following you here. Say it's in a manufacturer certificate, what
>> stops me from getting my own certificate for Attacker LLC and then serving
>> a wide open policy? The mitigations don't really seem to do much to
>> counteract this.
>>
>>
>> I believe this point and one down below, where you write:
>>
>> This doesn't seem to address my concern, which is that there's no
>> realistic way of knowing
>> what trust anchors apply. If it's not WebPKI, then what?
>>
>> are related, and so I propose to address them together, and this text
>> could go into security considerations.  The *intent* is that mud managers
>> or their providers will keep a list of known trusted signers.  Examples are
>> likely to include certification bodies (we are aware of at least one that
>> is very interested), the MUD manager vendor themselves, and perhaps
>> others.  Because these are early days, I don't want to be too declarative,
>> but we can say this:
>>
>> NEW:
>>
>> ---
>> MUD managers and their administrators MUST NOT automatically trust a
>> manufacturer's certificate simply because it validates.  Rather, the
>> certificate MUST be signed by an entity that has previously established
>> trust for this explicit purpose.  In particular, the WebPKI alone is not
>> appropriate.
>> ---
>>
>>
>> That means that just because Joe Evil signed the darn thing doesn't mean
>> that we should believe it.  On the other hand, I might trust a security
>> company to vet this stuff.  Would this address your concern?  Also, I'll
>> correct the previous factual error.
>>
>> And again, I view this as early days.  The architecture is going to need
>> some time to mature and evolve.
>>
>>
>>
>>
>>
>>
>>> ----------------------------------------------------------------------
>>> 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.
>>>
>>
>> To be honest, I would do a search and replace, but I agree that theis
>> would resolve the ambiguity here.
>>
>>>
>>>      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?
>>>
>>
>> Perhaps "not intended to be used for general purpose computing tasks"
>>
>>
>> Ok.
>>
>>
>>>
>>>      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.
>>>
>>
>> Hmmm.... No, I don't think you're reading me right here. I'm just saying
>> that it would be useful upfront to say that MUD
>> is about saying "this is what communications pattern these devices are
>> expected to have"
>>
>>
>> Ok.  I think that's a good add, and propose to add a statement based on
>> your quoted text.
>>
>> Thanks again,
>>
>> Eliot
>>
>
>