Re: [ipwave] requirements for CAs for vehicular networks

Alexandre Petrescu <alexandre.petrescu@gmail.com> Wed, 21 April 2021 17:43 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: its@ietfa.amsl.com
Delivered-To: its@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9183E3A30E5 for <its@ietfa.amsl.com>; Wed, 21 Apr 2021 10:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.668
X-Spam-Level:
X-Spam-Status: No, score=0.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, NML_ADSP_CUSTOM_MED=0.9, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VN5rjc0aQWeC for <its@ietfa.amsl.com>; Wed, 21 Apr 2021 10:43:23 -0700 (PDT)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A410B3A30E4 for <its@ietf.org>; Wed, 21 Apr 2021 10:43:23 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13LHhIoQ004778 for <its@ietf.org>; Wed, 21 Apr 2021 19:43:18 +0200
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id D0675206024 for <its@ietf.org>; Wed, 21 Apr 2021 19:43:18 +0200 (CEST)
Received: from muguet1-smtp-out.intra.cea.fr (muguet1-smtp-out.intra.cea.fr [132.166.192.12]) by pisaure.intra.cea.fr (Postfix) with ESMTP id C6AF5204BE4 for <its@ietf.org>; Wed, 21 Apr 2021 19:43:18 +0200 (CEST)
Received: from [10.14.0.28] ([10.14.0.28]) by muguet1-sys.intra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id 13LHhHRS025004 for <its@ietf.org>; Wed, 21 Apr 2021 19:43:17 +0200
To: its@ietf.org
References: <acc0f475-7f7b-bfbe-1099-913f0cef4de6@gmail.com> <01d601d731e3$140e2ed0$3c2a8c70$@eurecom.fr> <0600020f-b6ca-4d6d-2499-817586bc3548@gmail.com> <CAMEeBw9eaPBRT26BqqmXdEpqFzSTGt8w46wmexfg7ax4aRP-pQ@mail.gmail.com> <CAA2OGZCntE+FUtzKwxrsH7i_q70jjZuPoUjRG7cYmEVRHFJU8g@mail.gmail.com> <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <1ec103fe-7a50-cb2c-0763-30cc6362bf13@gmail.com>
Date: Wed, 21 Apr 2021 19:43:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <19dce5f5-8dca-55c2-4d46-bb83046562ab@gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/its/k67h_bgW3ivX946gj24vckGk9P8>
Subject: Re: [ipwave] requirements for CAs for vehicular networks
X-BeenThere: its@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/its>, <mailto:its-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/its/>
List-Post: <mailto:its@ietf.org>
List-Help: <mailto:its-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/its>, <mailto:its-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2021 17:43:29 -0000

This is my list of requirements for CAs for vehicular networks:
- must be reachable on IPv6, and their website too.
- must be present built-in in open source web browsers.
- must express their requirements to vehicular networks in terms of
   capabilities of certificates.  For example, a CA may agree to sign
   only a number of certs (1000?) per vehicle, but no more.  Or might
   suggest new fields in these X.509 certs that they are ready to confirm
   (to certify).
- must sign and offer almost for free certificates for vehicular
   networks.  It's not because the car industry makes much money that a
   lot has to be wasted on artificial costs.  The way for CA to make
   money should be different than direct charging the vehicular industry.
- must contribute to make Internet better, and not seggregate the
   vehicular networks from the Internet.

And this below is our dicussion that helped me frame these requirements, 
and I thank you for the discussion.

Le 20/04/2021 à 11:51, Alexandre Petrescu a écrit :
[...]

>> - Scoop@F http://www.scoop.developpement-durable.gouv.fr/ 
>> <http://www.scoop.developpement-durable.gouv.fr/> :

This is not reachable on IPv6.

>>
>>
>> which is about deploying 3000 cars + 2000 km of roads
>>
>>
>> - InterCor https://intercor-project.eu/
>> <https://intercor-project.eu/>,

This is not reachable on IPv6.


