netdev - Re: [RFC PATCH] ipv6: Use dev_addr in stable-privacy address generation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <a50808d0-df80-4fbc-a0aa-5a3342067378@www.fastmail.com>
Date:   Fri, 27 Mar 2020 14:06:03 +0100
From:   "Hannes Frederic Sowa" <hannes@...essinduktion.org>
To:     Bram Bonné <brambonne@...gle.com>,
        "David Miller" <davem@...emloft.net>
Cc:     "Alexey Kuznetsov" <kuznet@....inr.ac.ru>,
        "Hideaki YOSHIFUJI" <yoshfuji@...ux-ipv6.org>, kuba@...nel.org,
        netdev@...r.kernel.org, "Lorenzo Colitti" <lorenzo@...gle.com>,
        "Jeffrey Vander Stoep" <jeffv@...gle.com>
Subject: Re: [RFC PATCH] ipv6: Use dev_addr in stable-privacy address generation

Hello,

On Fri, Mar 27, 2020, at 12:50, Bram Bonné wrote:
> On Thu, Mar 26, 2020 at 7:45 PM David Miller <davem@...emloft.net> wrote:
> > I think the current behavior is intentional in that it's supposed to use
> > something that is unchanging even across arbitrary administrator changes
> > to the in-use MAC address.
> 
> Thank you for your feedback David.
> 
> Could you help me understand the use cases where the admin / user
> chooses to use MAC address randomization, but still wants an IPv6
> link-local address that remains stable across these networks? My
> assumption was that the latter would defeat the purpose of the former,
> though it's entirely possible that I'm missing something.

The main idea behind stable IPv6 identifiers is to eventually replace EUI-48 based generated addresses, because knowledge of the MAC address should never leave the broadcast domain you are in. This leads to tracking of a user moving between different networks (in this case moving between different ipv6 prefixes). It does not necessarily replace the temporary address mode which fully randomizes addresses and is still available to you for use in cases where you don't want to have this compromise. temp_addresses are still a good choice to use.

MAC address randomization was mainly introduced to blind the unique identifier during wifi probing and association, where no IPv6 traffic is yet visible on unencrypted links. As soon as the encrypted link between your wifi endpoint and the access point is established, IPv6 addresses are generated and used inside the "encrypted wifi tunnel". This is an orthogonal measure to reduce the exposure of unique identifiers in the closer geographical proximity.

You might want to combine those two features: Not being able to be disclosed in your proximity while having a stable address on your network. If that is not your goal, you can still enable temporary addresses, which will fully randomize your IPv6 addresses and are thus is completely independent of your MAC address. This would meet your concerns above.

My additional concern with this patch is that users might already expect a certain way of the generation of stable IPv6 identifiers: even though wpa_supplicant randomizes the mac address, they might already depend on the stable generation of those addresses. If this changes, contact to those systems might get lost during upgrade. Though I don't know how severe this scenario is, I do, in fact, have some IPv6 stable identifiers in my shell history which are wifi endpoints.

If the IPv6 link local address can get discovered on the unencrypted wifi medium, I would be concerned but I don't think that is the case. In case of fully unencrypted wifis you can make the above case. It is possible to determine if a network endpoint (with the same secret and permanent mac address) shows up again. In this case I would recommend temporary addresses.

Bye,
Hannes