idnits 2.17.1 draft-msahli-ipwave-ieee1609-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In addition, servers SHOULD not support renegotiation [RFC5746] which presented Man-In-The-Middle (MITM) type attacks over the past years for TLS 1.2. -- The document date (March 29, 2019) is 1855 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'IEEE1609.2b' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC4492' is defined on line 383, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPWAVE Working Group M. Msahli, Ed. 3 Internet-Draft Telecom ParisTech 4 Intended status: Informational P. Kampanakis, Ed. 5 Expires: September 30, 2019 Cisco 6 March 29, 2019 8 TLS Authentication using IEEE 1609.2 certificates 9 draft-msahli-ipwave-ieee1609-00.txt 11 Abstract 13 This document specifies the use of a new certificate type to 14 authenticate TLS entities. The first type enables the use of a 15 certificate specified by the IEEE and the European Telecommunications 16 Standards Institute (ETSI). 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 30, 2019. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 2 54 3. Extension Overview . . . . . . . . . . . . . . . . . . . . . 2 55 4. TLS Client and Server Handshake . . . . . . . . . . . . . . . 4 56 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Certificate Verification . . . . . . . . . . . . . . . . . . 6 59 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate . 6 61 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS 62 Server uses the X 509 certificate . . . . . . . . . . . . 7 63 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 64 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 65 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 67 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 69 11.2. Informative References . . . . . . . . . . . . . . . . . 10 70 Appendix A. Co-Authors . . . . . . . . . . . . . . . . . . . . . 11 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 73 1. Introduction 75 The TLS protocol [RFC8446] [RFC5246] uses X509 and Raw Public Key in 76 order to authenticate servers and clients. This document describes 77 the use of the certificate specified by the IEEE in [IEEE1609.2] and 78 profiled by the European Telecommunications Standards Institute 79 (ETSI) in [TS103097]. These standards specify secure communications 80 in vehicular environments. The certificate types are optimized for 81 bandwidth and processing time to support delay-sensitive 82 applications, and also provide both authentication and authorization 83 information to enable fast access control decisions in ad hoc 84 networks such as are found in Intelligent Transportation System 85 (ITS). The extension is following the [RFC6066]. 87 2. Requirements Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Extension Overview 95 This specification extends the Client Hello and Server Hello 96 messages, by using the "extension_data" field of the ClientCertType 97 Extension and the ServerCertType Extension structures defined in 98 RFC7250. In order to negotiate the support of IEEE 1609.2 or ETSI TS 99 103097 certificate-based authentication, the clients and the servers 100 MAY include the extension of type "client_certificate_type" and 101 "server_certificate_type" in the extended Client Hello and 102 "EncryptedExtensions". The "extension_data" field of this extension 103 SHALL contain a list of supported certificate types proposed by the 104 client as provided in the figure below: 106 /* Managed by IANA */ 107 enum { 108 X509(0), 109 RawPublicKey(2), 110 1609Dot2(3), 111 (255) 112 } CertificateType; 114 struct { 115 select (certificate_type) { 117 /* certificate type defined in this document.*/ 118 case 1609Dot2: 119 opaque cert_data<1..2^24-1>; 121 /* RawPublicKey defined in RFC 7250*/ 122 case RawPublicKey: 123 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 125 /* X.509 certificate defined in RFC 5246*/ 126 case X.509: 127 opaque cert_data<1..2^24-1>; 129 }; 131 Extension extensions<0..2^16-1>; 132 } CertificateEntry; 134 In case where the TLS server accepts the described extension, it 135 selects one of the certificate types in the extension described 136 above. Note that a server MAY authenticate the client using other 137 authentication methods. The end-entity certificate's public key has 138 to be compatible with one of the certificate types listed in the 139 extension described above. 141 4. TLS Client and Server Handshake 143 The "client_certificate_type" and "server_certificate_type" 144 extensions MUST be sent in handshake phase as illustrated in Figure 1 145 below. The same extension shall be sent in Server Hello for TLS 1.2. 147 Client Server 149 Key ^ ClientHello 150 Exch | + server_certificate_type* 151 | + client_certificate_type* 152 | + key_share* 153 v + signature_algorithms* --------> 154 ServerHello ^ Key 155 + key_share* v Exch 156 {EncryptedExtensions} ^ Server 157 {+ server_certificate_type*}| Params 158 {+ client_certificate_type*}| 159 {CertificateRequest*} v 160 {Certificate*} ^ 161 {CertificateVerify*} | Auth 162 {Finished} v 163 <------- [Application Data*] 164 ^ {Certificate*} 165 Auth | {CertificateVerify*} 166 v {Finished} --------> 167 [Application Data] <-------> [Application Data] 169 + Indicates noteworthy extensions sent in the 170 previously noted message. 172 * Indicates optional or situation-dependent 173 messages/extensions that are not always sent. 175 {} Indicates messages protected using keys 176 derived from a [sender]_handshake_traffic_secret. 178 [] Indicates messages protected using keys 179 derived from [sender]_application_traffic_secret_N. 181 Figure 1: Message Flow with certificate type extension for Full TLS 182 1.3 Handshake 184 4.1. Client Hello 186 In order to indicate the support of IEEE 1609.2 or ETSI TS 103097 187 certificates, client MUST include an extension of type 188 "client_certificate_type" and "server_certificate_type" in the 189 extended Client Hello message. The Hello extension is described in 190 Section 4.1.2 of TLS 1.3 [RFC8446]. 192 The extension 'client_certificate_type' sent in the client hello MAY 193 carry a list of supported certificate types, sorted by client 194 preference. It is a list in the case where the client supports 195 multiple certificate types. 197 Client MAY respond along with supported certificates by sending a 198 "Certificate" message immediately followed by the "CetificateVerify" 199 message. These specifications are valid for TLS 1.2 and TLS 1.3. 201 All implementations SHOULD be prepared to handle extraneous 202 certificates and arbitrary orderings from any TLS version, with the 203 exception of the end-entity certificate which MUST be first. 205 4.2. Server Hello 207 When the server receives the Client Hello containing the 208 client_certificate_type extension and/or the server_certificate_type 209 extension, the following options are possible: 211 - The server supports the extension described in this document. 212 It selects a certificate type from the client_certificate_type 213 field in the extended Client Hello and must take into account the 214 client authentication list priority. 216 - The server does not support the proposed certificate type and 217 terminates the session with a fatal alert of type 218 "unsupported_certificate". 220 - The server does not support the extension defined in this 221 document. In this case, the server returns the server hello 222 without the extensions defined in this document. 224 - The server supports the extension defined in this document, but 225 it does not have any certificate type in common with the client. 226 Then, the server terminates the session with a fatal alert of type 227 "unsupported_certificate". 229 - The server supports the extensions defined in this document and 230 has at least one certificate type in common with the client. In 231 this case, the server MAY include the client_certificate_type 232 extension in the Server Hello for TLS 1.2 or in Encrypted 233 Extension for TLS 1.3. Then, the server requests a certificate 234 from the client (via the certificate_request message) 236 It is worth to mention that the TLS client or server public keys are 237 obtained from a certificate chain from a web page. 239 5. Certificate Verification 241 Verification of an IEEE 1609.2/ ETSI TS 103097 certificates or 242 certificate chain is described in section 5.5.2 of [IEEE1609.2]. In 243 the case where the certificate_type is 1609Dot2, the 244 CertificateVerify message does not contain a raw signature but 245 instead contains a Canonical Octet Encoding Rules (COER)-encoded 246 Ieee1609Dot2Data of type signed as specified in [1609.2b], with the 247 pduFunctionalType field present and set to tlsHandshake. A full 248 specification of the contents of this Ieee1609Dot2Data, including 249 optional fields, is given in [1609.2b]. The message input to the 250 signature calculation is the usual message input for TLS 1.3, as 251 specified in [RFC8446] section 4.4.3, consisting of pad, context 252 string, separator and content, where content is Transcript- 253 Hash(Handshake Context, Certificate). 255 6. Examples 257 Some of exchanged messages examples are illustrated in Figures 2 and 258 3. 260 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate 262 This section shows an example where the TLS client as well as the TLS 263 server use the IEEE 1609.2 certificate. In consequence, both the 264 server and the client populate the client_certificate_type and 265 server_certificate_type with extension IEEE 1609.2 certificates as 266 mentioned in figure 2. 268 Client Server 270 ClientHello, 271 client_certificate_type*=1609Dot2, 272 server_certificate_type*=1609Dot2, --------> ServerHello, 273 {EncryptedExtensions} 274 {client_certificate_type*=1609Dot2} 275 {server_certificate_type*=1609Dot2} 276 {CertificateRequest*} 277 {Certificate*} 278 {CertificateVerify*} 279 {Finished} 280 {Certificate*} <------- [Application Data*] 281 {CertificateVerify*} 282 {Finished} --------> 283 [Application Data] <-------> [Application Data] 285 Figure 2: TLS Client and TLS Server use the IEEE 1609.2 certificate 287 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS Server uses 288 the X 509 certificate 290 This example shows the TLS authentication, where the TLS Client 291 populates the server_certificate_type extension with the X509 292 certificate and Raw Public Key type as presented in figure 3. the 293 client indicates its ability to receive and to validate an X509 294 certificate from the server. The server chooses the X509 295 certificateto make its authentication with the Client. 297 Client Server 299 ClientHello, 300 client_certificate_type*=(1609Dot2), 301 server_certificate_type*=(1609.9Dot, 302 X509,RawPublicKey), -----------> ServerHello, 303 {EncryptedExtensions} 304 {client_certificate_type*=1609Dot2} 305 {server_certificate_type*=X509} 306 {Certificate*} 307 {CertificateVerify*} 308 {Finished} 309 <--------- [Application Data*] 310 {Finished} ---------> 311 [Application Data] <--------> [Application Data] 313 Figure 3: TLS Client uses the IEEE 1609.2 certificate and TLS Server 314 uses the X 509 certificate 316 7. Security Considerations 318 This section provides an overview of the basic security 319 considerations which need to be taken into account before 320 implementing the necessary security mechanisms. The security 321 considerations described throughout [RFC8446] and [RFC5246] apply 322 here as well. 324 For security considerations in a vehicular environment, the minimal 325 use of any TLS extensions is recommended such as : 327 The "client_certificate_type" [IANA value 19] extension who's 328 purpose was previously described in [RFC7250]. 330 The "server_certificate_type" [IANA value 20] extension who's 331 purpose was previously described in [RFC7250]. 333 The "SessionTicket" [IANA value 35] extension for session 334 resumption. 336 In addition, servers SHOULD not support renegotiation [RFC5746] 337 which presented Man-In-The-Middle (MITM) type attacks over the 338 past years for TLS 1.2. 340 8. Privacy Considerations 342 For privacy considerations in a vehicular environment the use of EEE 343 1609.2/ETSI TS 103097 certificate is recommended for many reasons: 345 In order to address the risk of a personal data leakage, messages 346 exchanged for V2V communications are signed using IEEE 1609.2/ETSI 347 TS 103097 pseudonym certificates 349 The purpose of these certificates is to provide privacy relying on 350 geographical and/or temporal validity criteria, and minimizing the 351 exchange of private data 353 9. IANA Considerations 355 Existing IANA references have not been updated yet to point to this 356 document. 358 10. Acknowledgements 360 The authors wish to thank Eric Rescola and Ilari Liusvaara for their 361 feedback and suggestions on improving this document. Thanks are due 362 to Sean Turner for his valuable and detailed comments. Special 363 thanks to Maik Seewald for their guidance and support in the early 364 stages of the draft. 366 11. References 368 11.1. Normative References 370 [IEEE1609.2] 371 "IEEE Standard for Wireless Access in Vehicular 372 Environments - Security Services for Applications and 373 Management Messages", 2016. 375 [IEEE1609.2b] 376 "Draft Standard for Wireless Access in Vehicular 377 Environments Security Services for Applications and for 378 Management Messages", 2018. 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", March 1997. 383 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 384 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 385 for Transport Layer Security (TLS)", May 2006. 387 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 388 (TLS) Protocol Version 1.2", August 2008. 390 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 391 "Transport Layer Security (TLS) Renegotiation Indication 392 Extension"", February 2010. 394 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 395 Extension Definitions", January 2011. 397 [RFC7250] Wouters, P., Tschofenig, H., Weiler, S., and T. Kivinen, 398 "Using Raw Public Keys in Transport Layer Security (TLS) 399 and Datagram Transport Layer Security (DTLS)", June 2014. 401 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 402 Version 1.3", August 2018. 404 [TS103097] 405 "ETSI TS 103 097 v1.3.1 (2017-10): Intelligent Transport 406 Systems (ITS); Security; Security header and certificate 407 formats", October 2017. 409 11.2. Informative References 411 [draft-serhrouchni-tls-certieee1609-00] 412 KAISER, A., LABIOD, H., LONC, B., MSAHLI, M., and A. 413 SERHROUCHNI, "Transport Layer Security (TLS) 414 Authentication using ITS ETSI and IEEE certificates", 415 august 2017. 417 Appendix A. Co-Authors 419 o Houda Labiod 420 Telecom ParisTech 421 houda.labiod@telecom-paristech.fr 423 o Nancy Cam-Winget 424 CISCO, USA 425 ncamwing@cisco.com 427 o Ahmed Serhrouchni 428 Telecom ParisTech 429 ahmed.serhrouchni@telecom-paristech.fr 431 o William Whyte 432 Onboard Security 433 wwhyte@onboardsecurity.com 435 Authors' Addresses 437 Mounira Msahli (editor) 438 Telecom ParisTech 439 France 441 EMail: mounira.msahli@telecom-paristech.fr 443 Panos Kampanakis (editor) 444 Cisco 445 USA 447 EMail: pkampana@cisco.com