Subject: Stable privacy addresses (upcoming rev)

From: Fernando Gont <[email-masked]>
Date: Wed, 28 Mar 2012 17:53:29 +0200

Folks,

Probably the only objection that I got for
draft-gont-6man-stable-privacy-addresses is that the prefix shouldn't be
included in F() (the hash function).

I'd like to clarify the motivation for that, and also trigger some
discussion on the topic such that I can produce a revision of this
docuement that addresses any remaining concerns.

* Motivation for including the SLAAC Prefix in F() (the hash function)

The essential rationale for including the prefix in the hash function is
that, if we don't, then we'd be leaking more information than we should.

If we don't include the prefix as part of the data to be hashed, then
the Interface-ID will be exactly the same no matter whether the devices
moves from one network to another, and hence the node could be tracked,
even if it implements RFC 4941.

For example, think about the following scenario:

Attack scenario #1

A host configures the stable addresses without including the Prefix in
the hash function. Let's say the host employs any application that needs
to perform a server-like function (P2P, or whatever). As a result of
that, an attacker attacker participating in that application (e.g., P2P)
would learn the Interface-ID used for the stable address.

Now the same host moves to a completely different network, and uses the
same P2P application, probably even with a different user. The attacker
now interacts with the same node again, and hence can learn the "new"
stable address. Since the interface ID is the same as the one above, he
can infer that it is communicating with the same device as before.

Had the host included the Prefix when computing the Interface-ID (with
the hash function F()), the Interface-ID would have been different, and
this wouldn't have been made possible.

This is just *one* possible attack scenario, which should remind us that
one shouldn't disclose more than it is really needed (and a static
Interface-ID across many different networks does exactly that).

* Use of draft-gont-6man-stable-privacy-addresses without RFC 4941

Temporary addresses are painful to manage. They make painful to
correlate the activities of your own nodes. FOr example, one host gets
infeceted will malware, you logged the IPv6 address, but then you don't
know which node was using that address at that point in time.

This is the reason for which in many deployments temporary addresses
(RFC 4941) are disabled (e.g., look at any presentation by Ron Broersma).

When you disable temporary addresses, all you're left with is whatever
stable addresses your host uses. If you don't include the Prefix in F()
(the hash function) then, while you may be resistant to host scanning
attacks (your addresses is not predictable anymore), you're still
trackable, since your interface ID doesn't change as you move from one
network to another.

So yes, there are cases in which you may want privacy, without
necessarily be willing to deal with the burden of temporary addresses.
And if you're just going to have stable addresses, you do not really
want the Interface ID to be constant across networks.

* Concerns about CPU impact

Other folks have expressed concerns (in corridor meetings) that if the
Prefix is included in the hash function, they may need to recompute the
hash every time they attach to a network (assuming the SLAAC prefix
changes), and that would be expensive. I personally think this shouldn't
be an issue for most implementations (for instance, we do MD5 for every
single new TCP connection! -- see RFC 6528). And, in any case, we do not
really specify which hash function to use. -- If you're concerned about
CPU, you may want to use a (CPU-wise) cheaper function.

That said, I'd have no problem with making the inclusion of the Prefix a
SHOULD (i.e., do it, unless you have very good reasons not to do so
(such as CPU-constraints)), or even a MAY (if inclusion of the Prefix in
the hash function turns out to be the show-stopper here).

If you have any feedback/comments, I'd be glad to hear. I'm planning to
rev the document asap, clarifying and incorporating many of the things
explained throughout this e-mail. So if you send your feedback shortly,
the next rev could reflect your comments.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Tassos Chatzithomaoglou <[email-masked]>
Date: Wed, 28 Mar 2012 21:26:23 +0200

I like & support the idea, but it's not clear to me the 
randomness/stableness of the created identifiers.

Is there a guarantee, that after rebooting or powering-off/on the host, 
the produced RID will remain the same if Prefix remains the same?
Is there a way to change the secret key in case someone discovers it or 
for whatever reason?
I would like more examples (and probably a better definition) of the 
network_id. i.e. the SSID is something that is not exactly local to the 
host. Are all the usage cases like this? i.e. in case of fixed network, 
would it be the directly attached router's mac?

Extra question/idea..
If this address creation functionality can be transferred to a dhcp 
server too (which i don't see why not, since the critical input fields 
are already there), maybe the text regarding SLAAC should be replaced 
with something more appropriate. Or just add a note regarding this extra 
option (someone mentioned about a dhcp server creating temporary 
addresses).

Finally, I would prefer to keep the prefix as mandatory to the algorithm 
for the exact reason that you wrote.

PS: should there be any paragraph about the source address selection 
(rfc3484/bis) RFCs and these stable privacy addresses and how they 
should be handled, especially in comparison to the temporary ones?

