Re: [Madinas] identities for legitimate devices
Michael Richardson <mcr+ietf@sandelman.ca> Wed, 04 November 2020 16:54 UTC
Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: madinas@ietfa.amsl.com
Delivered-To: madinas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC7D43A1350 for <madinas@ietfa.amsl.com>; Wed, 4 Nov 2020 08:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jWSBgyMiEfW8 for <madinas@ietfa.amsl.com>; Wed, 4 Nov 2020 08:54:53 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EEB3A134C for <madinas@ietf.org>; Wed, 4 Nov 2020 08:54:52 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1CB7738A5E; Wed, 4 Nov 2020 11:54:54 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id p0y7rhHYeKHf; Wed, 4 Nov 2020 11:54:52 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E2ED538A5C; Wed, 4 Nov 2020 11:54:52 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 650EA5DF; Wed, 4 Nov 2020 11:54:49 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Qin Wu <bill.wu@huawei.com>, "madinas@ietf.org" <madinas@ietf.org>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAADB22346@dggeml511-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAADB22346@dggeml511-mbs.china.huawei.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.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-sha512"; protocol="application/pgp-signature"
Date: Wed, 04 Nov 2020 11:54:49 -0500
Message-ID: <14818.1604508889@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/madinas/lbKGpTmSRn_b6hV-DyLQ2PHoHNg>
Subject: Re: [Madinas] identities for legitimate devices
X-BeenThere: madinas@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: MAC Address Device Identification for Network and Application Services <madinas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/madinas>, <mailto:madinas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/madinas/>
List-Post: <mailto:madinas@ietf.org>
List-Help: <mailto:madinas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/madinas>, <mailto:madinas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Nov 2020 16:54:56 -0000
mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>> wrote: med> The slides you are referring to are not intended to articulate the med> overall problem space but to illustrate a use case where ** means to med> unambiguously and persistently identify devices within the home are med> required ** to protect the Internet but also to avoid collateral damage med> for subscribers hosting such compromised devices. Filtering at the med> network is suboptimal. The question then is: mcr> Reading the slides, I understood: mcr> "Doctor it hurts when I put my foot in the blender" mcr> me: "don't put your foot in the blender" med> ** how to reliably achieve this without mandating a given network setup med> and while minimizing subscriber involvement? ** med> Many ISPs offer apps to seek for an ACK from the subscribers whenever a med> new device connects to the home network. The identification is usually med> based on the MAC@. Notifications will be generated each time a new MAC@ med> is generated, which may be disturbing for the subscriber and may lead med> to deactivate the app or accept by default all devices. These med> considerations (and others) are not discussed in these slides because med> this is supposed to be handed in other use cases (device med> identification). mcr> Yes, it's is good that you agree with me that the real problem is not mcr> tracking malicious devices that change evade ACL by changing address, but mcr> rather positively identifying legitimate devices so that their MAC address mcr> changes can be transparently tracked. Qin Wu <bill.wu@huawei.com> wrote: qin> [Qin]: This reminds me to think the identity and locator concept, qin> whatever Mac address you changes, the identity of the device doesn't qin> change. If the device frequently changes MAC address, I am wondering qin> whether this device will be seen as attacking device. So the qin> question is when the device needs to change MAC? Changing MAC when qin> the device is moving or change MAC every 20 minutes, My impression qin> in the home network, even the device have the capability to change qin> MAC, if the device is still attaching to the same WLAN, MAC address qin> should stay same. Only when you change from one AP to another one, qin> MAC address change makes sense. Still, one MAC per one WLAN AP. You are exactly right: the identity doesn't change. WiFi devices will re-authenticate when they change their MAC address. With WPA-PSK using a single key (a la "coffee shop" internet), then nobody can tell which device if which. WPA-PSK can be deployed with a PSK-per-device, but configuring those additional keys is difficult because we lack interfaces into home routers. (The device wouldn't configure the keys, the home owner would, using their phone) A number of IETF irregulars wrote a document for the RIPE IoT WG: https://www.ripe.net/ripe/mail/archives/iot-wg/2020-October/000537.html WPA-Enterprise, using client certificates is also certainly possible, but it requires an onboarding protocol (such BRSKI) so issue an appropriate LDevID. But, the key (pun intended), in my opinion, is to change the device identity from being a MAC address to being a key. -- Michael Richardson <mcr+IETF@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
- [Madinas] identities for legitimate devices Qin Wu
- Re: [Madinas] identities for legitimate devices Michael Richardson
- Re: [Madinas] identities for legitimate devices Stephen Farrell
- Re: [Madinas] identities for legitimate devices mohamed.boucadair
- Re: [Madinas] identities for legitimate devices Michael Richardson
- Re: [Madinas] identities for legitimate devices Stephen Farrell
- Re: [Madinas] identities for legitimate devices Michael Richardson
- Re: [Madinas] identities for legitimate devices Juan Carlos Zuniga
- Re: [Madinas] identities for legitimate devices Stephen Farrell
- Re: [Madinas] identities for legitimate devices Juan Carlos Zuniga