Re: [OPSAWG] [Mud] Declaring something to be a controller in MUD

On Wed, Jun 26, 2019 at 6:56 AM Eliot Lear <lear@cisco.com> wrote:

>
>
> > On 25 Jun 2019, at 21:52, Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
> >
> > Signed PGP part
> >
> > Eliot Lear <lear@cisco.com> wrote:
> >> A few of us are just trying to put out an initial draft that addresses
> >> one gap in MUD (there are several).
> >
> >> In a MUD file one can say that one
> >> wants to access a controller in two ways: either "my-controller”
> >> meaning a controller that services devices of a particular MUD URL or a
> >> “controller” class that services devices based on a particular class
> >> name of controller.
> >
> > I think that we have two potential avenues for security attacks here:
> >  1) a device that claims to be a controller in order to gain access to
> >     devices.
> >  2) devices that claim to be belong to a controller in order to attack
> >     controllers.
> >
> > To my mind there are some different things we could do:
> >
> > 1) insist that to user the my-controller connections that the two devices
> >   have to be signed by the "same" entity.  ["same" could mean literal the
> >   same key, the same certificate Issuer/DN,  or something more complex]
> >
> > 2) we could have devices declare in an MUD extension the
> >   DN/certificate/entity which must sign their controller device.
>

controller or my-controller could refer to an application (not necessarily
another device). However, the approach you are suggesting could apply to an
application as well.

>
> > 3) (2) above, but with some level of indirection through some URL.
>
>
> I could see these as options.
>
> >
> >> In either case, right now the administrator has to manually know and
> >> populate information, to say - some device 1.2.3.4 is a controller,
> >> either for MUD URL https://example.com/mud <https://example.com/mud> or
> >> a class http://example.com/mudclass1 <http://example.com/mudclass1>.
> >> That can be laborious.  To assist, we are examining ways to have a
> >> controller declare itself as a candidate controller.  That at least
> >> provides a hint to the administrator that this particular device is
> >> capable of serving in a particular role.
> >
> > I think that anything that requires administrator activity to be a fail
> for
> > residential use.  It's too complex.
>
> There will ALWAYS be a need for an administrator in the enterprise case.
> But maybe with the options above we can ease the consumer burden over
> time.  In the consumer case, you might want an app for initial device
> admission control anyway, no?  Can we not rely on that interaction as an
> approval step in this instance?
>
> >
> >> To make that declaration, the device must- Form the declaration; Find
> >> the MUD manager; and Send it.
> >
> >> Finding the MUD manager depends on one question: Was the device built
> >> to be a controller or is it a general purpose device that has an app
> >> that is intended to be a controller?
> >
> >> If the device was built to be a controller, we can simply cram the
> >> declaration into that devices own MUD file as an extension.  If the
> >> device is a general purpose computer, things get a bit more
> >> interesting.
>

More precisely if the application that wants to declare itself to be a
controller is running on a general purpose controller then things could
become interesting.

>
> > Yes... but I think that we have to solve the multi-purpose computer MUD
> > anyway.  The intelligent speakers (Echo,Home,Mycroft,etc.) need to gain
> new
> > MUD definitions as they gain "skills", and I think that we can treat a
> > smartphone in a similar way.
>

It's a chicken and egg problem but I think we need to see some further
adoption before throwing such complications into the mix.

>
> > This might be a place where IPv6 wins, if we can split off each skill
> into a
> > new provisioning domain, giving it a new IPv6 IID.  I was thinking that
> maybe
> > we can associate the private key that signed the MUD file to the IID via
> > something like SEND/CGA, but I'm not sure how many private keys we have
> > (one for the app developer, or one per app installed on each device).
>
>
> >
> >> In this case we have two choices:
> >
> >> Either create a MUD file that points somewhere internally - this
> >> doesn’t seem very plug and play.  Make the declaration directly to the
> >> MUD manager.
> >
> >> I’m going to focus on the latter for the moment.  It is easy enough to
> >> create a RESTful interface for this purpose, but it requires a
> >> mechanism to discovered the MUD manager, which up until now has been an
> >> internal part of the network infrastructure.
>
>
> >> Let me call this out plainly: letting the app itself directly call the
> >> MUD manager requires that the MUD manager itself become exposed to the
> >> user infrastructure, which is a change.
> >
> > Agreed.
> > And that the MUD manager have some reason to trust the device is not
> p0wned,
> > and sending a bogus MUD file up.   A certificate chain back to the
> > manufacturer is not enough, it has to be signed by a key that an attacker
> > can't get access to.  So that requires attested keys if they are
> "local", or
> > for the signature to be done elsewhere.
> >
> >> One possibility to address this is to incorporate the new RESTful
> >> endpoint into an ANIMA BRSKI join registrar, which may already be
> >> exposed.  But that requires that ANIMA BRSKI be in play, which it may
> >> not.
>

I think the simplest approach would be to define a REST interface to the
mud controller. This can be invoked by the join registrar (in case brski is
being used) so that it is not directly exposed. When a controller (which
could be an application) is admitted to the network, the join registrar
signals the MUD manager.  Thus the MUD manager does not need exposure in
case brski is being used.

In case brski is not being used, exposure (or limited exposure) may not be
avoidable.

How to discover the MUD manager (i.e. where it is running the API server)
in case brski is not being used? Not clear, but won't simple direct
configuration do the trick?  Alternatively there are many discovery
protocols (some better than others).

 So long as the application declaring itself to be the controller can be
trusted, I don't see a big problem with exposing a RESTful API. Yes you now
have an API that can be invoked by anyone who can access the MUD manager.
How do you authenticate the invoker of this API? Again - many answers
possible. A simple one -- it must present a trusted  certificate signed by
a trusted authority (verified using a certificate chain and yes key
exposure is a known risk but isn't that always the case for public key
encryption?). There application itself must be trustworthy but that can be
verified by checking its code signature manually or automatically while
installing it. So while not perfect I think it is a reasonable solution.

Just my 2c.

> >
> > It is, however, a really good idea for the case where it is in play.
> >
> >> My thinking is that we do this work in two stages.  First handle the
> >> easy case, which is the MUD file extension, and then figure out how to
> >> do the app version of this.
> >
> >> Thoughts?
> >
> > yes.
> >
>
> Was that “yes” to the two stage approach?
>
> Eliot
>
> > --
> > Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
> > -= IPv6 IoT consulting =-
> >
> >
> >
> >
> >
>
> --
> Mud mailing list
> Mud@ietf.org
> https://www.ietf.org/mailman/listinfo/mud
>

-- 
M. Ranganathan