--
Tassos

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Mar 2012 13:44:16 +0200

Hi, Tassos,

Thanks so much for your comments. Please find my responses inline....

> the produced RID will remain the same if Prefix remains the same?

Well, yes: As long as all the values you use for computing the hash are
the same, the resulting Interface-ID will be the same.

> Is there a way to change the secret key in case someone discovers it or

If you change the key, the interface ID changes. That's implicit, since
the hash function is expected to be cryptographically secure.

(and one would argue that this is also desired, since once the key has
been compromised, an attacker could use it to predict the Interface-ID
that you'd use in other networks).

> would it be the directly attached router's mac?

The "Network_ID" is anything that would let you differentiate from one
network to another, even if the same SLAAC prefix is being advertised.

For example, you're connecting to a number of wifi networks, and the
router advertises the same ULA prefix, including the SSID would result
in different interface identifiers. In principle, the same thing would
be true for link-local addresses: you could use some sort of Network_ID
when generating the Interface-ID for link-local addresses, such that the
address changes when you move from one network to another.

(This is useful since sometimes this link-local addresses may leak out).

> option (someone mentioned about a dhcp server creating temporary

It could be transferred. So this is a good point. -- I will try to
address this in the next rev of the document.

> for the exact reason that you wrote.

I fully agree with you, and think it would be a bad idea to remove the
prefix from the hash. Some folks have argued against including the
prefix, and hence I just want to hear comments from others.

> should be handled, especially in comparison to the temporary ones?

Not sure what you mean....

Thanks!

Best regards,

---

From: Ray Hunter <[email-masked]>
Date: Fri, 30 Mar 2012 15:04:16 +0200

I have reviewed draft-gont-6man-stable-privacy-addresses and have 
already sent some nits direct to the author.

I like this draft.

One of my biggest criticisms of RFC4941 today is that end nodes act 
unilaterally, and that due consideration was not made of the needs of 
organizations (such as Enterprises or ISPs), where logging is perfectly 
legal, desirable, and has compliance issues.

If I were to write the design goal for interface identifier privacy 
myself I'd write:

o    It should be easy for an authorized person to be able to reliably 
predict the interface
       identifiers that will be generated by the algorithm, provided 
that the authorized person has
       access to the algorithm and the secret keying material used in 
generating the interface identifiers, but not otherwise.

The idea being that authorized persons e.g. law enforcement and network 
managers SHOULD be able to correlate activity at a later date (for legal 
compliance, logging, fault finding etc.) whilst an attacker or 
unauthorized person SHOULD NOT.

I have no objection per se to the time variance of temporary addresses 
of RFC4941, provided that the rotation of addresses happens in a 
controlled manner. Again, a common criticism of 4941 is that long-lived 
sessions may be broken, and there's no way of knowing when authorized 
persons should relearn/re-correlate private addresses to native 
EUI64's/machines.

I can think of 2 mechanisms to achieve controlled time-variance using 
your draft:

1. If controlled renumbering is ever widely implemented, it would be 
possible for a network manager to regularly rotate the /64 subnet 
prefixes in a controlled manner (add new prefix, deprecate old prefix) 
to generate new Random Interface Identifiers (RIDs), rather than this 
being an unilateral choice of the end nodes as in 4941. An end node 
would generate a new RID and use this for new sessions, whilst existing 
sessions would continue to use the RID generated from the deprecated 
prefix. This would mean that the time-variant aspect of user privacy in 
4941 could be maintained, whilst end node activity could still also be 
tracked and correlated by the authorized person/network manager (but not 
as easily by an attacker who does not have access to the secret key).

Some might say that this is a weakness, in that a node connected to a 
3rd party LAN could be tricked into giving away a few bits of 
information every time a RID is regenerated. However, I don't consider 
that a major issue, because the 3rd party LAN manager could anyway track 
usage directly, either based on the /64 parent prefix or some other 
means like EUI64 media address. A remote passive attacker might also 
have difficulty working out exactly how a new /64 prefix is correlated 
to the existing /64 prefix (provided there was enough variance in users 
and all other things/information leaks being equal.)

2. If the implementation provided a mechanism for the secret_key to be 
changed, it would also be possible for a network manager to regularly 
update the secret_keys in a controlled manner so that an end node would 
generate a new RID when an interface was re-initialised.

For these reasons, I feel that all implementations SHOULD include a 
mechanism for the secret_key to be updated (to repair a potentially 
compromised node where the secret_key has been learned by an 
unauthorized person, complicate long-term snooping of RID changes when 
prefixes change, and to allow a manager to trigger a RID rotation per node)

I make no comment on the mechanism by which the secret_key should be 
updated. Some environments may require specialist hardware, or use of an 
existing Security Association to create a secure channel to a secure 
node, whilst others might consider a DHCPv6 option sufficient. These 
mechanisms could be defined in related drafts.

This secret_key could then also be stored somewhere in a central 
(secure) log for use in cross-referencing obfuscated addresses from 
various logs at a later date.

Some switches or other devices that limit access to a single IPv6 link 
local address per port may have problems with RIDs.  RFC4941 Sections 
3.6 & 4 are certainly pertinent.

regards,
RayH

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 31 Mar 2012 08:47:21 +1300

Ray,

On 2012-03-31 02:04, Ray Hunter wrote:
...
> unauthorized person SHOULD NOT.

If you were a blogger sitting in an Internet cafe in a country governed
by a repressive regime, you would probably hold a different view.

    Brian

---

From: Fernando Gont <[email-masked]>
Date: Fri, 30 Mar 2012 22:20:25 +0200

Brian,

> by a repressive regime, you would probably hold a different view.

If the regime controls the local-link, then as far as address-tracking
is concerned, you're toast. -- They could sniff the network and log the
address->MAC mappings, have RAs require you to do DHCPv6 and then have
DHCPv6 assign you a constant address, etc.

Thanks,

---

From: Ray Hunter <[email-masked]>
Date: Fri, 30 Mar 2012 22:50:35 +0200

> by a repressive regime, you would probably hold a different view.
Please let's not take this out of context. We're talking about 
obfuscating interface identifiers. If I'm sat in an Internet cafe in a 
repressive regime (and I have visited and worked in various countries 
around the World, including one that fingerprinted me on entry, one that 
took a full body scan capable of looking through clothes, and one which 
is known to operate firewalls and passive monitoring on all 
International links), obfuscating an interface identifier is not going 
to protect my rights. That repressive regime would anyway likely have 
access to a copy of my passport or ID card, my network login 
credentials, the time I entered the Internet cafe, which seat I was sat 
on, a report from my neighbors, details of my phone's SIM card, man in 
the middle HTTPS monitoring, my MAC address, the /64 prefix I was using, 
a key logger running on the ISP host, a camera pointed at the screen  .....

I do not attempt to define "authorized persons" any further than 
providing an example. I express no preference whatsoever on the question 
of whether privacy is desirable or not on this list, nor to what 
standard, nor where the balance lies between rights of the state or 
corporation and the rights of the individual, nor whether particular 
laws are sensible or not.

I'm just trying to comply with local laws when giving advice to 
companies operating in countries where I provide consultancy. And many 
of those local laws include a requirement for corporations to retain a 
log of IP addresses, network communications, and user credentials for 
several months, and to provide access to this information to "authorized 
persons" when necessary, even though they are some of the most liberal 
regimes in the World.

regards,
RayH

---

From: Christian Huitema <[email-masked]>
Date: Sat, 31 Mar 2012 05:32:02 +0000

> If the regime controls the local-link, then as far as address-tracking is concerned, you're toast. -- They could sniff the 
>network and log the address->MAC mappings, have RAs require you to do DHCPv6 and then have DHCPv6 assign you a
 > constant address, etc.

The obvious solution is to randomize the MAC address, and I would definitely want to do that when visiting untrusted networks. 

Of course, randomizing the MAC address is necessary but not sufficient. There are many other ways in which our computer leak information. DHCP messages, for example, contains names and other identifiers. Computers connecting to a network issue a flurry of DNS lookups that can make for good signatures. Etc.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Sat, 31 Mar 2012 14:27:28 +0200

On 03/31/2012 07:32 AM, Christian Huitema wrote:
>> If the regime controls the local-link, then as far as
>> address-tracking is concerned, you're toast. -- They could sniff
>> the network and log the address->MAC mappings, have RAs require you
>> to do DHCPv6 and then have DHCPv6 assign you a constant address,
>> etc.
> 
> The obvious solution is to randomize the MAC address, and I would
> definitely want to do that when visiting untrusted networks.

Or use an external card or even a different system, use it, and destroy
and throw away. :-)

In any case, as noted by Ray, if you're really into the aforementioned
"regime" situation, randomizing the mac address is probably *not* #1 in
your set of priorities.

> Of course, randomizing the MAC address is necessary but not
> sufficient. There are many other ways in which our computer leak
> information. DHCP messages, for example, contains names and other
> identifiers. Computers connecting to a network issue a flurry of DNS
> lookups that can make for good signatures. Etc.

Exactly. That's why I said that if the regime controls the local link,
then, for the most part "game over". - If they don't, you can usually
tunnel somewhere else.

Thanks,