>>
>> - C-Roads Platform https://www.c-roads.eu/platform.html 
>> <https://www.c-roads.eu/platform.html>

This is not reachable on IPv6.


>>
>>
>> InterCor and C-Roads are about harmonising C-ITS specifications in
>> Europe
>>
>>
>> - INDID 
>> https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html 
>>
>>
>> <https://www.c-roads.eu/pilots/core-members/france/Partner/project/show/indid.html>. 
>>
>>
>>
>>
>>
>> All these projects are using ETSI TS 103 097 certificates, which is a
>>  profile of 1609.2 to secure C-ITS messages:
> 
> But there are also other projects funded by the EU in the same domain 
> (connected automated mobility with self-driving cars) and where more 
> open certificates are being used, with more open source software.
> 
>>
>> https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf 

This is reachable on IPv6.

>>
>>
>> <https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf> 
>>
>>
>>
>>
>> As mentioned by Jerome, one use case of the RFC 8902 could be to sign
>>  CAM and DENM messages on facilities layer and not geonet as
>> specified in ETSI.
> 
> Yes, but has that been done?  HAs someone put CAM messages on IP on a 4G 
> link and signed with 1609.2 certificates?  I think not.
> 
> It would be good if it worked, but it would need the CAs to know these 
> certifiicate formats, and the CAs would need to be known in common 
> browsers.
> 
>> Yes, in projects dealing with C-ITS security
>> interoperability, we use MQTT to exchange C-ITS messages between many
>> countries to ensure continuity of service when vehicle is crossing
>> borders.
> 
> Ok, good to know.
> 
>>
>>
>> We could also use the RFC for Vehicle-To-Internet simply to upload
>> log of vehicle for example etc…
> 
> Yes, but what CA would be put in the server of that log?  Would that CA 
> be a self-made CA with openssl (or other open source software), or would 
> it be a widely known CA like the CAs present in firefox, for example?
> 
> My guess is that you assume a self-made CAs, and I agree with it for 
> experimentation.
> 
> But for deployment there would be a need for the existing CAs in the 
> browsers to implement these 1609.2 certs.  And they are paying.  I doubt 
> it could work.
> 
>>
>>
>>
>>>> The reason is because the former is all open source software and
>>>> freely accessible standards, whereas  1609.2 are closed documents
>>>> and ETSI ITS certificate software is not integrated in mainline
>>>> software like openssl.
>>
>>
>> There's a java implementation of 1609.2/103 097 here: 
>> https://github.com/pvendil/c2c-common 
>> <https://github.com/pvendil/c2c-common>. I already used it.

This is not reachable on IPv6.  Several people who contributed to IETF 
also asked github support to put it on IPv6.  There is no answer since 
some time now.

I would suggest the person who maintains that java implementation of 
1609.2 to put it on another server that is reachable on IPv6.  Or 
otherwise to ask too, like the others have, github.com to be on IPv6.


> Yes, but the spec is paying.  That does inspire seriousness but might 
> inspire risk for the confidence.
> 
>>
>>
>>>> ITS-specific CAs are closed, hard to access and the certificate
>>>> are
>>
>> expensive.  hard to access and the certificate are expensive.
>>
>>
>> you can get certificates from
>> https://www.ghsiss.com/v2x-certificates/ 
>> <https://www.ghsiss.com/v2x-certificates/>

This is not reachable on IPv6.  And ISS CA (Integrated Security 
Services) is not in my browser either.

In comparison, Microsec might provide certificates in bilateral 
agreements that might cost less, or almost 0.  And Microsec is reachable 
on IPv, and is in my browser.

There is also the Let's Encrypt CA that is reachable on IPv6.  I think 
they might offer certificates free of charge too.

These kinds of CAs (Microsec and Let's Encrypt) are good candidates to 
whom to propose interoperability for vehicular networks on IPv6.

There might be other such CAs?

So, the question is whether Microsec and Let's Encrypt (who are on IPv6 
and offer somehow very cheap or almost free certificates), offer 
compliance with RFC 8902?  If yes, is it with ITS Certificates (1609.2) 
or with X.509 certificates?

