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