Re: [Mud] DPP + MUD onboarding
Michael Richardson <mcr+ietf@sandelman.ca> Sun, 12 January 2020 00:33 UTC
Return-Path: <mcr+ietf@sandelman.ca>
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 335BA12004D for <mud@ietfa.amsl.com>; Sat, 11 Jan 2020 16:33:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 B51URGkDh0LV for <mud@ietfa.amsl.com>; Sat, 11 Jan 2020 16:33:32 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C46812001A for <mud@ietf.org>; Sat, 11 Jan 2020 16:33:32 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C5A603897F; Sat, 11 Jan 2020 19:33:07 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6FE7C431; Sat, 11 Jan 2020 19:33:31 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "M. Ranganathan" <mranga@gmail.com>
cc: mud@ietf.org
In-Reply-To: <CAHiu4JOYnGQ0e8K3R2AOQResNvpf66mGQWA=bgTOF2TAE7LHRA@mail.gmail.com>
References: <CAHiu4JOYnGQ0e8K3R2AOQResNvpf66mGQWA=bgTOF2TAE7LHRA@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Sat, 11 Jan 2020 19:33:31 -0500
Message-ID: <16563.1578789211@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/mqFO8uRg9VwM-tnYRE2jb86psp8>
Subject: Re: [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: Sun, 12 Jan 2020 00:33:34 -0000
M. Ranganathan <mranga@gmail.com> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
- [Mud] DPP + MUD onboarding M. Ranganathan
- Re: [Mud] DPP + MUD onboarding M. Ranganathan
- Re: [Mud] DPP + MUD onboarding Michael Richardson