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

[Christian Huitema <[e-mail]>]

On 9/29/2020 10:59 AM, Brian Dickson wrote:
>
> On Tue, Sep 29, 2020 at 10:30 AM Michael Richardson <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     Christian Huitema <[e-mail]
>     <mailto:[e-mail]>> 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