| Network Working Group | M. Msahli, Ed. |
| Internet-Draft | Telecom Paris |
| Intended status: Experimental | N. Cam-Winget, Ed. |
| Expires: April 24, 2020 | Cisco |
| A. Serhrouchni, Ed. | |
| H. Labiod , Ed. | |
| Telecom Paris | |
| W. Whyte, Ed. | |
| Qualcomm | |
| October 22, 2019 |
TLS Authentication using IEEE 1609.2 certificate
draft-msahli-ise-ieee1609-02
This document specifies the use of the IEEE/ETSI certificate type to authenticate TLS entities. The goal is to enable the use of end-entity certificate specified by the IEEE and the European Telecommunications Standards Institute (ETSI). This specification defines an experimental change of TLS to support IEEE/ETSI certificate type.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 24, 2020.
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
The TLS protocol [RFC8446] [RFC5246] uses X.509 certificates and Raw Public Key in order to authenticate servers and clients. This document describes an experimental extension following the [RFC7250] to support use of the certificate format specified by the IEEE in [IEEE1609.2] and profiled by the European Telecommunications Standards Institute (ETSI) in [TS103097]. These standards specify secure communications in vehicular environments. These certificates are referred to in this document as Cooperative Intelligent Transportation Systems (C-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 such as are found in Intelligent Transportation Systems (ITS). The standards specify different types of certificate 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 C-ITS certificates is becoming widespread in the C-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" for communications range for ITS operations like collision avoidance). The C-ITS certificates are also suited to the M2M ad hoc network setting, because their direct encoding of permissions (see Security Considerations, section 7.6) 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 C-ITS certificates in Cooperative Intelligent Transportation Systems deployments. A multi-year project developed a certificate policy for the use of C-ITS certificates, including a specification of how different root certificates can be trusted across the system (hosted at https://ec.europa.eu/transport/themes/its/c-its_en, direct link at https://ec.europa.eu/transport/sites/transport/files/c-its_certificate_policy_release_1.pdf). 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 OEMs and national road authorities to create root CAs and have them trusted. In the US, the US Department of Transportation (USDOT) published a proposed regulation, which at the time of writing is active though not rapidly progressing, which would have required all light vehicles in the US to implement V2X communications including the use of C-ITS certificates (available from https://www.federalregister.gov/documents/2017/01/12/2016-31059/federal-motor-vehicle-safety-standards-v2v-communications). As of 2019, ITS deployments across the US, Europe and Australia were using C-ITS certificates. Volkswagen have committed to deploying V2X next year using C-ITS certificates. New York, Tampa and Wyoming are deploying traffic management systems using C-ITS certificates. GM deployed V2X in their Cadillac CTSes using C-ITS certificates. C-ITS certificates are also used in a number of standards that build on top of the foundational IEEE and ETSI standards, particularly the 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.
This document describes an experimental extension of TLS security model. We are using a form of certificate that has not traditionally been used in the Internet. Systems using this Experimental approach are segregated from system using standard TLS by the use of a new Certificate Type value, reserved through IANA. The implementation of TLS is not involved in the Experiment and it will not be able to interact with an Experimental implementation. This extension has been encouraged by stakeholders in the Cooperative ITS community in order to support the C-ITS use cases deployment and it is anticipated that its use will be widespread.
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 [RFC2119] [RFC8174]when, and only when, they appear in all capitals, as shown here.
/* 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 5246*/
case X.509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
For TLS 1.2[RFC5246], the "extension_data" field SHALL follow the [RFC7250]. In case of TLS 1.3, the "extension_data" field SHALL contain a list of supported certificate types proposed by the client as provided in the figure below:
In case where the TLS server accepts the described extension, it selects one of the certificate types. Note that a server MAY authenticate the client using other authentication methods.
Client Server
Key ^ ClientHello
Exch | + server_certificate_type*
| + client_certificate_type*
| + key_share*
v + signature_algorithms* -------->
ServerHello ^ Key
+ key_share* v Exch
{EncryptedExtensions} ^ Server
{+ server_certificate_type*}| Params
{+ client_certificate_type*}|
{CertificateRequest*} v
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the
previously noted message.
* Indicates optional or situation-dependent
messages/extensions that are not always sent.
{} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys
derived from [sender]_application_traffic_secret_N.
Figure 1: Message Flow with certificate type extension for Full TLS 1.3 Handshake
The "client_certificate_type" and "server_certificate_type" extensions MUST be sent in handshake phase as illustrated in figure 1 below.
In case of TLS 1.3 and in order to negotiate the support of IEEE 1609.2 or ETSI TS 103097 certificate-based authentication, the clients and the servers MAY include the extension of type "client_certificate_type" and "server_certificate_type" in the extended Client Hello and "EncryptedExtensions". In case of TLS 1.2, used extensions are in Client Hello and Server Hello.
In order to indicate the support of IEEE 1609.2 or ETSI TS 103097 certificates, client MUST include an extension of type "client_certificate_type" or "server_certificate_type" in the extended Client Hello message as described in Section 4.1.2 of TLS 1.3 [RFC8446].
The extension 'client_certificate_type' sent in the Client Hello MAY carry a list of supported certificate types, sorted by client preference. It is a list in the case where the client supports multiple certificate types.
In both TLS 1.2 and 1.3, the rules if client Certificate and CertificateVerify messages appear is as follows:
All implementations SHOULD be prepared to handle extraneous certificates and arbitrary orderings from any TLS version, with the exception of the end-entity certificate which MUST be first.
When the server receives the Client Hello containing the client_certificate_type extension and/or the server_certificate_type extension, the following options are possible:
The TLS client or server public keys can be obtained from an online repository. In fact, the repository is used to retrive the certificate chain. All PKI requests and responses are indicated in ETSI[ETSI102941].
Verification of an IEEE 1609.2/ ETSI TS 103097 certificates or certificate chain is described in section 5.1 of [IEEE1609.2]. In the case of TLS 1.3 and when the certificate_type is 1609Dot2, the CertificateVerify contents and processing are different than for the CertificateVerify message specified for other values of certificate_type in [RFC8446]. In this case, the CertificateVerify message contains a Canonical Octet Encoding Rules [ITU-TX.696] -encoded IEEE1609Dot2Data of type signed as specified in [IEEE1609.2], [IEEE1609.2b], where:
All other fields in the headerInfo are omitted. The certificate appPermissions field shall be present and shall permit (as defined in IEEE1609.2) 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 [IEEE1609.2] 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 IEEE 1609.2) 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 message input to the signature calculation is the usual message input for TLS 1.3, as specified in [RFC8446] section 4.4.3, consisting of pad, context string, separator and content, where content is Transcript- Hash(Handshake Context, Certificate).
The signature and verification are carried out as specified in [IEEE1609.2].
The message input to the signature calculation is the usual message input for TLS 1.3, as specified in [RFC8446] section 4.4.3, consisting of pad, context string, separator and content, where content is Transcript- Hash(Handshake Context, Certificate).
The signature and verification are carried out as specified in [IEEE1609.2].
Some of exchanged messages examples are illustrated in Figures 2 and 3.
Client Server
ClientHello,
client_certificate_type=1609Dot2,
server_certificate_type=1609Dot2, --------> ServerHello,
{EncryptedExtensions}
{client_certificate_type=1609Dot2}
{server_certificate_type=1609Dot2}
{CertificateRequest}
{Certificate}
{CertificateVerify}
{Finished}
{Certificate} <------- [Application Data]
{CertificateVerify}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 2: TLS Client and TLS Server use the IEEE 1609.2 certificate
This section shows an example where the TLS client as well as the TLS server use the IEEE 1609.2 certificate. In consequence, both the server and the client populate the client_certificate_type and server_certificate_type with extension IEEE 1609.2 certificates as mentioned in figure 2.
Client Server
ClientHello,
client_certificate_type=(1609Dot2),
server_certificate_type=(1609Dot2,
X509,RawPublicKey), -----------> ServerHello,
{EncryptedExtensions}
{client_certificate_type=1609Dot2}
{server_certificate_type=X509}
{Certificate}
{CertificateVerify}
{Finished}
<--------- [Application Data]
{Finished} --------->
[Application Data] <--------> [Application Data]
Figure 3: TLS Client uses the IEEE 1609.2 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 figure 3. the client indicates its ability to receive and to validate an X.509 certificate from the server. The server chooses the X.509 certificate to make its authentication with the Client.
This section provides an overview of the basic security considerations which need to be taken into account before implementing the necessary security mechanisms. The security considerations described throughout [RFC8446] regarding the supported groups and signature algorithms apply here as well.
The certificates used to establish a secure connection may be obtained from an online repository in particular, 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[ETSI102941] provides a mechanism that can be used to securely obtain C-ITS certificates.
Conventions around certificate lifetime differ between C-ITS certificates and X.509 certificates, and in particular C-ITS certificates may be relatively short-lived compared with typical X.509 certificates. A party to a TLS session that accepts C-ITS certificates MUST check the expiry time in the received C-ITS certificate and SHOULD terminate a session when the certificate received in the handshake expires. We can consider the TLS renegotiation as specified in [RFC8446] and [RFC5246], but an implementation of proposed extension could favor terminating the session on expiry of the the certificate.
All C-ITS certificates use public-key cryptographic algorithms with an estimated strength of at least 128 bits 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.
C-ITS certificates in TLS express the certificate holders permissions using two fields: a Provider Service Identifier (PSID), also known as an ITS Application Identifier (ITS-AID), which identifies a broad set of application activities which provide a context for the certificate holders permissions, and a Service Specific Permissions (SSP) field associated with the 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 [SAEJ29453]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 [IEEE160912] and for more information about the development of SSPs, see [SAEJ29455]
The assumption in this document is that a party that accepts C-ITS certificates will do it in the context of an access control policy that states what PSIDs and SSPs are to be accepted in the handshake, and what activities are permitted within the session based on the PSIDs and SSPs presented in the handshake. [ISO21177] provides a generalization of this where additional certificates may be presented within the context of a TLS session to provide a more complete picture of the permissions of the counterparty within the session, allowing that counterparty to demonstrate its entitlement to a broader range of permissions than those indicated within the single certificate presented within the handshake. An implementation that accepts C-ITS certificates MUST do so in the context of an access policy of this type.
The CertificateVerify message for TLS 1.3 is an Ieee1609Dot2Data of type signed, signed using a C-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. A C-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. If the pduFunctionalType field is present and set equal to tlsHandshake, the message is a CertificateVerify and MUST NOT be interpreted as a directly signed message for the application.
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. For new application activities, PSIDs can be requested via IEEE or via ISO TC 204. In particular, note that there is currently no PSID associated to the extension, although such a PSID could be reserved in future if it were found to be useful.
For privacy considerations in a vehicular environment the use of IEEE 1609.2/ETSI TS 103097 certificate is recommended for many reasons:
IANA is requested to change the reference for the "1609Dot2" entry when RFC Editor notifies us that they've assigned an RFC number: https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml .
The authors wish to thank Eric Rescola , Russ Housley and Ilari Liusvaara for their feedback and suggestions on improving this document. Thanks are due to Sean Turner for his valuable and detailed comments. Special thanks to Panos Kampanakis, Jasja Tijink and Bill Lattin for their guidance and support of the draft.