Alex

> 
> Thanks for the pointer, I did not know ghsiss.  Are they paying 
> certificates?
> 
> Recently I worked with Microsec and they might also propose certificates 
> for cheaper (free), if it is for evaluation, or for academia, or 
> similar.  And Microsec CA _is_ present in the browsers.  But can 
> Microsec sign these 1609.2 certificates and still not ask me (end user) 
> to pay for the certificates?
> 
> Another thing to consider is whether or not ghsiss (and Microsec for 
> that matter) are reachable on IPv6.  That is also a make kor break 
> condition of use.  It is worth trying.
> 
> Thanks for the message.
> 
> Alex
> 
>>
>>
>>
>>>> In  my personal opinion, it remains good if IPWAVE provides a
>>>> guideline on how to secure IP vehicular communication, including
>>>> interoperability between systems (although I have at that time
>>>> limited resources to actively contribute to this), as several
>>>> options are on the table and we need to guarantee the trust
>>>> chain, even considering different protocol or standards being
>>>> used.
>>
>>
>> I’m also interested to work on security interoperability in C-ITS and
>> we could add:
>>
>>
>> - Misbehaving in vehicular network
>>
>> - Revocation management
>>
>> - Pseudonym management/change to avoid tracking and to ensure
>> privacy
>>
>>
>> Thank you Russ for your time on this RFC and for your valuable
>> review.
>>
>>
>>
>> Kind regards
>>
>> Mounira
>>
>>
>>
>>
>>
>>
>>
>>
>> ---------- Forwarded message --------- De : *Alexandre Petrescu*
>> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> 
>> Date: jeu. 15 avr. 2021 à 22:44 Subject: Re: [ipwave] RFC8902 - TLS
>> with ITS Certificates, EXPERIMENTAL, and the one PKI and one
>> Internet To: Jérôme Härri <Jerome.Haerri@eurecom.fr 
>> <mailto:Jerome.Haerri@eurecom.fr>>, IPWAVE WG <its@ietf.org 
>> <mailto:its@ietf.org>>
>>
>>
>>
>>
>> Le 15/04/2021 à 12:35, Jérôme Härri a écrit :
>>> Dear Alex,
>>>
>>> Thanks. Indeed such discrepancies is particularly an issue when it 
>>> comes to merging wireless and wired (V2I). For example, you send a 
>>> DENM over 5G reaching a MEC. It will remove the ETSI KPI and do 
>>> something on its own (not fully sure what exactly), or if you use 
>>> MQTT type of interaction, where it is even less clear (what a
>>> broker will do on a DENM sent over JSON is not fully clear to keep
>>> track of any kind of security/data integrity...
>>>
>>> For that matter, there was one effort from C-ROAD to develop 
>>> something called 'Facilities' PKI, saying that the ITS KPI are at 
>>> facilities layer and no longer at geonet. The advantage is that at 
>>> least now, you do not need to remove the KPI when moving and 
>>> exchanging DENM (or else) in backend. But I am not sure of the 
>>> current status or even if this WI is actually active.
>>>
>>> Now, I do not fully agree with you with the equivalence of the 
>>> internet KPI and ITS KPI. Indeed, the principle is the same, but
>>> in the test you mention, the trust chain is not guaranteed (you
>>> edit your own root-CA for the purpose of the tests, but for example
>>> in one of our cross-border deployment (e.g. DE-FR), this solution
>>> does not work, as a German car will not recognize the CA from a
>>> French root-CA. So, the key issue I see is not really (or only) on
>>> security but on Trust. The ITS KPI is one option, there might be
>>> others, but 'open ssl' strategies still face the trust-chain
>>> issue.
>>
>> Jérôme,
>>
>> I agree with you.
>>
>> In the discussion above I think you meant 'PKI' throughout (Public
>> Key Infrastructure), and not 'KPI' (Key Performance Indicator).
>>
>> That said, the question you formulate about how a car-to-server MQTT 
>> interaction on IP would be authenticated by certificates that are 
>> verified by CAs that are absent from normal browsers, or how the CAs 
>> that are present in normal browsers would help authenticating CAM 
>> messages sent on IP - is a very relevant question.
>>
>> Alex
>>>
>>> Best Regards,
>>>
>>> Jérôme
>>>
>>> -----Original Message----- From: its <its-bounces@ietf.org
>> <mailto:its-bounces@ietf.org>> On Behalf
>>> Of Alexandre Petrescu Sent: Thursday, 15 April 2021 12:20 To:
>>> IPWAVE WG <its@ietf.org <mailto:its@ietf.org>> Subject: [ipwave]
>>> RFC8902
>> - TLS with ITS
>>> Certificates, EXPERIMENTAL, and the one PKI and one Internet
>>>
>>> Hi, IPWAVErs,
>>>
>>> A colleague pointed me to this recently issued RFC 8902 about TLS 
>>> with ITS Certificates.
>>>
>>> This RFC is of an EXPERIMENTAL Category.
>>>
>>> It might be in agreement with other IEEE standards such as 1609.2.
>>>
>>> But I must say that I think it further deepens the discrepancy 
>>> between what is PKI in the Internet and what is the closed PKI for 
>>> ITS.  That is a discrepancy that exists for a long time, and I
>>> must share that - IMHO - I am surprised that the IETF issues an RFC
>>> that further promotes such a discrepancy.
>>>
>>> This discrepancy is the following: in a few trials I participated, 
>>> and some about I heard of, people use normal PKI with openssl and 
>>> normal certificates in cars, over IP, on cellular links like 4G. They 
>>> work fine.  The CA is a local CA (not a commercial CA), but
>>> the concept _is_ compatible with normal CAs.  These dont use the
>>> ETSI ITS-specific certificates, neither the 1609.2 certificates.
>>>
>>> I think there are more such trial deployments using local (but 
>>> standard, openssl PKIs and certificates) than there are trials
>>> using ETSI ITS certificates or 1609.2 certificates.  The reason is
>>> because the former is all open source software and freely
>>> accessible standards, whereas 1609.2 are closed documents and ETSI
>>> ITS certificate software is not integrated in mainline software
>>> like openssl.
>>>
>>> There are many easily accessible CAs (Certificate Authorities)
>>> that are integrated in the Internet and in main web browsers,
>>> whereas the ITS-specific CAs are closed, hard to access and the
>>> certificate are expensive.  Many strong oppinions maintain that it
>>> should stay that way: cars PKI different than Internet PKI.
>>>
>>> There should be one Internet, and that means one trust, and one
>>> PKI.
>>>
>>> Everything else should not be done at IETF, I think; hence my
>>> comment about this particular RFC.
>>>
>>> That is my humble oppinion.
>>>
>>> I would like to hear other oppinions?  Maybe I miss something...
>>>
>>> Alex
>>>
>>> _______________________________________________ its mailing list 
>>> its@ietf.org <mailto:its@ietf.org>
>> https://www.ietf.org/mailman/listinfo/its 
>> <https://www.ietf.org/mailman/listinfo/its>
>>>
>>> _______________________________________________ its mailing list 
>>> its@ietf.org <mailto:its@ietf.org>
>> https://www.ietf.org/mailman/listinfo/its 
>> <https://www.ietf.org/mailman/listinfo/its>
>>>
>>
>> _______________________________________________ its mailing list 
>> its@ietf.org <mailto:its@ietf.org> 
>> https://www.ietf.org/mailman/listinfo/its 
>> <https://www.ietf.org/mailman/listinfo/its>
>>
>>
>> _______________________________________________ its mailing list 
>> its@ietf.org https://www.ietf.org/mailman/listinfo/its
>>
> 
> _______________________________________________
> its mailing list
> its@ietf.org
> https://www.ietf.org/mailman/listinfo/its