Subject: [Mud] DPP + MUD onboarding

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 10 Jan 2020 14:14:18 -0500

I am tinkering with ideas on onboarding devices using DPP and device
certificates.

In DPP a trusted configurator onboards a device.  I added (prototyped)
piggy backing device certificates to DPP config requests so the device
transmits its full device certificate (not just raw public key) as
part of the DPP config request. This certificate is verified by the
configurator which is a trusted application assumed to have the CA
certifcate and can be assumed to reside on the same network  as the
MUD-enabled device.( This certificate transmission is not part of the
DPP spec but I am hoping somebody picks up on it.)

The question is how to transmit the MUD URLin a non-spoofable way
given that the configurator is trusted, has possession of the public
key of the device and has already onboarded the device. I want to
avoid defining new API for the MUD controller.

Does the following make sense?

- Configurator broadcasts the public key and MAC address of the device
being onboarded (which is part of the DPP onboarding URL) on the local
network using a reserved port.
- MUD server picks up this information.
- MUD-enabled device sends *signed* MUD URL as part of the DHCP
request (using options 161).
- MUD server verifies signature and installs rules / blocks device if
signature fails.

Thank you for reading.

Thoughts?

Best regards and best wishes for 2020.

Ranga
-- 
M. Ranganathan

---

From: "M. Ranganathan" <[email-masked]>
Date: Fri, 10 Jan 2020 14:59:02 -0500

A few holes .. excuse the spam I need to think this through again.

--
M. Ranganathan

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Jan 2020 19:33:31 -0500

M. Ranganathan <[email-masked]> wrote:
    > The question is how to transmit the MUD URLin a non-spoofable way given
    > that the configurator is trusted, has possession of the public key of
    > the device and has already onboarded the device. I want to avoid
    > defining new API for the MUD controller.

I am not that concerned about spoofing of the MUD URL in this process.

I think that a place where we need an Operational Security Considerations
document is in how MUD URLs are updated.  The DHCP mechanism in particular,
is easily spoofable, and quite reasonable for MALWARE in the device to change
it's URL.

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