idnits 2.17.1 draft-msahli-ise-ieee1609-01.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 (August 14, 2019) is 1716 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: February 15, 2020 Cisco 6 August 14, 2019 8 TLS Authentication using IEEE 1609.2 certificate 9 draft-msahli-ise-ieee1609-01 11 Abstract 13 This document specifies the use of the IEEE/ETSI certificate type to 14 authenticate TLS entities. The goal is to enable the use of end- 15 entity certificate specified by the IEEE and the European 16 Telecommunications Standards Institute (ETSI). This specification 17 defines an experimental change of TLS to support IEEE/ETSI 18 certificate type. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 15, 2020. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Experiment Overview . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3 57 3. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3 58 4. TLS Client and Server Handshake . . . . . . . . . . . . . . . 4 59 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 6 60 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Certificate Verification . . . . . . . . . . . . . . . . . . 7 62 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate . 8 64 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS 65 Server uses the X.509 certificate . . . . . . . . . . . . 8 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 70 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 71 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 74 1. Introduction 76 The TLS protocol [RFC8446] [RFC5246] uses X.509 certificates and Raw 77 Public Key in order to authenticate servers and clients. This 78 document describes an experimental extension following the [RFC7250] 79 to support use of the certificate format 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 Systems (ITS). The standards specify different types of certificate 88 to support a full Public Key Infrastructure (PKI) specification; the 89 certificates to be used in this context are end-entity certificates, 90 i.e. certificates that have the 1609.2 appPermissions field present. 92 1.1. Experiment Overview 94 This document describes an experimental extension of TLS security 95 model. We are using a form of certificate that has not traditionally 96 been used in the Internet. Systems using this Experimental approach 97 are segregated from system using standard TLS by the use of a new 98 Certificate Type value, reserved through IANA. The implementation of 99 TLS is not involved in the Experiment and it will not be able to 100 interact with an Experimental implementation. In fact, an 101 implementation of TLS can recognize that the Certificate Type value 102 used in this document is unknown. This extension has been encouraged 103 by stakeholders in the Cooperative ITS community including ISO 104 internationally, and SAE in the US and ETSI in EU , in order to 105 support the deployment of a number of use cases in cooperative ITS 106 and it is anticipated that its use will be widespread. 108 2. Requirements Terminology 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174]when, and only when, they appear in all 114 capitals, as shown here. 116 3. Extension Overview 118 For TLS 1.2[RFC5246], the "extension_data" field SHALL follow the 119 [RFC7250]. In case of TLS 1.3, the "extension_data" field SHALL 120 contain a list of supported certificate types proposed by the client 121 as provided in the figure below: 123 /* Managed by IANA */ 124 enum { 125 X509(0), 126 RawPublicKey(2), 127 1609Dot2(3), 128 (255) 129 } CertificateType; 131 struct { 132 select (certificate_type) { 134 /* certificate type defined in this document.*/ 135 case 1609Dot2: 136 opaque cert_data<1..2^24-1>; 138 /* RawPublicKey defined in RFC 7250*/ 139 case RawPublicKey: 140 opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>; 142 /* X.509 certificate defined in RFC 5246*/ 143 case X.509: 144 opaque cert_data<1..2^24-1>; 146 }; 148 Extension extensions<0..2^16-1>; 149 } CertificateEntry; 151 In case where the TLS server accepts the described extension, it 152 selects one of the certificate types. Note that a server MAY 153 authenticate the client using other authentication methods. 155 4. TLS Client and Server Handshake 157 The "client_certificate_type" and "server_certificate_type" 158 extensions MUST be sent in handshake phase as illustrated in figure 1 159 below. 161 Client Server 163 Key ^ ClientHello 164 Exch | + server_certificate_type* 165 | + client_certificate_type* 166 | + key_share* 167 v + signature_algorithms* --------> 168 ServerHello ^ Key 169 + key_share* v Exch 170 {EncryptedExtensions} ^ Server 171 {+ server_certificate_type*}| Params 172 {+ client_certificate_type*}| 173 {CertificateRequest*} v 174 {Certificate*} ^ 175 {CertificateVerify*} | Auth 176 {Finished} v 177 <------- [Application Data*] 178 ^ {Certificate*} 179 Auth | {CertificateVerify*} 180 v {Finished} --------> 181 [Application Data] <-------> [Application Data] 183 + Indicates noteworthy extensions sent in the 184 previously noted message. 186 * Indicates optional or situation-dependent 187 messages/extensions that are not always sent. 189 {} Indicates messages protected using keys 190 derived from a [sender]_handshake_traffic_secret. 192 [] Indicates messages protected using keys 193 derived from [sender]_application_traffic_secret_N. 195 Figure 1: Message Flow with certificate type extension for Full TLS 196 1.3 Handshake 198 In case of TLS 1.3 and in order to negotiate the support of IEEE 199 1609.2 or ETSI TS 103097 certificate-based authentication, the 200 clients and the servers MAY include the extension of type 201 "client_certificate_type" and "server_certificate_type" in the 202 extended Client Hello and "EncryptedExtensions". In case of TLS 1.2, 203 used extensions are in Client Hello and Server Hello. 205 4.1. Client Hello 207 In order to indicate the support of IEEE 1609.2 or ETSI TS 103097 208 certificates, client MUST include an extension of type 209 "client_certificate_type" or "server_certificate_type" in the 210 extended Client Hello message as described in Section 4.1.2 of TLS 211 1.3 [RFC8446]. 213 The extension 'client_certificate_type' sent in the Client Hello MAY 214 carry a list of supported certificate types, sorted by client 215 preference. It is a list in the case where the client supports 216 multiple certificate types. 218 In both TLS 1.2 and 1.3, the rules if client Certificate and 219 CertificateVerify messages appear is as follows: 221 - Client Certificate message is present if and only if server sent 222 a CertificateRequest message. 224 - Client CertificateVerify message is present if and only if the 225 Client Certificate message is present and contains non-empty 226 certificate list. 228 All implementations SHOULD be prepared to handle extraneous 229 certificates and arbitrary orderings from any TLS version, with the 230 exception of the end-entity certificate which MUST be first. 232 4.2. Server Hello 234 When the server receives the Client Hello containing the 235 client_certificate_type extension and/or the server_certificate_type 236 extension, the following options are possible: 238 - The server supports the extension described in this document. 239 It selects a certificate type from the client_certificate_type 240 field in the extended Client Hello and SHALL take into account the 241 client authentication list priority. 243 - The server does not support any of the proposed certificate type 244 and terminates the session with a fatal alert of type 245 "unsupported_certificate". 247 - The server does not support the extension defined in this 248 document. In this case, the server returns the Server Hello 249 without the extensions defined in this document. 251 - The server supports the extension defined in this document, but 252 it does not have any certificate type in common with the client. 254 Then, the server terminates the session with a fatal alert of type 255 "unsupported_certificate". 257 - The server supports the extensions defined in this document and 258 has at least one certificate type in common with the client. In 259 this case, the server MAY include the client_certificate_type 260 extension in the Server Hello for TLS 1.2 or in Encrypted 261 Extension for TLS 1.3. Then, the server requests a certificate 262 from the client (via the certificate_request message) 264 It is worth to mention that the TLS client or server public keys are 265 obtained from an online repository. 267 5. Certificate Verification 269 Verification of an IEEE 1609.2/ ETSI TS 103097 certificates or 270 certificate chain is described in section 5.1 of [IEEE1609.2]. In 271 the case of TLS 1.3 and when the certificate_type is 1609Dot2, the 272 CertificateVerify contents and processing are different than for the 273 CertificateVerify message specified for other values of 274 certificate_type in [RFC8446]. In this case, the CertificateVerify 275 message contains a Canonical Octet Encoding Rules (COER)[ITU-TX.696] 276 -encoded IEEE1609Dot2Data of type signed as specified in 277 [IEEE1609.2], [IEEE1609.2b], where: 279 payload contains an extDataHash containing the SHA-256 hash of the 280 data the signature is calculated over. This is identical to the 281 data the signature is calculated over in standard TLS, which is 282 reproduced below for clarity. 284 psid indicates the application activity that the certificate is 285 authorizing. 287 generationTime is the current time. 289 pduFunctionalType (as specified in [IEEE1609.2b]) is present and 290 is set equal to tlsHandshake (1). 292 All other fields in the headerInfo are omitted. 294 The certificate appPermissions field shall be present and shall 295 permit (as defined in 1609.2) signing of PDUs with the PSID indicated 296 in the HeaderInfo of the SignedData. If the application 297 specification for that PSID requires Service Specific Permissions 298 (SSP) for signing a pduFunctionalType of tlsHandsahke, this SSP shall 299 also be present. 301 The message input to the signature calculation is the usual message 302 input for TLS 1.3, as specified in [RFC8446] section 4.4.3, 303 consisting of pad, context string, separator and content, where 304 content is Transcript- Hash(Handshake Context, Certificate). 306 The signature and verification are carried out as specified in 307 [IEEE1609.2]. 309 6. Examples 311 Some of exchanged messages examples are illustrated in Figures 2 and 312 3. 314 6.1. TLS Server and TLS Client use the 1609Dot2 Certificate 316 This section shows an example where the TLS client as well as the TLS 317 server use the IEEE 1609.2 certificate. In consequence, both the 318 server and the client populate the client_certificate_type and 319 server_certificate_type with extension IEEE 1609.2 certificates as 320 mentioned in figure 2. 322 Client Server 324 ClientHello, 325 client_certificate_type=1609Dot2, 326 server_certificate_type=1609Dot2, --------> ServerHello, 327 {EncryptedExtensions} 328 {client_certificate_type=1609Dot2} 329 {server_certificate_type=1609Dot2} 330 {CertificateRequest} 331 {Certificate} 332 {CertificateVerify} 333 {Finished} 334 {Certificate} <------- [Application Data] 335 {CertificateVerify} 336 {Finished} --------> 337 [Application Data] <-------> [Application Data] 339 Figure 2: TLS Client and TLS Server use the IEEE 1609.2 certificate 341 6.2. TLS Client uses the IEEE 1609.2 certificate and TLS Server uses 342 the X.509 certificate 344 This example shows the TLS authentication, where the TLS Client 345 populates the server_certificate_type extension with the X.509 346 certificate and Raw Public Key type as presented in figure 3. the 347 client indicates its ability to receive and to validate an X.509 348 certificate from the server. The server chooses the X.509 349 certificate to make its authentication with the Client. 351 Client Server 352 ClientHello, 353 client_certificate_type=(1609Dot2), 354 server_certificate_type=(1609.9Dot, 355 X509,RawPublicKey), -----------> ServerHello, 356 {EncryptedExtensions} 357 {client_certificate_type=1609Dot2} 358 {server_certificate_type=X509} 359 {Certificate} 360 {CertificateVerify} 361 {Finished} 362 <--------- [Application Data] 363 {Finished} ---------> 364 [Application Data] <--------> [Application Data] 366 Figure 3: TLS Client uses the IEEE 1609.2 certificate and TLS Server 367 uses the X.509 certificate 369 7. Security Considerations 371 This section provides an overview of the basic security 372 considerations which need to be taken into account before 373 implementing the necessary security mechanisms. The security 374 considerations described throughout [RFC8446] regarding the supported 375 groups and signature algorithms apply here as well. 377 TLS extensions to be considered are: 379 The "client_certificate_type" [IANA value 19] extension who's 380 purpose was previously described in [RFC7250]. 382 The "server_certificate_type" [IANA value 20] extension who's 383 purpose was previously described in [RFC7250]. 385 This specification does not address the security of online 386 repository. 388 8. Privacy Considerations 390 For privacy considerations in a vehicular environment the use of IEEE 391 1609.2/ETSI TS 103097 certificate is recommended for many reasons: 393 In order to address the risk of a personal data leakage, messages 394 exchanged for V2V communications are signed using IEEE 1609.2/ETSI 395 TS 103097 pseudonym certificates 397 The purpose of these certificates is to provide privacy relying on 398 geographical and/or temporal validity criteria, and minimizing the 399 exchange of private data 401 9. IANA Considerations 403 IANA is requested to update the registry to reference the RFC: 404 https://www.iana.org/assignments/tls-extensiontype-values/tls- 405 extensiontype-values.xhtml to point to this document. 407 10. Acknowledgements 409 The authors wish to thank Eric Rescola , Russ Housley and Ilari 410 Liusvaara for their feedback and suggestions on improving this 411 document. Thanks are due to Sean Turner for his valuable and 412 detailed comments. Special thanks to Panos Kampanakis, Jasja Tijink 413 and Maik Seewald for their guidance and support of the draft. 415 11. Normative References 417 [IEEE1609.2] 418 "IEEE Standard for Wireless Access in Vehicular 419 Environments - Security Services for Applications and 420 Management Messages", 2016. 422 [IEEE1609.2b] 423 "IEEE Standard for Wireless Access in Vehicular 424 Environments--Security Services for Applications and 425 Management Messages - Amendment 2--PDU Functional Types 426 and Encryption Key Management", 2019. 428 [ITU-TX.696] 429 "Procedures for the operation of object identifier 430 registration authorities: General procedures and top arcs 431 of the international object identifier tree", July 2011. 433 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 434 Requirement Levels", March 1997. 436 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 437 (TLS) Protocol Version 1.2", August 2008. 439 [RFC7250] Wouters, P., Tschofenig, H., Weiler, S., and T. Kivinen, 440 "Using Raw Public Keys in Transport Layer Security (TLS) 441 and Datagram Transport Layer Security (DTLS)", June 2014. 443 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 444 2119 Key Words", May 2017. 446 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 447 Version 1.3", August 2018. 449 [TS103097] 450 "ETSI TS 103 097 : Intelligent Transport Systems (ITS); 451 Security; Security header and certificate formats". 453 Appendix A. Contributors 455 o Houda Labiod 456 Telecom ParisTech 457 houda.labiod@telecom-paristech.fr 459 o Ahmed Serhrouchni 460 Telecom ParisTech 461 ahmed.serhrouchni@telecom-paristech.fr 463 o William Whyte 464 Onboard Security 465 wwhyte@onboardsecurity.com 467 Authors' Addresses 469 Mounira Msahli (editor) 470 Telecom ParisTech 471 France 473 EMail: mounira.msahli@telecom-paristech.fr 475 Nancy Cam-Winget (editor) 476 Cisco 477 USA 479 EMail: ncamwing@cisco.com