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

From: Eliot Lear <[email-masked]>
Date: Mon, 24 Jun 2019 11:48:28 +0200

Hi everyone,

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.

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.

To make that declaration, the device must-
Form the declaration;
Find the MUD manager; and
Send it.

Forming the declaration is easy: we can make this a YANG grouping and then place it in various spots.

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.  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.

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.

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?

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Mon, 24 Jun 2019 12:02:21 -0400

Hi Eliot,

On Mon, Jun 24, 2019 at 5:48 AM Eliot Lear <[email-masked]> wrote:

> Hi everyone,
>
> 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.
>
> 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 or a class
> 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.
>
>    - Form the declaration;
>    - Find the MUD manager; and
>    - Send it.
>
>
>    - 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.  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.
>

Regardless of whether the app directly calls the MUD manager or the Join
registrar calls the MUD manager, an interface to it would need to be
defined so that the MUD manager can be notified.

A RESTful interface should work fine. Of course the RESTful API should be
secured and based on certificates/HTTPs but that problem has been solved so
does not need to be re-defined here. Of greater concern is that it is
exposed outside the NW infrastructure. However, it does not HAVE to be
exposed -- the same interface can work in either case (i.e. the Join
registrar can use it or the controller  application can use it, with the
recommendation that it SHOULD not be exposed).

As you rightly point out, discovery protocols are dime a dozen so pick a
simple one. Can DNS (SRV record) be defined/used to locate the MUD
manager?  Perhaps it can be sent back in the DHCP response in case the
service needs to be exposed to the application (just thinking out loud).

> 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.
>
> 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.
>

Sounds good.

Regards, Ranga

-- 
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Jun 2019 15:52:26 -0400

Eliot Lear <[email-masked]> 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.

3) (2) above, but with some level of indirection through some URL.

    > 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.

    > 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?

    > declaration into that devices own MUD file as an extension.  If the
    > device is a general purpose computer, things get a bit more
    > 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.

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.

    > 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.

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.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Jun 2019 12:56:10 +0200

> On 25 Jun 2019, at 21:52, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

I could see these as options.

> 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?

>> do the app version of this.

Was that “yes” to the two stage approach?

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Jun 2019 13:15:41 +0200

> 3) (2) above, but with some level of indirection through some URL.

Another thought here:

We could provide a level of dereference for authorized controllers in the device’s MUD file, in the form of a URL list that would look something like:

{  [
   “controller” : “controller-name"
   “mud-urls” : [ some mud urls of valid controllers here ]
   “include” : “https://levelofindirection.example.com” that points to a file that contains a JSON serialization of this grouping
}

Whether you trust that mud-url without a cert is up to you.

Eliot

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 26 Jun 2019 10:26:53 -0400

> >   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.

> 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?
>
> >

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.

> > 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.

> >> exposed.  But that requires that ANIMA BRSKI be in play, which it may

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.

> Mud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mud
>

-- 
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Jun 2019 11:34:35 -0400

> 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?

I think we'd all like to have a generic app (with an RFC standard API) that
can onboard any device and can do admission control for any controller.
I think this is what you are saying as well.

    > Was that “yes” to the two stage approach?

"Yes"   :-)

    > We could provide a level of dereference for authorized controllers in
    > the device’s MUD file, in the form of a URL list that would look
    > something like:

    > “include” : “https://levelofindirection.example.com” that points to a file that contains a JSON serialization of this grouping

yes, this is exactly what I was thinking about.

Would "mud-urls" / "include" be mutually exclusive?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Jun 2019 17:43:00 +0200

> On 26 Jun 2019, at 17:34, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 

Yes, but I was saying a bit more.  Do you expect to fully automate the inclusion of a controller into a controller class in the home?  How do you envision the full flow looking like?

>> Was that “yes” to the two stage approach?

Okidoke.
> Would "mud-urls" / "include" be mutually exclusive?

I don’t see why it would have to be.  But now let’s back up, just to make sure we’re not digging too deep a hole for the application case that Ranga wants to get to.  If the MUD protected device is declaring MUD URLs for MUD controllers and that is what all of this would boil down to, then the app case is really a completely separate mechanism, because apps don’t have MUD-URLs.

If we do a two-stage, then we need a completely separate draft for apps anyway, but I was hoping for some commonality.

Eliot

---

From: Michael Richardson <[email-masked]>
Date: Wed, 26 Jun 2019 17:26:26 -0400

> Yes, but I was saying a bit more.  Do you expect to fully automate the
    > inclusion of a controller into a controller class in the home?  How do
    > you envision the full flow looking like?

I expect to fully automate the inclusion of a controller into that class,
yes.   I'd like to automate the device into the class too.

Perhaps your point is that since the controller has to onboard (at the
layer-7) the device in anyway: can we leverage that?

    > I don’t see why it would have to be.  But now let’s back up, just to
    > make sure we’re not digging too deep a hole for the application case
    > that Ranga wants to get to.  If the MUD protected device is declaring
    > MUD URLs for MUD controllers and that is what all of this would boil
    > down to, then the app case is really a completely separate mechanism,
    > because apps don’t have MUD-URLs.

    > If we do a two-stage, then we need a completely separate draft for apps
    > anyway, but I was hoping for some commonality.

Hmm.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 26 Jun 2019 23:30:24 +0200

> On 26 Jun 2019, at 23:26, Michael Richardson <[email-masked]> wrote:
> 
> 

For devices that are designed as controllers, yes.

>> anyway, but I was hoping for some commonality.

Indeed.  But let’s not get wrapped around the axle here.  I’ll try and have something out for the controller case, and then let’s talk about the other in Montreal.  Ok?

Eliot