Re: [Captive-portals] [homenet] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

Christian Huitema <huitema@huitema.net> Tue, 29 September 2020 19:04 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887A83A1109 for <captive-portals@ietfa.amsl.com>; Tue, 29 Sep 2020 12:04:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Level:
X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, 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 4QH2Ca2qGFSo for <captive-portals@ietfa.amsl.com>; Tue, 29 Sep 2020 12:04:21 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62293A1165 for <captive-portals@ietf.org>; Tue, 29 Sep 2020 12:04:08 -0700 (PDT)
Received: from xse123.mail2web.com ([66.113.196.123] helo=xse.mail2web.com) by mx168.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kNKv0-0013Db-1I for captive-portals@ietf.org; Tue, 29 Sep 2020 21:04:07 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4C180v27YGz1kvm for <captive-portals@ietf.org>; Tue, 29 Sep 2020 12:03:11 -0700 (PDT)
Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1kNKu7-0005px-50 for captive-portals@ietf.org; Tue, 29 Sep 2020 12:03:11 -0700
Received: (qmail 18891 invoked from network); 29 Sep 2020 19:03:10 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.238]) (envelope-sender <huitema@huitema.net>) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for <int-area@ietf.org>; 29 Sep 2020 19:03:10 -0000
To: Brian Dickson <brian.peter.dickson@gmail.com>, Michael Richardson <mcr@sandelman.ca>
Cc: Martin Thomson <mt@lowentropy.net>, "Lee, Yiu" <Yiu_Lee@comcast.com>, "captive-portals@ietf.org" <captive-portals@ietf.org>, "homenet@ietf.org" <homenet@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
References: <20200922201317.097C3389D4@tuna.sandelman.ca> <15660.1600807202@localhost> <902400f2-9172-9581-25ab-59ad08e67bee@cs.tcd.ie> <D81695FF-973F-472D-BC0A-9B0F57278B21@comcast.com> <ca575a6b-987e-d998-2713-91e45190f5ea@cs.tcd.ie> <0A436777-D9CE-4A4C-BE45-C8C2CAB9FBF6@comcast.com> <29901277-6da1-46fc-b244-ca289005841d@www.fastmail.com> <af0451b1-8eae-4714-849f-d6e384dda075@huitema.net> <19117.1601400596@localhost> <CAH1iCip7UBe+FR-Cz+sP6SdS11NUQC9gV_s=99yO0tjcvCcX6A@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Message-ID: <f6146747-0c60-072d-7d2e-6ecc945989e4@huitema.net>
Date: Tue, 29 Sep 2020 12:03:09 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <CAH1iCip7UBe+FR-Cz+sP6SdS11NUQC9gV_s=99yO0tjcvCcX6A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------79D2D7C80BA7374FFADDBDDD"
Content-Language: en-US
X-Originating-IP: 66.113.196.123
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.123/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.123/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Z1apovzGPsYhEeBL1aoZmqpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGD9NKqG/fmMP3yul5JhQOTK5aP BLMYd83MuhpCxTgKDz2bFxYJnRQK0gEcuviCIvd+WmuNA8WTybi1JN85FSnfKfyrBBzCRb2oe4JC Nd2sOpeuAZSFpNKmPIWDmHyh6XPSNIO/emvhlwlcA0NK2OuLB5FVgpT1b21uZVckGp0ccOZsRgF0 wcvPx91nK3EE+9D+MzCOHPDavhUA6yQVlDyA0a5g95eyZBAGnSXepG9WpP+KeHGV1+GDbwcApRSC c9xvb9lLcno8+LMWQktE6OGVK1Cyj1RWE2fDFBwInXy3MWouNMfKNR0BJhgbBK7NDOmpQy17Ychx ni5a2VYVYiL6p0zFIS4eFFedtqTPxkQeRTOiomu5RawBHfscrcVNTNDmdXkcCRtBI89Ppivzm8CF 7foTcdRszDvfFFq71TR2vNS105zjbKsiPvrvVDH+VNpRclzFnL9mZb0jWXJhjtxPMCM76Y/SM8ga XNdGScJz4OUkZ/wD/TMMbgsGnEqUZSxCnVxASo9dHmMdBMpGA/F0Ea3nkY07HqD3TNAtU1GuOwZW TcUVh8zbZfcKACLJrQoefqrtsPZ1hcyhjIkCZT/HnPGISNE/hO231c8s4dw5L8oMhGfTGKeYohdq JlHBQlshrlP9M6a63suU95GjnImx4UvcvbjW7NQ6sDu9dQojc3NIYDh60e9w4/wmpOTrpF/vPUIV F2OW2qEaVbUHcFpJPHLYM3A6BXfvel8OEFDbU53AkkgbH6S0I3lUiwbrW8csqFRGTooeK78BeuwV S1l7cjVjn0ct4reaW46myUBetVNddn8KKfQU2n19Ayh48sIRmzvvJzEWC/ZHpFS+HYcdOon5y/vc IKE4+MoDT8NV3zdM7Ahub8TBeVhtYGLHDQnyEj+FTyUVIz4E3+N7ec+ThjDIZMcgCg0Vf6NxbsMa Z0R5yhTi9qm8IZJSHpFdJ5bb
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/rT60KBm0GCSVHUUm5bwcHjlNkvk>
Subject: Re: [Captive-portals] [homenet] [Int-area] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2020 19:04:24 -0000

