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

[Eric Rescorla <[e-mail]>]

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)

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
>