Re: [6tisch-security] Question re draft-ietf-6tisch-minimal-security

[Michael Richardson <[e-mail]>]

Fred Baker <[e-mail]> wrote:
    > The specification makes a number of comments about an IPv6 address
    > based on EUI64. RFC 7217/7721 provides a way to build a stable IPv6
    > address that is not based on the MAC address, and
    > draft-gont-6man-address-usage-recommendations (which has not been
    > adopted, but which I presume will eventually be adopted) recommends
    > using it. What plans might 6tisch have in that direction?

I thought we dealt with this in the "Privacy Considerations" section, which
is attached.   These aren't iPhones that wander from starbucks to starbucks.

In the 6tisch-minimal with PSK-based authorization, it doesn't much matter
how the IID is generated. It's essentially never used for security function,
in fact, many of the devices out there just make up non-stable random EUI64s
and IIDs on each boot anyway.  Many consider that a bug.

In the zero-touch situation, we expect the 802.1AR IDevID certificate to
include the IID.  If the manufacturer wants to run 7217 in the factory and
produce the IID that way, they can/should do that.  This obscures the
manufacturers' IEEE assigned 32-bit OUI, which can be seen as privacy
enhancing, but may be very security negative when it comes to auditing.

Once in production, we replace all 8-byte EUIs (and derived IPv6 IIDs) with
2-byte assigned addresses.



This is the text from the draft:

# Privacy Considerations

This specification relies on the uniqueness of EUI64 that is transferred in
clear as part of the security context identifier. (EDNOTE: should we say IID
here?)
Privacy implications of using such long-term identifier are discussed
in {{RFC7721}} and comprise correlation of activities over time,
location tracking, address scanning and device-specific vulnerability
exploitation.  Since the join protocol is executed rarely compared to
the network lifetime, long-term threats that arise from using EUI64
are minimal.
In addition, the join response message contains an optional short address
which can be assigned by JRC to the pledge.
The short address is independent of the long-term identifier EUI64 and is
encrypted in the response.
For that reason, it is not possible to
correlate the short address with the EUI64 used during the join.  Use
of short addresses once the join protocol completes mitigates the
aforementioned privacy risks.  In addition, EDHOC may be used for
identity protection during the join protocol by generating a random
context identifier in place of the EUI64
{{I-D.selander-ace-cose-ecdhe}}.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-