Network Working Group M. Msahli, Ed. Internet-Draft Telecom ParisTech Intended status: Experimental N. Cam-Winget, Ed. Expires: January 23, 2020 Cisco July 22, 2019 TLS Authentication using IEEE 1609.2 certificates draft-msahli-ise-ieee1609-00 Abstract This document specifies the use of a new certificate type to authenticate TLS entities. The goal is to enable the use of a certificate specified by the IEEE and the European Telecommunications Standards Institute (ETSI). This specification defines an experimental change of TLS to support a new certificate type. Status of This Memo 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 January 23, 2020. Copyright Notice 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 Msahli & Cam-Winget Expires January 23, 2020 [Page 1] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Experiment Overview . . . . . . . . . . . . . . . . . . . 2 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 3. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3 4. TLS Client and Server Handshake . . . . . . . . . . . . . . . 4 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 6 5. Certificate Verification . . . . . . . . . . . . . . . . . . 7 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate . 8 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS Server uses the X.509 certificate . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The TLS protocol [RFC8446] uses X.509 and Raw Public Key in order to authenticate servers and clients. This document describes an experimental use of the certificate 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. 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 System (ITS). We define an experimental extension following the [RFC7250]. 1.1. Experiment Overview This document describes an experimental extension of TLS security model. We are using a form of certificate that has not traditionally been used in IETF works. Systems using this Experimental approach are segregated from system using standard TLS by the use of a new Msahli & Cam-Winget Expires January 23, 2020 [Page 2] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 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. In fact, an implementation of TLS can recognize that the Certificate Type value used in this document is unknown. This design has been requested by stakeholders in the Cooperative ITS community including ISO internationally, and SAE in the US and ETSI in EU , in order to support the deployment of a number of use cases in cooperative ITS and it is anticipated that its use will be widespread. There is no IPR that needs to be disclosed by the authors or contributors under the IETF's rules set out in BCP 78 and BCP 79. 2. 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 [RFC2119] [RFC8174]when, and only when, they appear in all capitals, as shown here. 3. Extension Overview 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: Msahli & Cam-Winget Expires January 23, 2020 [Page 3] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 /* 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; 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. The end- entity certificate's public key MUST be compatible with one of the certificate types listed in the extension described above. 4. TLS Client and Server Handshake The "client_certificate_type" and "server_certificate_type" extensions MUST be sent in handshake phase as illustrated in figure 1 below. Msahli & Cam-Winget Expires January 23, 2020 [Page 4] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 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 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. Msahli & Cam-Winget Expires January 23, 2020 [Page 5] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 4.1. Client 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" and "server_certificate_type" in the extended Client Hello message. The Hello extension is 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: - Client Certificate message is present if and only if server sent a CertificateRequest message. - Client CertificateVerify message is present if and only if the Client Certificate message is present and contains non-empty certificate list. 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. 4.2. Server Hello 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 server supports the extension described in this document. It selects a certificate type from the client_certificate_type field in the extended Client Hello and SHALL take into account the client authentication list priority. - The server does not support any of the proposed certificate type and terminates the session with a fatal alert of type "unsupported_certificate". - The server does not support the extension defined in this document. In this case, the server returns the server hello without the extensions defined in this document. - The server supports the extension defined in this document, but it does not have any certificate type in common with the client. Msahli & Cam-Winget Expires January 23, 2020 [Page 6] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 Then, the server terminates the session with a fatal alert of type "unsupported_certificate". - The server supports the extensions defined in this document and has at least one certificate type in common with the client. In this case, the server MAY include the client_certificate_type extension in the Server Hello for TLS 1.2 or in Encrypted Extension for TLS 1.3. Then, the server requests a certificate from the client (via the certificate_request message) It is worth to mention that the TLS client or server public keys are obtained from an online repository. 5. Certificate Verification 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 (COER)-encoded Ieee1609Dot2Data of type signed as specified in [IEEE1609.2], [IEEE1609.2b], where: payload contains an extDataHash containing the SHA-256 hash of the data the signature is calculated over. This is identical to the data the signature is calculated over in standard TLS, which is reproduced below for clarity. psid indicates the application activity that the certificate is authorizing. generationTime is the current time. pduFunctionalType (as specified in [IEEE1609.2b]) is present and is set equal to tlsHandshake (1). All other fields in the headerInfo are omitted. 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]. Msahli & Cam-Winget Expires January 23, 2020 [Page 7] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 6. Examples Some of exchanged messages examples are illustrated in Figures 2 and 3. 6.1. TLS Server and TLS Client use the 1609Dot2 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, --------> 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 6.2. 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. Msahli & Cam-Winget Expires January 23, 2020 [Page 8] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 Client Server ClientHello, client_certificate_type*=(1609Dot2), server_certificate_type*=(1609.9Dot, 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 7. Security Considerations 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. TLS extensions to be considered are: The "client_certificate_type" [IANA value 19] extension who's purpose was previously described in [RFC7250]. The "server_certificate_type" [IANA value 20] extension who's purpose was previously described in [RFC7250]. 8. Privacy Considerations For privacy considerations in a vehicular environment the use of IEEE 1609.2/ETSI TS 103097 certificate is recommended for many reasons: In order to address the risk of a personal data leakage, messages exchanged for V2V communications are signed using IEEE 1609.2/ETSI TS 103097 pseudonym certificates The purpose of these certificates is to provide privacy relying on geographical and/or temporal validity criteria, and minimizing the exchange of private data Msahli & Cam-Winget Expires January 23, 2020 [Page 9] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 9. IANA Considerations IANA is requested to update the registry to reference the RFC. Existing IANA references have not been updated yet to point to this document. 10. Acknowledgements The authors wish to thank Eric Rescola 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 Maik Seewald for their guidance and support of the draft. 11. References 11.1. Normative References [IEEE1609.2] "IEEE Standard for Wireless Access in Vehicular Environments - Security Services for Applications and Management Messages", 2016. [IEEE1609.2b] "IEEE Standard for Wireless Access in Vehicular Environments--Security Services for Applications and Management Messages - Amendment 2--PDU Functional Types and Encryption Key Management", 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", August 2008. [RFC7250] Wouters, P., Tschofenig, H., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", June 2014. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", May 2017. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018. Msahli & Cam-Winget Expires January 23, 2020 [Page 10] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 [TS103097] "ETSI TS 103 097 : Intelligent Transport Systems (ITS); Security; Security header and certificate formats". 11.2. Informative References [draft-serhrouchni-tls-certieee1609-00] KAISER, A., LABIOD, H., LONC, B., MSAHLI, M., and A. SERHROUCHNI, "Transport Layer Security (TLS) Authentication using ITS ETSI and IEEE certificates", august 2017. Msahli & Cam-Winget Expires January 23, 2020 [Page 11] Internet-Draft IEEE and ETSI Certificate Types for TLS July 2019 Appendix A. Contributors o Houda Labiod Telecom ParisTech houda.labiod@telecom-paristech.fr o Ahmed Serhrouchni Telecom ParisTech ahmed.serhrouchni@telecom-paristech.fr o William Whyte Onboard Security wwhyte@onboardsecurity.com Authors' Addresses Mounira Msahli (editor) Telecom ParisTech France EMail: mounira.msahli@telecom-paristech.fr Nancy Cam-Winget (editor) Cisco USA EMail: ncamwing@cisco.com Msahli & Cam-Winget Expires January 23, 2020 [Page 12]