Re: [Mud] MUD server discovery?

["M. Ranganathan" <[e-mail]>]

On Wed, Jan 15, 2020 at 11:31 AM M. Ranganathan <[e-mail]> wrote:
>
> On Tue, Jan 14, 2020 at 4:52 PM Michael Richardson <[e-mail]> wrote:
> >
> >
> > M. Ranganathan <[e-mail]> wrote:
> >     > 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.
>
> 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.
>
> >
> >     > 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.
> >
> > 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.
> >
>
>
> 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?


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.


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



-- 
M. Ranganathan