RE: Stephen Farrell's Discuss on draft-ietf-6man-stable-privacy-addresses-16: (with DISCUSS and COMMENT)

[Christian Huitema <[e-mail]>]

>> Nobody could conceivably object to that, but I do wonder whether the
>> statement "Secret keys should be kept secret" doesn't belong in a much
>> more generic document than this one. Actually a BCP on pitfalls surrounding
>> secret keys and how to protect them would be very valuable, but doesn't
>> belong in this WG.
>
> I agree with you.
>
> I'd say I would have probably objected against adding this (with the
> argument "well, this should be obvious to everyone"). But then I recall
> having a conversation with a folk working on TCP SEQ randomization
> (using a similar scheme) for a popular OS, and apparently they were
> employing a constant secret key for all their systems. Hence, "sometimes
> it's not bad to clarify what you might deem as obvious".

That's actually a tradeoff in Fernando's algorithm.  In order to guarantee reuse of the same IPv6 address at the same location, the system only has to remember the secret key. But if the secret key is disclosed to an attacker, the attacker can predict the IPv6 address that will be used by that system at any future location.

There are other possible designs that don't make the same tradeoff. For example, systems could maintain a list of visited locations and associated IPv6 addresses. When they visit a location not in the list, they can pick a random number for their IID. The system will require more memory, but will have the property that future addresses will be unpredictable, even if an attacker manages to obtain the list of previously used addresses and locations.

-- Christian Huitema