Subject: [Mud] MUD server discovery?

From: "M. Ranganathan" <[email-masked]>
Date: Tue, 14 Jan 2020 15:03:52 -0500

There are a couple of situations I can think of where a  trusted agent
may need to communicate with a MUD server:

1. Controller Application: A Controller application may need to "tell"
the MUD server when it joins the network and that it is a controller
for a device. Perhaps it presents a signed certificate to assert its
identity to the MUD server.

2. Onboarding using a third party app (e.g. DPP). The onboarding
application may need to communicate the identity (Device certificate)
to the MUD server.

Is there a use case for the MUD server address to be published so it
can be discovered by such applications?

If yes, then should there be a REST API for such use cases? Are there
better ways of doing this?

Thanks

Ranga

-- 
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Tue, 14 Jan 2020 16:52:45 -0500

> application may need to communicate the identity (Device certificate)

My opinion is that the this should be an extension in the CAPPORT API.
MUD controllers need the CAPPORT API to indicate if they have quarantined a
device.

--
]               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: "M. Ranganathan" <[email-masked]>
Date: Wed, 15 Jan 2020 11:31:35 -0500

>     > identity to the MUD server.

Not sure how this fits into the Captive portal model. What we need is
some way to assert the app identity to the MUD server so it can be
trusted to be a device controller. If the APP is trusted and bundled
with a private key and certificate then it should be relatively simple
using TLS handshake.

> MUD controllers need the CAPPORT API to indicate if they have quarantined a

The trusted onboarding application is assumed to have a connection to
the MUD server via the CAPPORT API (how?). The onboarding app sends
the device certificate to the MUD server via the CAPPORT API
extension. The device sends a signed MUD URL in the DHCP request
(until which time it is effectively quarantined from the local
network). The MUD server receives the signed MUD URL (sent via DHCP)
and verifies the signature using the device certificate that was
previously sent to it by the onboarding application.

How will unconstrained devices (e.g. a laptop) on the network fit into
this model?

-- 
M. Ranganathan

---

From: "M. Ranganathan" <[email-masked]>
Date: Wed, 15 Jan 2020 12:07:13 -0500

> How will unconstrained devices (e.g. a laptop) on the network fit into

On second thoughts, indeed the onboarding application could send the
MUD URL of the device to the MUD server. It would be part of the
device certificate. DHCP based mechanism would be redundant.

One could use RFC 7710 to transmit the captive portal URL. So yes this
scheme makes sense.

-- 
M. Ranganathan