idnits 2.17.1 draft-msahli-ise-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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 22, 2019) is 1711 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: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Duplicate reference: RFC2119, mentioned in 'RFC8174', was also mentioned in 'RFC2119'. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Msahli, Ed. 3 Internet-Draft Telecom ParisTech 4 Intended status: Experimental N. Cam-Winget, Ed. 5 Expires: January 23, 2020 Cisco 6 July 22, 2019 8 TLS Authentication using IEEE 1609.2 certificates 9 draft-msahli-ise-ieee1609-00 11 Abstract 13 This document specifies the use of a new certificate type to 14 authenticate TLS entities. The goal is to enable the use of a 15 certificate specified by the IEEE and the European Telecommunications 16 Standards Institute (ETSI). This specification defines an 17 experimental change of TLS to support a new certificate type. 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 January 23, 2020. 36 Copyright Notice 38 Copyright (c) 2019 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 1.1. Experiment Overview . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 56 3. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3 57 4. TLS Client and Server Handshake . . . . . . . . . . . . . . . 4 58 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 6 59 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Certificate Verification . . . . . . . . . . . . . . . . . . 7 61 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate . 8 63 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS 64 Server uses the X.509 certificate . . . . . . . . . . . . 8 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 69 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 11.2. Informative References . . . . . . . . . . . . . . . . . 11 72 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 The TLS protocol [RFC8446] uses X.509 and Raw Public Key in order to 78 authenticate servers and clients. This document describes an 79 experimental use of the certificate specified by the IEEE in 80 [IEEE1609.2] and profiled by the European Telecommunications 81 Standards Institute (ETSI) in [TS103097]. These standards specify 82 secure communications in vehicular environments. The certificate 83 types are optimized for bandwidth and processing time to support 84 delay-sensitive applications, and also to provide both authentication 85 and authorization information to enable fast access control decisions 86 in ad hoc networks such as are found in Intelligent Transportation 87 System (ITS). We define an experimental extension following the 88 [RFC7250]. 90 1.1. Experiment Overview 92 This document describes an experimental extension of TLS security 93 model. We are using a form of certificate that has not traditionally 94 been used in IETF works. Systems using this Experimental approach 95 are segregated from system using standard TLS by the use of a new 96 Certificate Type value, reserved through IANA. The implementation of 97 TLS is not involved in the Experiment and it will not be able to 98 interact with an Experimental implementation. In fact, an 99 implementation of TLS can recognize that the Certificate Type value 100 used in this document is unknown. This design has been requested by 101 stakeholders in the Cooperative ITS community including ISO 102 internationally, and SAE in the US and ETSI in EU , in order to 103 support the deployment of a number of use cases in cooperative ITS 104 and it is anticipated that its use will be widespread. 106 There is no IPR that needs to be disclosed by the authors or 107 contributors under the IETF's rules set out in BCP 78 and BCP 79. 109 2. Requirements Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described in BCP 114 14 [RFC2119] [RFC8174]when, and only when, they appear in all 115 capitals, as shown here. 117 3. Extension Overview 119 For TLS 1.2[RFC5246], the "extension_data" field SHALL follow the 120 [RFC7250]. In case of TLS 1.3, the "extension_data" field SHALL 121 contain a list of supported certificate types proposed by the client 122 as provided in the figure below: 124 /* Managed by IANA */ 125 enum { 126 X509(0), 127 RawPublicKey(2), 128 1609Dot2(3), 129 (255) 130 } CertificateType; 132 struct { 133 select (certificate_type) { 135 /* certificate type defined in this document.*/ 136 case 1609Dot2: 137 opaque cert_data<1..2^24-1>; 139 /* RawPublicKey defined in RFC 7250*/ 140 case RawPublicKey: 141 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 143 /* X.509 certificate defined in RFC 5246*/ 144 case X.509: 145 opaque cert_data<1..2^24-1>; 147 }; 149 Extension extensions<0..2^16-1>; 150 } CertificateEntry; 152 In case where the TLS server accepts the described extension, it 153 selects one of the certificate types. Note that a server MAY 154 authenticate the client using other authentication methods. The end- 155 entity certificate's public key MUST be compatible with one of the 156 certificate types listed in the extension described above. 158 4. TLS Client and Server Handshake 160 The "client_certificate_type" and "server_certificate_type" 161 extensions MUST be sent in handshake phase as illustrated in figure 1 162 below. 164 Client Server 166 Key ^ ClientHello 167 Exch | + server_certificate_type* 168 | + client_certificate_type* 169 | + key_share* 170 v + signature_algorithms* --------> 171 ServerHello ^ Key 172 + key_share* v Exch 173 {EncryptedExtensions} ^ Server 174 {+ server_certificate_type*}| Params 175 {+ client_certificate_type*}| 176 {CertificateRequest*} v 177 {Certificate*} ^ 178 {CertificateVerify*} | Auth 179 {Finished} v 180 <------- [Application Data*] 181 ^ {Certificate*} 182 Auth | {CertificateVerify*} 183 v {Finished} --------> 184 [Application Data] <-------> [Application Data] 186 + Indicates noteworthy extensions sent in the 187 previously noted message. 189 * Indicates optional or situation-dependent 190 messages/extensions that are not always sent. 192 {} Indicates messages protected using keys 193 derived from a [sender]_handshake_traffic_secret. 195 [] Indicates messages protected using keys 196 derived from [sender]_application_traffic_secret_N. 198 Figure 1: Message Flow with certificate type extension for Full TLS 199 1.3 Handshake 201 In case of TLS 1.3 and in order to negotiate the support of IEEE 202 1609.2 or ETSI TS 103097 certificate-based authentication, the 203 clients and the servers MAY include the extension of type 204 "client_certificate_type" and "server_certificate_type" in the 205 extended Client Hello and "EncryptedExtensions". In case of TLS 1.2, 206 used extensions are in Client Hello and Server Hello. 208 4.1. Client Hello 210 In order to indicate the support of IEEE 1609.2 or ETSI TS 103097 211 certificates, client MUST include an extension of type 212 "client_certificate_type" and "server_certificate_type" in the 213 extended Client Hello message. The Hello extension is described in 214 Section 4.1.2 of TLS 1.3 [RFC8446]. 216 The extension 'client_certificate_type' sent in the client hello MAY 217 carry a list of supported certificate types, sorted by client 218 preference. It is a list in the case where the client supports 219 multiple certificate types. 221 In both TLS 1.2 and 1.3, the rules if client Certificate and 222 CertificateVerify messages appear is as follows: 224 - Client Certificate message is present if and only if server sent 225 a CertificateRequest message. 227 - Client CertificateVerify message is present if and only if the 228 Client Certificate message is present and contains non-empty 229 certificate list. 231 All implementations SHOULD be prepared to handle extraneous 232 certificates and arbitrary orderings from any TLS version, with the 233 exception of the end-entity certificate which MUST be first. 235 4.2. Server Hello 237 When the server receives the Client Hello containing the 238 client_certificate_type extension and/or the server_certificate_type 239 extension, the following options are possible: 241 - The server supports the extension described in this document. 242 It selects a certificate type from the client_certificate_type 243 field in the extended Client Hello and SHALL take into account the 244 client authentication list priority. 246 - The server does not support any of the proposed certificate type 247 and terminates the session with a fatal alert of type 248 "unsupported_certificate". 250 - The server does not support the extension defined in this 251 document. In this case, the server returns the server hello 252 without the extensions defined in this document. 254 - The server supports the extension defined in this document, but 255 it does not have any certificate type in common with the client. 257 Then, the server terminates the session with a fatal alert of type 258 "unsupported_certificate". 260 - The server supports the extensions defined in this document and 261 has at least one certificate type in common with the client. In 262 this case, the server MAY include the client_certificate_type 263 extension in the Server Hello for TLS 1.2 or in Encrypted 264 Extension for TLS 1.3. Then, the server requests a certificate 265 from the client (via the certificate_request message) 267 It is worth to mention that the TLS client or server public keys are 268 obtained from an online repository. 270 5. Certificate Verification 272 Verification of an IEEE 1609.2/ ETSI TS 103097 certificates or 273 certificate chain is described in section 5.1 of [IEEE1609.2]. In 274 the case of TLS 1.3 and when the certificate_type is 1609Dot2, the 275 CertificateVerify contents and processing are different than for the 276 CertificateVerify message specified for other values of 277 certificate_type in [RFC8446]. In this case, the CertificateVerify 278 message contains a Canonical Octet Encoding Rules (COER)-encoded 279 Ieee1609Dot2Data of type signed as specified in [IEEE1609.2], 280 [IEEE1609.2b], where: 282 payload contains an extDataHash containing the SHA-256 hash of the 283 data the signature is calculated over. This is identical to the 284 data the signature is calculated over in standard TLS, which is 285 reproduced below for clarity. 287 psid indicates the application activity that the certificate is 288 authorizing. 290 generationTime is the current time. 292 pduFunctionalType (as specified in [IEEE1609.2b]) is present and 293 is set equal to tlsHandshake (1). 295 All other fields in the headerInfo are omitted. 297 The message input to the signature calculation is the usual message 298 input for TLS 1.3, as specified in [RFC8446] section 4.4.3, 299 consisting of pad, context string, separator and content, where 300 content is Transcript- Hash(Handshake Context, Certificate). 302 The signature and verification are carried out as specified in 303 [IEEE1609.2]. 305 6. Examples 307 Some of exchanged messages examples are illustrated in Figures 2 and 308 3. 310 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate 312 This section shows an example where the TLS client as well as the TLS 313 server use the IEEE 1609.2 certificate. In consequence, both the 314 server and the client populate the client_certificate_type and 315 server_certificate_type with extension IEEE 1609.2 certificates as 316 mentioned in figure 2. 318 Client Server 320 ClientHello, 321 client_certificate_type*=1609Dot2, 322 server_certificate_type*=1609Dot2, --------> ServerHello, 323 {EncryptedExtensions} 324 {client_certificate_type*=1609Dot2} 325 {server_certificate_type*=1609Dot2} 326 {CertificateRequest*} 327 {Certificate*} 328 {CertificateVerify*} 329 {Finished} 330 {Certificate*} <------- [Application Data*] 331 {CertificateVerify*} 332 {Finished} --------> 333 [Application Data] <-------> [Application Data] 335 Figure 2: TLS Client and TLS Server use the IEEE 1609.2 certificate 337 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS Server uses 338 the X.509 certificate 340 This example shows the TLS authentication, where the TLS Client 341 populates the server_certificate_type extension with the X.509 342 certificate and Raw Public Key type as presented in figure 3. the 343 client indicates its ability to receive and to validate an X.509 344 certificate from the server. The server chooses the X.509 345 certificate to make its authentication with the Client. 347 Client Server 348 ClientHello, 349 client_certificate_type*=(1609Dot2), 350 server_certificate_type*=(1609.9Dot, 351 X509,RawPublicKey), -----------> ServerHello, 352 {EncryptedExtensions} 353 {client_certificate_type*=1609Dot2} 354 {server_certificate_type*=X509} 355 {Certificate*} 356 {CertificateVerify*} 357 {Finished} 358 <--------- [Application Data*] 359 {Finished} ---------> 360 [Application Data] <--------> [Application Data] 362 Figure 3: TLS Client uses the IEEE 1609.2 certificate and TLS Server 363 uses the X.509 certificate 365 7. Security Considerations 367 This section provides an overview of the basic security 368 considerations which need to be taken into account before 369 implementing the necessary security mechanisms. The security 370 considerations described throughout [RFC8446] regarding the supported 371 groups and signature algorithms apply here as well. 373 TLS extensions to be considered are: 375 The "client_certificate_type" [IANA value 19] extension who's 376 purpose was previously described in [RFC7250]. 378 The "server_certificate_type" [IANA value 20] extension who's 379 purpose was previously described in [RFC7250]. 381 8. Privacy Considerations 383 For privacy considerations in a vehicular environment the use of IEEE 384 1609.2/ETSI TS 103097 certificate is recommended for many reasons: 386 In order to address the risk of a personal data leakage, messages 387 exchanged for V2V communications are signed using IEEE 1609.2/ETSI 388 TS 103097 pseudonym certificates 390 The purpose of these certificates is to provide privacy relying on 391 geographical and/or temporal validity criteria, and minimizing the 392 exchange of private data 394 9. IANA Considerations 396 IANA is requested to update the registry to reference the RFC. 398 Existing IANA references have not been updated yet to point to this 399 document. 401 10. Acknowledgements 403 The authors wish to thank Eric Rescola and Ilari Liusvaara for their 404 feedback and suggestions on improving this document. Thanks are due 405 to Sean Turner for his valuable and detailed comments. Special 406 thanks to Panos Kampanakis, Jasja Tijink and Maik Seewald for their 407 guidance and support of the draft. 409 11. References 411 11.1. Normative References 413 [IEEE1609.2] 414 "IEEE Standard for Wireless Access in Vehicular 415 Environments - Security Services for Applications and 416 Management Messages", 2016. 418 [IEEE1609.2b] 419 "IEEE Standard for Wireless Access in Vehicular 420 Environments--Security Services for Applications and 421 Management Messages - Amendment 2--PDU Functional Types 422 and Encryption Key Management", 2019. 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", March 1997. 427 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 428 (TLS) Protocol Version 1.2", August 2008. 430 [RFC7250] Wouters, P., Tschofenig, H., Weiler, S., and T. Kivinen, 431 "Using Raw Public Keys in Transport Layer Security (TLS) 432 and Datagram Transport Layer Security (DTLS)", June 2014. 434 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 435 2119 Key Words", May 2017. 437 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 438 Version 1.3", August 2018. 440 [TS103097] 441 "ETSI TS 103 097 : Intelligent Transport Systems (ITS); 442 Security; Security header and certificate formats". 444 11.2. Informative References 446 [draft-serhrouchni-tls-certieee1609-00] 447 KAISER, A., LABIOD, H., LONC, B., MSAHLI, M., and A. 448 SERHROUCHNI, "Transport Layer Security (TLS) 449 Authentication using ITS ETSI and IEEE certificates", 450 august 2017. 452 Appendix A. Contributors 454 o Houda Labiod 455 Telecom ParisTech 456 houda.labiod@telecom-paristech.fr 458 o Ahmed Serhrouchni 459 Telecom ParisTech 460 ahmed.serhrouchni@telecom-paristech.fr 462 o William Whyte 463 Onboard Security 464 wwhyte@onboardsecurity.com 466 Authors' Addresses 468 Mounira Msahli (editor) 469 Telecom ParisTech 470 France 472 EMail: mounira.msahli@telecom-paristech.fr 474 Nancy Cam-Winget (editor) 475 Cisco 476 USA 478 EMail: ncamwing@cisco.com