[Mud] DPP + MUD onboarding

"M. Ranganathan" <mranga@gmail.com> Fri, 10 January 2020 19:14 UTC

Return-Path: <mranga@gmail.com>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F40391200B5 for <mud@ietfa.amsl.com>; Fri, 10 Jan 2020 11:14:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTfKy4pHe0pD for <mud@ietfa.amsl.com>; Fri, 10 Jan 2020 11:14:56 -0800 (PST)
Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110FA120019 for <mud@ietf.org>; Fri, 10 Jan 2020 11:14:56 -0800 (PST)
Received: by mail-il1-x12c.google.com with SMTP id t8so2641344iln.4 for <mud@ietf.org>; Fri, 10 Jan 2020 11:14:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+NITPUdTrI1SVn2g2JwT9bl0vGeBnxvhRhXmOpxqTU0=; b=egAatAU4Xxd+BGiQMH6JUjUS5N8cL15ub2exu57lhv5MrKGn0fa8iGIwgEE/b0Aas0 vWqKIj3ZJKHVOG3XEBeSQHMQiTBA0P5KG3JDTGyGtafyhNA4qQh0LtpiVhfXMwoI+vyQ 3o/KtwT8fDW1jd/tFA8ej4BVagzsi3sje1us5GE+dU5Ky+C6mo0gAidi+w2XUJ5Lv3Sx gymvoEEBxA+ktBbdl9KiCoDWO7CYK9asDJ0QnBiE2htG53zv6I6OhwMsNnMpjG13S5U4 DpxMIMpVEZm6gqwSbLTo/MYdsTmp9cVQ9G8+A2D2BCjPHR2Uv7yK7IgY+8RD+ITsjjHL eIGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+NITPUdTrI1SVn2g2JwT9bl0vGeBnxvhRhXmOpxqTU0=; b=iQkoJ+fZOHjxRzBV5R94oatwK5T/cy9awmTHH9nC/ArWHlIrTesIHG9vbkabfDxnaS ywYDyTUOAmgVeUxhSMh0HXBwsxFX9BogTArNrqbxEeVFTpE2fmhB6QkQqG4z5kTwacV9 63Z1KbjwUGC/kSRwINA6OHg7+wxbEZVTGM/Rf4y1Q2yAfaSKTdRmlavBW7HGtxJL+cQw LSThsL4dAcFejEFz4/1/8x5tFHYrYzpzunSgg1z/udm50nbAMnMlHWbdzSQqFxYtwOP5 ugt+yGKxcLPXbkIbGTBX9aHBz69C85nTgslTPV7/ERWrR9CfY3kNdQLA5z/jnL3VZreY rq2g==
X-Gm-Message-State: APjAAAUnjIVxHR4tE00MxXFg2dmAe6QU5rUQQt5dUsSCzGgOCGDXIYcU hn71iZiRSCp4zaeMxMarUQvMLvbQrDVKE9DPT/E2euwMg7YwKQ==
X-Google-Smtp-Source: APXvYqzGtYhNmjUlTUAW0DHANZ6lkw+Um/5m0K8WZ6JHuVtndAYSFQLv1xYLW4axwUpMF4amV7Zas1A0VSwpOMGAMmM=
X-Received: by 2002:a92:dcca:: with SMTP id b10mr4147907ilr.294.1578683694891; Fri, 10 Jan 2020 11:14:54 -0800 (PST)
MIME-Version: 1.0
From: "M. Ranganathan" <mranga@gmail.com>
Date: Fri, 10 Jan 2020 14:14:18 -0500
Message-ID: <CAHiu4JOYnGQ0e8K3R2AOQResNvpf66mGQWA=bgTOF2TAE7LHRA@mail.gmail.com>
To: mud@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/IdETwQTVCJR_gUXnGjiRSYRVCTE>
Subject: [Mud] DPP + MUD onboarding
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jan 2020 19:14:59 -0000

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