TLS Authentication
Using Intelligent Transport System (ITS) Certificates Telecom ParisFrance mounira.msahli@telecom-paris.fr CiscoUnited States of Americancamwing@cisco.com QualcommUnited States of Americawwhyte@qti.qualcomm.comTelecom Paris France ahmed.serhrouchni@telecom-paris.frTelecom Paris France houda.labiod@telecom-paris.frTLSIntelligent Transport System (ITS) CertificatesIEEEETSI
The IEEE and ETSI have specified a type of end-entity certificate. This document defines an experimental change to TLS to support IEEE/ETSI certificate types to authenticate TLS entities. IntroductionThe TLS protocol allows the use of X.509
certificates and raw public keys to authenticate servers and
clients. This document describes an experimental extension following the
procedures laid out by to support use of the certificate
format specified by the IEEE in and profiled by the
European Telecommunications Standards Institute (ETSI) in . These standards specify secure communications in
vehicular environments. These certificates are referred to in this
document as Intelligent Transport Systems (ITS) Certificates.The certificate types are optimized for bandwidth and processing time
to support delay-sensitive applications and also to provide both
authentication and authorization information to enable fast access
control decisions in ad hoc networks found in Intelligent
Transport Systems (ITS). The standards specify different types of
certificates to support a full Public Key Infrastructure (PKI)
specification; the certificates to be used in this context are
end-entity certificates, i.e., certificates that have the IEEE 1609.2
appPermissions field present.Use of ITS certificates is becoming widespread in the ITS
setting. ITS communications, in practice, make heavy use of 10 MHz
channels with a typical throughput of 6 Mbps. (The 802.11OCB modulation
that gives this throughput is not the one that gives the highest
throughput, but it provides for a robust signal over a range up to
300-500 m, which is the "sweet spot" communications range for ITS
operations like collision avoidance). The compact nature of ITS
certificates as opposed to X.509 certificates makes them appropriate for
this setting. The ITS certificates are also suited to the machine-to-machine (M2M)
ad hoc network setting because their direct encoding of permissions (see
) allows a receiver to make an immediate
accept/deny decision about an incoming message without having to refer
to a remote identity and access management server. The EU has committed
to the use of ITS certificates in Cooperative Intelligent Transport
Systems deployments. A multi-year project developed a certificate policy
for the use of ITS certificates, including a specification of how
different root certificates can be trusted across the system (hosted at
<>,
direct link at <>). The EU has committed funding for the first five years of operation
of the top-level Trust List Manager entity, enabling organizations such
as motor vehicle original equipment manufacturers (OEMs) and national
road authorities to create root certificate authorities (CAs) and have
them trusted. In the US, the US Department of Transportation (USDOT)
published a proposed regulation, active as of late 2019 though not
rapidly progressing, requiring all light vehicles in the US to implement
vehicle-to-everything (V2X) communications, including the use of ITS
certificates (available at <>). As
of 2019, ITS deployments across the US, Europe, and Australia were using
ITS certificates. Volkswagen has committed to deploying V2X using ITS
certificates. New York, Tampa, and Wyoming are deploying traffic
management systems using ITS certificates. GM deployed V2X in the
Cadillac CTS, using ITS certificates. ITS certificates are also used in a number of standards that build
on top of the foundational IEEE and ETSI standards, particularly the
Society of Automobile Engineers (SAE) J2945/x series of standards for
applications and ISO 21177 , which builds a framework for exchanging
multiple authentication tokens on top of the TLS variant specified in
this document.
Experiment OverviewThis document describes an experimental extension to the TLS
security model. It uses a form of certificate that has not previously
been used in the Internet. Systems using this Experimental approach
are segregated from systems using standard TLS by the use of a new
certificate type value, reserved through IANA (see ). An implementation of TLS that is not involved in
the Experiment will not recognize this new certificate type and will
not participate in the experiment; TLS sessions will either negotiate
the use of existing X.509 certificates or fail to be established. This extension has been encouraged by stakeholders in the
Cooperative ITS community in order to support ITS use-case
deployment, and it is anticipated that its use will be widespread. Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
Extension Overview The TLS extensions "client_certificate_type" and
"server_certificate_type" are used to negotiate
the type of Certificate messages used in TLS to authenticate the server
and, optionally, the client. Using separate extensions allows for mixed
deployments where the client and server can use certificates of different types. It is expected that ITS
deployments will see both peers using ITS certificates due to the homogeneity of the ecosystem, but there is no barrier at a technical level that prevents mixed certificate usage. This document defines a new certificate type, 1609Dot2, for usage with
TLS 1.3. The updated CertificateType enumeration and corresponding addition to the CertificateEntry structure are shown below. CertificateType values are sent in the "server_certificate_type" and "client_certificate_type" extensions, and the CertificateEntry
structures are included in the certificate chain sent in the Certificate message.
In the case of TLS 1.3, the "client_certificate_type" SHALL contain a list of supported certificate types proposed by the client as provided in the figure below:
/* Managed by IANA */
enum {
X509(0),
RawPublicKey(2),
1609Dot2(3),
(255)
} CertificateType;
struct {
select (certificate_type) {
/* certificate type defined in this document.*/
case 1609Dot2:
opaque cert_data<1..2^24-1>;
/* RawPublicKey defined in RFC 7250*/
case RawPublicKey:
opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;
/* X.509 certificate defined in RFC 8446*/
case X.509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
As per , the server processes the received
[endpoint]_certificate_type extension(s) and selects one of the offered
certificate types, returning the negotiated value in its
EncryptedExtensions (TLS 1.3) message. Note that there is no requirement
for the negotiated value to be the same in client_certificate_type and
server_certificate_type extensions sent in the same message.TLS Client and Server Handshake shows the handshake message flow for a full TLS 1.3 handshake negotiating both certificate types.
In the case of TLS 1.3, in order to negotiate the support of ITS
certificate-based authentication, clients and servers include the
extension of type "client_certificate_type" and
"server_certificate_type" in the extended Client Hello and
"EncryptedExtensions".Client HelloIn order to indicate the support of ITS certificates, a client
MUST include an extension of type
"client_certificate_type" or "server_certificate_type" in the extended
Client Hello message as described in (TLS 1.3).For TLS 1.3, the rules for when the Client Certificate and
CertificateVerify messages appear are as follows:
The client's Certificate message is present if and only if
the server sent a CertificateRequest message.
The client's CertificateVerify message is present if and only if the client's Certificate message is present and contains a non-empty certificate_list.
For maximum compatibility, all implementations
SHOULD be prepared to handle "potentially" extraneous
certificates and arbitrary orderings from any TLS version, with the
exception of the end-entity certificate, which MUST be
first. Server Hello When the server receives the Client Hello containing the client_certificate_type extension and/or the server_certificate_type extension, the following scenarios are possible:
If both the client and server indicate support for the ITS
certificate type, the server MAY select the first
(most preferred) certificate type from the client's list that is
supported by both peers.
The server does not support any of the proposed certificate
types and terminates the session with a fatal alert of type
"unsupported_certificate".
The server supports the certificate types specified in this
document. In this case, it MAY respond with a
certificate of this type. It MAY also include the
client_certificate_type extension in Encrypted Extension. Then, the
server requests a certificate from the client (via the
CertificateRequest message).
The certificates in the TLS client or server certificate chain
MAY be sent as part of the handshake,
MAY be obtained from an online repository, or
might already be known to and cached at the endpoint. If the
handshake does not contain all the certificates in the chain, and the
endpoint cannot access the repository and does not already know the
certificates from the chain, then it SHALL reject the
other endpoint's certificate and close the connection. Protocols to
support retrieving certificates from a repository are specified in
ETSI .Certificate VerificationVerification of an ITS certificate or certificate chain is described in
section 5.1 of . In the case of
TLS 1.3, and when the certificate_type is 1609.2, the CertificateVerify
contents and processing are different than for the CertificateVerify message
specified for other values of certificate_type in . In this case, the CertificateVerify message contains an
Ieee1609Dot2Data encoded with Canonical Octet Encoding Rules (OER)
of type signed as specified in and , where:
payload contains an extDataHash containing the SHA-256 hash of
the data that the signature is calculated over. This is identical to the
data that the signature is calculated over in standard TLS, which
is reproduced below for clarity.
headerInfo.psid indicates the application
activity that the certificate is authorizing.
headerInfo.generationTime is the time at which the data structure was generated.
headerInfo.pduFunctionalType (as specified in )
is present and is set equal to tlsHandshake (1).
All other fields in the headerInfo are omitted. The certificate
appPermissions field SHALL be present and
SHALL permit (as defined in )
signing of PDUs with the PSID indicated in the HeaderInfo of the
SignedData. If the application specification for that PSID requires Service
Specific Permissions (SSP) for signing a pduFunctionalType of tlsHandshake,
this SSP SHALL also be present. For more details on the use
of PSID and SSP, see , clauses 5.1.1 and
5.2.3.3.3. All other fields in the headerInfo are omitted.The certificate appPermissions field SHALL be present and SHALL
permit (as defined in ) signing of PDUs with the PSID
indicated in the HeaderInfo of the SignedData. If the application
specification for that PSID requires Service Specific Permissions (SSP)
for signing a pduFunctionalType of tlsHandshake, this SSP SHALL also be
present.The signature and verification are carried out as specified in . The input to the hash process is identical to the message input for
TLS 1.3, as specified in , consisting of pad, context string, separator, and
content, where content is Transcript-Hash(Handshake Context,
Certificate).ExamplesSome of the message-exchange examples are illustrated in Figures
and .TLS Server and TLS Client Use the ITS CertificateThis section shows an example where the TLS client as well as the TLS server use ITS certificates. In consequence, both the
server and the client populate the client_certificate_type and
server_certificate_type extension with the IEEE 1609 Dot 2 type as mentioned
in .
TLS Client Uses the ITS Certificate and TLS Server Uses the X.509 Certificate This example shows the TLS authentication, where the TLS client
populates the server_certificate_type extension with the X.509
certificate and raw public key type as presented in . The client indicates its ability to receive and
validate an X.509 certificate from the server. The server chooses the
X.509 certificate to make its authentication with the client. This is
applicable in the case of a raw public key supported by the server.
Security ConsiderationsThis section provides an overview of the basic security
considerations that need to be taken into account before implementing
the necessary security mechanisms. The security considerations described
throughout apply here as
well.Securely Obtaining Certificates from an Online RepositoryIn particular, the certificates used to establish a secure connection MAY be obtained from an online repository. An online repository may be used to obtain the CA certificates in the chain of either participant in the secure session.
ETSI TS 102 941 provides a mechanism that can be used to securely obtain ITS certificates.Expiry of CertificatesConventions around certificate lifetime differ between ITS
certificates and X.509 certificates, and in particular, ITS
certificates may be relatively short lived compared with typical X.509
certificates. A party to a TLS session that accepts ITS certificates
MUST check the expiry time in the received ITS
certificate and SHOULD terminate a session when the
certificate received in the handshake expires. Algorithms and Cryptographic Strength All ITS certificates use public-key cryptographic algorithms with
an estimated strength on the order of 128 bits or more, specifically,
Elliptic Curve Cryptography (ECC) based on curves with keys of length
256 bits or longer. An implementation of the techniques specified in
this document SHOULD require that if X.509 certificates
are used by one of the parties to the session, those certificates are
associated with cryptographic algorithms with (pre-quantum-computer)
strength of at least 128 bits.Interpreting ITS Certificate Permissions ITS certificates in TLS express the certificate holders
permissions using two fields: a PSID, also known as an ITS Application
Identifier (ITS-AID), which identifies a broad set of application
activities that provide a context for the certificate holder's
permissions, and a Service Specific Permissions (SSP) field associated
with that PSID, which identifies which specific application activities
the certificate holder is entitled to carry out within the broad set
of activities identified by that PSID. For example, SAE uses PSID 0204099 to indicate
activities around reporting weather and managing weather response
activities, and an SSP that states whether the certificate holder is a
Weather Data Management System (WDMS, i.e., a central road manager),
an ordinary vehicle, or a vehicle belonging to a managed road
maintenance fleet. For more information about PSIDs, see , and for more information about
the development of SSPs, see .Psid and Pdufunctionaltype in CertificateVerify The CertificateVerify message for TLS 1.3 is an Ieee1609Dot2Data
of type signed, where the signature contained in this Ieee1609Dot2Data
was generated using an ITS certificate. This certificate may
include multiple PSIDs. When a CertificateVerify message of this form
is used, the HeaderInfo within the Ieee1609Dot2Data
MUST have the pduFunctionalType field present and set
to tlsHandshake. The background to this requirement is as follows: an
ITS certificate may (depending on the definition of the application
associated with its PSID(s)) be used to directly sign messages or to
sign TLS CertificateVerify messages, or both. To prevent the
possibility that a signature generated in one context could be
replayed in a different context, i.e., that a message signature could
be replayed as a CertificateVerify, or vice versa, the
pduFunctionalType field provides a statement of intent by the signer
as to the intended use of the signed message. If the pduFunctionalType
field is absent, the message is a directly signed message for the
application and MUST NOT be interpreted as a
CertificateVerify. Note that each PSID is owned by an owning organization that has
sole rights to define activities associated with that PSID. If an
application specifier wishes to expand activities associated with an
existing PSID (for example, to include activities over a secure
session such as specified in this document), that application
specifier must negotiate with the PSID owner to have that
functionality added to the official specification of activities
associated with that PSID.Privacy ConsiderationsFor privacy considerations in a vehicular environment, the ITS
certificate is used for many reasons:
In order to address the risk of a personal data leakage, messages
exchanged for vehicle-to-vehicle (V2V) communications are signed using ITS pseudonym
certificates.
The purpose of these certificates is to provide privacy and
minimize the exchange of private data.
IANA ConsiderationsIANA maintains the "Transport Layer Security (TLS) Extensions"
registry with a subregistry called "TLS Certificate Types".Value 3 was previously assigned for "1609Dot2” and included a
reference to draft-tls-certieee1609. IANA has updated this
entry to reference this RFC.Normative ReferencesIntelligent Transport Systems (ITS); Security; Security
header and certificate formatsETSI
2017ETSI TS 103 097
Intelligent Transport Systems (ITS); Security; Trust and
Privacy Management ETSIETSI TS 102 941IEEE Standard for Wireless Access in Vehicular Environments --
Security Services for Applications and Management MessagesIEEEIEEE Standard 1609.2-2016
IEEE Standard for Wireless Access in Vehicular Environments--Security Services
for Applications and Management Messages - Amendment 2--PDU Functional Types
and Encryption Key Management
IEEEIEEE 1609.2b-2019Information technology - ASN.1 encoding rules: Specification
of Octet Encoding Rules (OER)
ITU-TRecommendation ITU-T X.696IEEE Standard for Wireless Access in Vehicular Environments
(WAVE) - Identifier AllocationsIEEEIEEE 1609.12-2016Intelligent transport systems - ITS station security services
for secure session establishment and authentication between trusted devicesISOISO/TS 21177:2019Requirements for V2I Weather ApplicationsSAE
J2945/3Service Specific Permissions and Security Guidelines for Connected Vehicle ApplicationsSAEJ2945/5_202002AcknowledgementsThe authors wish to thank ,
, ,
, and for their feedback and suggestions on improving this document.
Thanks are due to for his valuable and detailed
comments. Special thanks to ,
, and for their guidance and support of the document.