On 9/29/2020 10:59 AM, Brian Dickson wrote:
>
> On Tue, Sep 29, 2020 at 10:30 AM Michael Richardson <mcr@sandelman.ca
> <mailto:mcr@sandelman.ca>> wrote:
>
>     Christian Huitema <huitema@huitema.net
>     <mailto:huitema@huitema.net>> wrote:
>         > Martin is making an important point here. There are a number
>     of privacy
>         > enhancing technologies deployed at different layers: MAC address
>         > randomization at L2, Privacy addresses at L3, various forms of
>         > encryption and compartments at L4 and above. Each of these
>     technologies
>         > is useful by itself, but they can easily be defeated by
>     deployment
>         > mistakes. For example:
>
>     You are spot on.
>     But, even your four points muddle things.
>

There were meant as examples, so people quickly recognize that we do
have a problem. It is very true that different classes of attackers have
different views of the system, and that some defenses deter some
attackers while being bypassed by others. But I was writing a short
email, not a textbook...


>
>     We need some diagrams that we can all agree upon, and we need to
>     name the
>     different observers.
>
>     Each thing defends against different kinds of observers, and not all
>     observers can see all things.
>     Some observers may collaborate (I invoke, the WWII French
>     resistance emotion
>     for this term...)
>     Some observers may have strong reasons not to.
>
>         > 1) Using the same IP address with different MAC addresses
>     negates a lot
>         > of the benefits of randomized MAC addresses,
>
>     This assumes that a single observer can observe both at the same time.
>     WEP++ leaves MAC addresses visible, but encrypts the rest of L3
>     content.
>
>
> Any host/interface that uses ARP (not sure whether any flavor of WiFi
> does, or if so which flavors), exposes the L3/L2 mapping. 
> So, wired IPv4 for certain (except in very locked-down enterprise
> settings with static MAC addresses, perhaps) leaks this information to
> every host on the same broadcast domain (same subnet and possibly
> additional subnets on the same LAN/VLAN).

Yes. Michael has a point, though. Consider enterprise Wi-Fi network,
typically access controlled using 802.1x. Then, consider an attacker who
want to track which department of the enterprise is active on what
project. The attacker have not penetrated the network, maybe because
they don't want risk getting caught doing blatantly illegal stuff. They
are merely listening to the radio waves. They can see the MAC addresses,
which are outside the Wi-Fi encryption envelope, but they cannot see the
IP headers, which are encrypted. In the absence of MAC address
randomization, these MAC addresses still provide them with interesting
information, such as the graph of who connects to whom, or maybe what
type of hardware is being used. If a device is used inside and outside
the enterprise, the attackers could monitor outside activity and
identify the device owner, and then add that to the communication graph.
MAC address randomization will be a big deterrent for this class of
attackers.


>
> ARP L2 broadcasts solicit information about IP addresses, and at a
> minimum each such query exposes its own MAC and IP address. Responses
> may be unicast or broadcast, not sure which.
> An active compromised host can easily solicit that information by
> iterating over all the IP addresses on the subnet and performing an
> ARP for each one.

Yes, that's another class of attackers, those that have access to the
link. For those, defense requires coordinated use of MAC address
randomization and IP address selection.

And yes to both of you, the threat model does require modeling the
capacities of attackers. That's work.

-- Christian Huitema