idnits 2.17.1 draft-tls-certieee1609-02.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 9 characters in excess of 72. 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 (October 22, 2018) is 2011 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 ---------------------------------------------------------------------------- == Missing Reference: 'THIS RFC' is mentioned on line 357, but not defined == Unused Reference: 'RFC4492' is defined on line 379, 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: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TLS Working Group P. Kampanakis, Ed. 3 Internet-Draft Cisco 4 Intended status: Informational M. Msahli, Ed. 5 Expires: April 25, 2019 Telecom ParisTech 6 October 22, 2018 8 TLS Authentication using ETSI TS 103 097 and IEEE 1609.2 certificates 9 draft-tls-certieee1609-02.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 Institute of Electrical and Electronics 16 Engineers (IEEE) and the European Telecommunications Standards 17 Institute (ETSI). 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 25, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 55 3. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3 56 4. TLS Client and Server Handshake . . . . . . . . . . . . . . . 4 57 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 5 58 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 6 59 5. Certificate Verification . . . . . . . . . . . . . . . . . . 7 60 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate . 7 62 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS 63 Server uses the X 509 certificate . . . . . . . . . . . . 7 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 65 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 66 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 68 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 70 11.2. Informative References . . . . . . . . . . . . . . . . . 10 71 Appendix A. Co-Authors . . . . . . . . . . . . . . . . . . . . . 11 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 74 1. Introduction 76 The TLS protocol [RFC8446] [RFC5246] uses X509 and Raw Public Key in 77 order to authenticate servers and clients. This document describes 78 the use of certificates specified either by the Institute of 79 Electrical and Electronics Engineers (IEEE) [IEEE1609.2] or the 80 European Telecommunications Standards Institute (ETSI) [TS103097]. 81 It is worth mentioning that the ETSI TS 103097 certificate is a 82 profile of IEEE 1609.2 certificate and uses the same data structure. 83 These standards are defined in order to secure communications in 84 vehicular environments. Existing authentication methods, such as 85 X509 and Raw Public Key, are designed for Internet use, particularly 86 for flexibility and extensibility, and are not optimized for 87 bandwidth and processing time to support delay-sensitive 88 applications. That is why size-optimized certificates were 89 standardized by ETSI and IEEE to secure data exchange in highly 90 dynamic vehicular environment in Intelligent Transportation System 91 (ITS). 93 2. Requirements Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Extension Overview 101 This specification extends the Client Hello and Server Hello 102 messages, by using the "extension_data" field of the ClientCertType 103 Extension and the ServerCertType Extension structures defined in 104 RFC7250. In order to negotiate the support of IEEE 1609.2 or ETSI TS 105 103097 certificate-based authentication, the clients and the servers 106 MAY include the extension of type "client_certificate_type" and 107 "server_certificate_type" in the extended Client Hello and 108 "EncryptedExtensions". The "extension_data" field of this extension 109 SHALL contain a list of supported certificate types proposed by the 110 client as provided in the figure below: 112 /* Managed by IANA */ 113 enum { 114 X509(0), 115 RawPublicKey(2), 116 1609Dot2(?), /* Number 3 will be requested for 1609.2 */ 117 (255) 118 } CertificateType; 120 struct { 121 select (certificate_type) { 123 /* certificate type defined in this document.*/ 124 case 1609Dot2: 125 opaque cert_data<1..2^24-1>; 127 /* RawPublicKey defined in RFC 7250*/ 128 case RawPublicKey: 129 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 131 /* X.509 certificate defined in RFC 5246*/ 132 case X.509: 133 opaque cert_data<1..2^24-1>; 135 }; 137 Extension extensions<0..2^16-1>; 138 } CertificateEntry; 140 In case where the TLS server accepts the described extension, it 141 selects one of the certificate types in the extension described 142 above. Note that a server MAY authenticate the client using other 143 authentication methods. The end-entity certificate's public key has 144 to be compatible with one of the certificate types listed in the 145 extension described above. 147 4. TLS Client and Server Handshake 149 The "client_certificate_type" and "server_certificate_type" 150 extensions MUST be sent in handshake phase as illustrated in Figure 1 151 below. The same extension shall be sent in Server Hello for TLS 1.2. 153 Client Server 155 Key ^ ClientHello 156 Exch | + server_certificate_type* 157 | + client_certificate_type* 158 | + key_share* 159 v + signature_algorithms* --------> 160 ServerHello ^ Key 161 + key_share* v Exch 162 {EncryptedExtensions} ^ Server 163 {+ server_certificate_type*}| Params 164 {+ client_certificate_type*}| 165 {CertificateRequest*} v 166 {Certificate*} ^ 167 {CertificateVerify*} | Auth 168 {Finished} v 169 <------- [Application Data*] 170 ^ {Certificate*} 171 Auth | {CertificateVerify*} 172 v {Finished} --------> 173 [Application Data] <-------> [Application Data] 175 + Indicates noteworthy extensions sent in the 176 previously noted message. 178 * Indicates optional or situation-dependent 179 messages/extensions that are not always sent. 181 {} Indicates messages protected using keys 182 derived from a [sender]_handshake_traffic_secret. 184 [] Indicates messages protected using keys 185 derived from [sender]_application_traffic_secret_N. 187 Figure 1: Message Flow with certificate type extension for Full TLS 188 1.3 Handshake 190 4.1. Client Hello 192 In order to indicate the support of IEEE 1609.2 or ETSI TS 103097 193 certificates, client MUST include an extension of type 194 "client_certificate_type" and "server_certificate_type" in the 195 extended Client Hello message. The Hello extension is described in 196 Section 4.1.2 of TLS 1.3 [RFC8446]. 198 The extension 'client_certificate_type' sent in the client hello MAY 199 carry a list of supported certificate types, sorted by client 200 preference. It is a list in the case where the client supports 201 multiple certificate types. 203 Client MAY respond along with supported certificates by sending a 204 "Certificate" message immediately followed by the "CetificateVerify" 205 message. These specifications are valid for TLS 1.2 and TLS 1.3. 207 All implementations SHOULD be prepared to handle extraneous 208 certificates and arbitrary orderings from any TLS version, with the 209 exception of the end-entity certificate which MUST be first. 211 4.2. Server Hello 213 When the server receives the Client Hello containing the 214 client_certificate_type extension and/or the server_certificate_type 215 extension, the following options are possible: 217 - The server supports the extension described in this document. 218 It selects a certificate type from the client_certificate_type 219 field in the extended Client Hello and must take into account the 220 client authentication list priority. 222 - The server does not support the proposed certificate type and 223 terminates the session with a fatal alert of type 224 "unsupported_certificate". 226 - The server does not support the extension defined in this 227 document. In this case, the server returns the server hello 228 without the extensions defined in this document in case of TLS 229 1.2. 231 - The server supports the extension defined in this document, but 232 it does not have any certificate type in common with the client. 233 Then, the server terminates the session with a fatal alert of type 234 "unsupported_certificate". 236 - The server supports the extensions defined in this document and 237 has at least one certificate type in common with the client. In 238 this case, the server MUST include the client_certificate_type 239 extension in the Server Hello for TLS 1.2 or in Encrypted 240 Extension for TLS 1.3. Then, the server requests a certificate 241 from the client (via the certificate_request message) 243 It is worth to mention that the TLS client or server public keys are 244 obtained from a certificate chain from a web page. 246 5. Certificate Verification 248 Verification of an IEEE 1609.2/ ETSI TS 103097 certificates or 249 certificate chain is described in section 5.5.2 of [IEEE1609.2]. 251 6. Examples 253 Some of exchanged messages examples are illustrated in Figures 2 and 254 3. 256 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate 258 This section shows an example where the TLS client as well as the TLS 259 server use the IEEE 1609.2 certificate. In consequence, both the 260 server and the client populate the client_certificate_type and 261 server_certificate_type with extension IEEE 1609.2 certificates as 262 mentioned in figure 2. 264 Client Server 266 ClientHello, 267 client_certificate_type*=1609Dot2, 268 server_certificate_type*=1609Dot2, --------> ServerHello, 269 {EncryptedExtensions} 270 {client_certificate_type*=1609Dot2} 271 {server_certificate_type*=1609Dot2} 272 {CertificateRequest*} 273 {Certificate*} 274 {CertificateVerify*} 275 {Finished} 276 {Certificate*} <------- [Application Data*] 277 {CertificateVerify*} 278 {Finished} --------> 279 [Application Data] <-------> [Application Data] 281 Figure 2: TLS Client and TLS Server use the IEEE 1609.2 certificate 283 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS Server uses 284 the X 509 certificate 286 This example shows the TLS authentication, where the TLS Client 287 populates the server_certificate_type extension with the X509 288 certificate and Raw Public Key type as presented in figure 3. the 289 client indicates its ability to receive and to validate an X509 290 certificate from the server. The server chooses the X509 291 certificateto make its authentication with the Client. 293 Client Server 295 ClientHello, 296 client_certificate_type*=(1609Dot2), 297 server_certificate_type*=(1609.9Dot, X509,RawPublicKey), -------> ServerHello, 298 {EncryptedExtensions} 299 {client_certificate_type*=1609Dot2} 300 {server_certificate_type*=X509} 301 {Certificate*} 302 {CertificateVerify*} 303 {Finished} 304 <--------- [Application Data*] 305 {Finished} ---------> 306 [Application Data] <--------> [Application Data] 308 Figure 3: TLS Client uses the IEEE 1609.2 certificate and TLS Server 309 uses the X 509 certificate 311 7. Security Considerations 313 This section provides an overview of the basic security 314 considerations which need to be taken into account before 315 implementing the necessary security mechanisms. The security 316 considerations described throughout [RFC8446] and [RFC5246] apply 317 here as well. 319 For security considerations in a vehicular environment, the minimal 320 use of any TLS extensions is recommended such as : 322 The "client_certificate_type" [IANA value 19] extension who's 323 purpose was previously described in [RFC7250]. 325 The "server_certificate_type" [IANA value 20] extension who's 326 purpose was previously described in [RFC7250]. 328 The "SessionTicket" [IANA value 35] extension for session 329 resumption. 331 In addition, servers SHOULD not support renegotiation [RFC5746] 332 which presented Man-In-The-Middle (MITM) type attacks over the 333 past years for TLS 1.2. 335 8. Privacy Considerations 337 For privacy considerations in a vehicular environment the use of EEE 338 1609.2/ETSI TS 103097 certificate is recommended for many reasons: 340 In order to address the risk of a personal data leakage, messages 341 exchanged for V2V communications are signed using IEEE 1609.2/ETSI 342 TS 103097 pseudonym certificates 344 The purpose of these certificates is to provide privacy relying on 345 geographical and/or temporal validity criteria, and minimizing the 346 exchange of private data 348 9. IANA Considerations 350 Existing IANA references have not been updated yet to point to this 351 document. 353 IANA is asked to register a new value in the "TLS Certificate Types" 354 registry of Transport Layer Security (TLS) Extensions [TLS- 355 Certificate-Types-Registry], as follows: 357 o Value: TBD Description: 1609Dot2 Reference: [THIS RFC] 359 10. Acknowledgements 361 The authors wish to thank Eric Rescola and Ilari Liusvaara for their 362 feedback and suggestions on improving this document. Thanks are due 363 to Sean Turner for his valuable and detailed comments. Special 364 thanks to William Whyte and Maik Seewald for their guidance and 365 support in the early stages of the draft. 367 11. References 369 11.1. Normative References 371 [IEEE1609.2] 372 IEEE, "IEEE Standard for Wireless Access in Vehicular 373 Environments - Security Services for Applications and 374 Management Messages", 2016. 376 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", March 1997. 379 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 380 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 381 for Transport Layer Security (TLS)", May 2006. 383 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 384 (TLS) Protocol Version 1.2", August 2008. 386 [RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov, 387 "Transport Layer Security (TLS) Renegotiation Indication 388 Extension"", February 2010. 390 [RFC7250] Wouters, P., Tschofenig, H., Weiler, S., and T. Kivinen, 391 "Using Raw Public Keys in Transport Layer Security (TLS) 392 and Datagram Transport Layer Security (DTLS)", June 2014. 394 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 395 Version 1.3", August 2018. 397 [TS103097] 398 ETSI, "ETSI TS 103 097 v1.3.1 (2017-10): Intelligent 399 Transport Systems (ITS); Security; Security header and 400 certificate formats", October 2017. 402 11.2. Informative References 404 [draft-serhrouchni-tls-certieee1609-00] 405 KAISER, A., LABIOD, H., LONC, B., MSAHLI, M., and A. 406 SERHROUCHNI, "Transport Layer Security (TLS) 407 Authentication using ITS ETSI and IEEE certificates", 408 august 2017. 410 Appendix A. Co-Authors 412 o Nancy Cam-Winget 413 CISCO, USA 414 ncamwing@cisco.com 416 o Houda Labiod 417 Telecom Paristech, France 418 houda.labiod@telecom-paristech.fr 420 o Ahmed Serhrouchni 421 Telecom ParisTech 422 ahmed.serhrouchni@telecom-paristech.fr 424 Authors' Addresses 426 Panos Kampanakis (editor) 427 Cisco 428 USA 430 EMail: EMail: pkampana@cisco.com 432 Mounira Msahli (editor) 433 Telecom ParisTech 434 France 436 EMail: mounira.msahli@telecom-paristech.fr