Re: [ipwave] Alissa Cooper's Discuss on draft-ietf-ipwave-ipv6-over-80211ocb-49: (with DISCUSS and COMMENT)

[Alexandre Petrescu <[e-mail]>]

This is a difficult thing to do, and it needs some long reflection on my
side.  But I would like to help progress the document.

Allow me to group below the privacy-related quotations from Alissa
Cooper, Barry Leiba and Roman Danyliw.  This is in order to reduce the
number of emails that I send.

Le 10/07/2019 à 20:27, Alissa Cooper via Datatracker a écrit :
[...]

> ----------------------------------------------------------------------
>
>
>
>
>
>
> 
 > DISCUSS:
> ----------------------------------------------------------------------
>
>
>
>
>
>
> 
 > I support Roman's DISCUSS.
> 
> Overall I am unclear on the privacy properties of what this document 
> specifies.

Basically, at this stage the situation is that there are privacy issues
with talking cars and talking Road-Side Units.  These issues can be
witnessed in all IP car trials that I looked at.

They come from:
- lack of implementation of RFC7217 ('privacy' IIDs) in the embedded
   computers.  To my knowledge no embedded linux displays obfuscated
   (random) IIDs in IP LL addresses when typing ifconfig command.
- lack of common recommendation of how to generate a more obfuscated MAC
   address ('random').  There is a recommendation at ETSI ITS, a
   recommendation at Microsoft, and a recommendation at IEEE.  These
   three distinct recommendations are supposedly different.  Others may
   disagree.
- unknowns about the IPR status of the MAC generation techniques.
   The places to explore are Microsoft, ETSI and IEEE.  There are some
   clarifications I received in private from something about Microsoft,
   but more exploration is needed.  BEcause, on my side, I do not want to
   put here a method of MAC address generation that is protected by
   somebody else.

> I think it would help to have a clear statement about the 
> circumstances under which each kind of address generation scheme is 
> recommended.

After much reflection, I express I agree with the need.  It would be so
much helpful for implementer reading an RFC to see an algorithm in front
of his eyes telling what to implement, and what to not care about.

The recommendation could be something like this: if on your embedded
platform the RFC 7217 (privacy IIDs) implementation is available then
use it all while making sure the changes in IIDs dont break your
application; if they do, dont use it, and inform users there are
Privacy risks.

And I have some doubts.  I often fear that it is not because we make 
MUST RFC 7217 that it becomes implemented.  There are good reasons from 
implementers not to implement it.

Others think the contrary: put the MUST RFC 7217 in the I-D and the 
implementers will have to.

So, I am some times tempted to just reflect the current situation (there
is no privacy) and develop later a method to protect.

But it is just my thoughts.  Others may have another oppinion, that I am
curious to learn.

> Were RFC 4941 addresses not considered because addresses generated 
> according to RFC 8064 have functionally equivalent properties given 
> how often moving vehicle change subnets?

YEs, that is one reason why.

There are more reasons:
- rfc 4941 (privacy addresses) are not implemented in many embedded
systems.  rfc 4941 and rfc 7217 (privacy addresses) are implemented
mainly in BSD and derivatives; these BSD flavors do not implement OCB;
given the choice, BSD is not used.  There are other OSs specific to 
embedded systems, and none has MAC address generations schemes, as far 
as I know.

- stable link-local addresses are needed when forming subnets of cars,
because there are routing table entries with next hop values that must
stay stable.  (worse, they should be easily remembered by humans in the
beginning, and even the LL addresses EUI64 are hard to work with).

> For link-local addresses, is it possible to give recommendations for
>  when IIDs should be re-generated?

It is possible.

On my side I do not want to do it (re-generate), because I have never
tried to regenerate.  I do not want it.

There are groups of people at ETSI and some trials that do consider
re-generations of LL address.  This implies re-generatin of certificates
as well.  These certificates are not openly available; they depend on
closed-circuit CAs.  They are hard to test and dont scale to large
sizes.  They are hard to access.

I do not want to get in the way of satisfying the request of giving
recommendations for when IIDs should be re-generated.  Maybe a
recommendation should be given by somebody trying it.

Barry Leiba wrote recently:
>>>> If semantically opaque IIDs are needed, they MAY be generated 
>>>> using the method for generating semantically opaque IIDs
>>> 
>>> This isn’t wrong with the “MAY”, but I think it really is just a
>>>  non-keyword “may”.

I tend to agree.  It is a non-keyword 'may'.

>>>> In 802.11-OCB networks, the MAC addresses MAY change during 
>>>> well defined renumbering events.
>>> 
>>> Also a statement of fact, so “may”.

I agree.

Roman Danyliw wrote recently:
> ** What specific ETSI protocols are being recommended from
> [ETSI-sec-archi]?

I do not know for sure myself.  One would ask Jérôme Härri.

I looked myself at the public document referred (ETSI TS 102 940 V1.2.1
(2016-11)).  I could find a recommendation to generate MAC address:
"shall be derived from the identifier provided by the Security Entity in
the ID change notification".  (the "ID Change Notification" seems to be
an application layer message).

 From my side, I do not agree with this method to generate more
obfuscated MAC addresses.

I have some ideas how to generate more obfuscated MAC addresses, but
certainly not in that ETSI way.

> ** What is meant by the drivers’ identity in this case?

There is activity at Gemalto now Thales about e-Driver's License.
Supposedly that is an electronic format of a driver's license that is
more accessible.  I think that driver's license in some countries have
no electronic equivalent at this time.

The trials of electronic Driver's License happened mostly in America,
and were probably totally absent in Europe.

That is all I know.

> What is the pseudonym scheme is being used to protect it or what
> requirements are being set for it?

I do not know myself.

> ** What are the specific challenges of concern around
> pseudo-anonymization approaches to which an allusion is made?
> 
> ** Who is the trusted third parted needed?

There is no trusted third party in the automotive networks.  There are a
few efforts to build national Certificate Authorities, European
automotive PKIs, and similar.  Most are backed by trials.  But there is
no universally agreed CA (like is e.g. Verisign in the Internet world).
  They are all expensive to access, and some times even impossible.

What is needed is that the automotive networks use the CAs from Internet.

What is needed is that the automotive networks use the CAs from Internet.

Alex