| TLS Working Group | P. Kampanakis, Ed. |
| Internet-Draft | Cisco |
| Intended status: Informational | M. Msahli, Ed. |
| Expires: September 22, 2018 | Telecom ParisTech |
| March 21, 2018 |
Transport Layer Security (TLS) Authentication using ITS ETSI and IEEE certificates
draft-tls-certieee1609-02.txt
This document specifies the use of two new certificate types to authenticate TLS entities. The first type enables the use of a certificate specified by the Institute of Electrical and Electronics Engineers (IEEE) [IEEE-ITS] and the second by the European Telecommunications Standards Institute (ETSI) [ETSI103097].
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 September 22, 2018.
Copyright (c) 2018 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
At present, TLS protocol uses X509 [RFC5246] and Raw Pubic Key [RFC7250] in order to authenticate servers and clients. This document describes the use of certificates specified either by the Institute of Electrical and Electronics Engineers (IEEE) [IEEE-ITS] or the European Telecommunications Standards Institute (ETSI) [ETSI103097]. These standards are defined in order to secure communications in vehicular environments. Existing certificates, such as X509 and Raw Pubic Key, are designed for Internet use, particularly for flexibility and extensibility, and are not optimized for bandwidth and processing time to support delay-sensitive applications. This is why size-optimized certificates that meet the ITS requirements were designed and standardized.
Two new values referring the previously mentioned certificated are added to the "client_certificate_type" and the "server_certificate_type" extensions defined in [RFC7250].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
opaque ASN.1Cert <1..2^24-1>
struct {
select(certificate_type){
// certificate type defined in this document.
case ETSI:
ASN.1Cert certificate_list<1..2^24-1>
// certificate type defined in this document.
case IEEE:
ASN.1Cert certificate_list<1..2^24-1>
// RawPublicKey defined in RFC 7250
// certificate type defined in this document.
case RawPublicKey:
opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>
// X.509 certificate defined in RFC 5246
case X.509:
ASN.1Cert certificate_list<1..2^24-1>
// Additional certificate type based on
// "TLS Certificate Types" subregistry
};
} Certificate;
The extension format for extended client and server hellos, which uses the "extension_data" field, is used to carry the "Certificate_Type_Extension" Structure.defined in RFC7250. The CertificateType structure is an enum with values taken from the TLS Certificate Types In order to negotiate the support of IEEE or ETSI certificate-based authentication:
The extension_data" field of this extension SHALL contain a list of supported certificate types proposed by the client as provided in figure below:
In case where the TLS server accepts the described extension, it selects one of the certificate types in the extension described here. Note that a server MAY authenticate the client using other authentication methods. The client MAY at its discretion either continue the handshake, or respond with a fatal message alert.
The end-entity certificate's public key has to be compatible with one of the certificate types listed in extension described here.
Servers aware of the extension described here but not wishing to use it, SHOULD gracefully not proceed with the negotiation.
client_hello,
client_certificate_type,
server_certificate_type ->
<- server_hello,
client_certificate_type,
server_certificate_type,
certificate,
server_key_exchange,
certificate_request,
server_hello_done
certificate,
client_key_exchange,
certificate_verify,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 1: Message Flow with certificate type extension
The "client_certificate_type" message MUST be sent as the first handshake message as illustrated in Figure 1 below.
In order to indicate the support of IEEE or ETSI certificates, clients MUST include an extension of type "client_certificate_type" to the extended client hello message. The hello extension mechanism is described in Section 4.1.2 of TLS 1.3 [RFC6961].
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 a vehicular environment, privacy is important. In order to preserve anonymity, a client MUST include IEEE or ETSI certificate types in the "client_certificate_type" extension certificates.
Clients respond along with their certificates by sending a "Certificate" message immediately followed by the "ClientKeyExchange" message. The premaster secret is generated according to the cipher algorithm selected by the server in the ServerHello.cipher_suite.
When the server receives the client hello containing the client_certificate_type extension and/or the server_certificate_type extension. The following outcomes are possible:
Verification of an IEEE 1609.2 certificate or certificate chain is described in section 5.5.2 of [IEEE-ITS].
Verification of ETSI TS 103 097 certificate or certificate chain is described in annex F of [ETSI102941].
Some of exchanged messages examples are illustrated in Figures 2 and 3.
client_hello,
client_certificate_type= (X.509, Raw Public Key ) ->
server_certificate_type= ( IEEE ord ETSI certificate) ->
<- server_hello,
client_certificate_type= (X.509, Raw Public Key ) ->
server_certificate_type= ( IEEE ord ETSI certificate),
certificate,
certificate_request,
server_hello_done
certificate,
client_key_exchange,
certificate_verify,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 2: Example with ETSI or IEEE certificate
This example shows the TLS authentication, where the TLS client indicates its ability to receive and to validate an IEEE and ETSI certificate from the server. Therefore, the client populates the server_certificate_type extension with the ETSI or IEEE certificate type as presented in figure 2. In this exchange the client indicates its ability to process the X.509 or the Raw Public Keys.
client_hello,
client_certificate_type= ( IEEE ord ETSI certificate) ->
server_certificate_type= ( IEEE ord ETSI certificate) ->
<- server_hello,
server_certificate_type= ( IEEE ord ETSI certificate),
certificate,
client_certificate_type= ( IEEE ord ETSI certificate),
certificate,
certificate_request,
server_hello_done
certificate,
certificate_verify,
change_cipher_spec,
finished ->
<- change_cipher_spec,
finished
Application Data <-------> Application Data
Figure 3: TLS Client and TLS Server use the ETSI or IEEE Certificates
This section shows an example where the TLS client as well as the TLS server use the ETSI or IEEE certificates. In consequence, both the server and the client populate the Client_Certificate_type and server_certificate_type with extension ETSI or IEEE certificates as mentioned in figure 3.
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 [RFC5246] apply here as well.
For security considerations in a vehicular environment, the minimal use of any TLS extensions is recommended such as : [RFC5746] which presented Man-In-The-Middle (MITM) type attacks over the past years.
In addition, servers SHOULD not support renegotiation
For privacy considerations in a vehicular environment the use of ETSI and IEEE certificate is recommended for many reasons:
Existing IANA references have not been updated yet to point to this document.
IANA is asked to register two new values in the "TLS Certificate Types" registry of Transport Layer Security (TLS) Extensions [TLS-Certificate-Types-Registry], as follows:
This document borrows a lot from [draft-serhrouchni-tls-certieee1609-00]. 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.
| [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. |
| [FIPS186] | FIPS 186-4, "Digital Signature Standard", July 2013. |
| [ICSI] | ICST project, "Analysis of timeliness of communication for IEEE 1609.2", 2013. |
| [KARGL] | Kargl, F., Papadimitratos, P., Buttyan, L., Muter, M., Schoch, E., Wiedersheim, B., Thong, T., Calandriello, G., Held, A., Kung, A. and J. Hubaux, "Secure Vehicular Communications: Implementation, Performance, and Research Challenges", November 2008. |
| [PETIT] | Petit, J., "Analysis of ECDSA authentication processing in VANETs", December 2009. |
| [SCHUTZE] | Schutze, T., "Automotive security: Cryptography for Car2X communication", March 2011. |
| [X696] | ITU-T X.696, "Information Technology - ASN.1 encoding rules: Specification of Octet Encoding Rules (OER)", august 2014. |
+-----------------------+-----------------------+ | ETSI Certificate | IEEE Certificate | +-----------------------+-----------------------+ | Version | Version | +-----------------------+-----------------------+ | | Type | +-----------------------+-----------------------+ | Signer_info | IssuerIdentifier | +-----------------------+-----------------------+ | Subject_info | | | Subject_attributes | ToBeSignedCertificate | | Validity_restrictions | | +-----------------------+-----------------------+ | Signature | Signature | +-----------------------+-----------------------+
Figure 4: Certificates comparison
The ETSI and IEEE 1609.2 represent the active standardization groups in Europe and U.S those dealing with the security of vehicular communications. Although defined for the same purpose, the different security requirements have led to the definition of different certificate formats. Figure 4, the IEEE certificate contains same data strucutres as the one defined by ETSI except "Type" field, which specifies the type of certificate if it is implicit or explicit.
The main differences are listed below:
In order to authenticate end-entities in TLS with ETSI certificates the following issues still have to be addressed:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
+---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--
01 | 02 80 ba 80 02 02 01 53 88 de c6 40 c6 e1 9e 01
02 | 00 52 00 00 04 d4 81 34 8a cd d1 d9 9c 1f fb a4
03 | c7 0e 6d 2a 5d 13 ca b0 a1 e6 cf 63 22 9f 69 79
04 | b4 53 c0 15 c7 da 3a 12 7c 8f 39 44 59 b1 2f 94
05 | d4 cb 9a 12 ce e1 1d 87 40 8d 91 ac 95 6c 90 c8
06 | b3 b2 9f 4c 22 02 e0 21 0b 24 03 01 00 00 25 04
07 | 01 00 00 00 0b 01 15 04 39 83 15 4c bc 02 03 00
08 | 00 00 71 ff 9a 0d 80 16 ca cb cd d8 1c d1 4f 81
09 | 94 3c dd c7 74 51 1e 2b f7 15 7b 33 e5 4f 7b 6b
10 | 6e 5b 5d 07 94 70 be 40 a6 46 e0 55 9c 19 89 28
11 | b5 b8 ed cf bd c2 29 70 53 95 1d bc 51 cb d6 a3
12 | e1 d0 00 00 01 41 ae 0f 26 64 c0 05 24 01 55 20
13 | 50 02 80 00 31 01 00 14 00 30 14 4a d9 f8 7e 59
14 | 9e 09 2b 00 00 00 00 00 00 00 00 80 00 00 00 00
15 | 00 00 00 07 d1 00 00 01 02 00 00 00 02 09 2b 40
16 | 56 b4 9d 20 0d 69 3a 40 1f ff ff fc 22 30 d4 1e
17 | 40 00 0f c0 00 7e 02 76 ea 87 33 a9 d7 4f ff d0
18 | 84 14 00 00 43 01 00 00 61 6d 42 37 dd 2c ea b7
19 | 27 31 c2 3b cb 5d 61 8f 88 17 df 0d a8 7b d2 b8
20 | d3 54 8f 71 09 8a f1 88 d2 43 04 a8 61 6a 95 bf
21 | 5e 07 45 a1 06 e9 33 9f 9e 69 ba b3 3c bc 68 28
22 | 93 5a 66 ea 11 a0 37 69
Figure 5: Example of encoded ETSI secured message with signed payload
The hex sequence shown in Figure 5 presents an encoded secured message with signed payload as a generic encoded octet string.
struct SecuredMessage {
uint8 protocol_version: 2
HeaderField<186> header_fields {
struct HeaderField {
HeaderFieldType type: signer_info (128)
struct SignerInfo signer {
SignerInfoType type: certificate (2)
struct Certificate certificate {
uint8 version: 2
struct SignerInfo signer_info {
SignerInfoType type: certificate_digest_with_sha256 (1)
HashedId8 digest: 5388DEC640C6E19E
}
struct SubjectInfo subject_info {
SubjectType subject_type: authorization_ticket (1)
opaque<0> subject_name:
}
SubjectAttribute<82> subject_attributes {
struct SubjectAttribute {
SubjectAttributeType type: verification_key (0)
struct PublicKey key {
PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_
sha256 (0)
struct EccPoint public_key {
EccPointType type: uncompressed (4)
opaque[32] x: D481348ACDD1D99C1FFBA4C70E6D2A5D
13CAB0A1E6CF63229F6979B453C015C7
opaque[32] y: DA3A127C8F394459B12F94D4CB9A12CE
E11D87408D91AC956C90C8B3B29F4C22
}
}
}
struct SubjectAttribute {
SubjectAttributeType type: assurance_level (2)
SubjectAssurance assurance_level: assurance level = 7,
confidence = 0
(bitmask = 11100000)
}
struct SubjectAttribute {
SubjectAttributeType type: its_aid_ssp_list (33)
ItsAidSsp<11> its_aid_ssp_list {
struct ItsAidSsp {
IntX its_aid: 36
opaque<3> service_specific_permissions: 010000
}
struct ItsAidSsp {
IntX its_aid: 37
opaque<4> service_specific_permissions: 01000000
}
}
}
}
ValidityRestriction<11> validity_restrictions {
struct ValidityRestriction {
ValidityRestrictionType type: time_start_and_end (1)
Time32 start_validity: 2015-03-05 00:00:00 UTC
Time32 end_validity: 2015-04-28 23:59:59 UTC
}
struct ValidityRestriction {
ValidityRestrictionType type: region (3)
struct GeographicRegion region {
RegionType region_type: none (0)
}
}
}
struct Signature {
PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_sha256
(0)
struct EcdsaSignature ecdsa_signature {
struct EccPoint R {
EccPointType type: x_coordinate_only (0)
opaque[32] x: 71FF9A0D8016CACBCDD81CD14F81943C
DDC774511E2BF7157B33E54F7B6B6E5B
}
opaque[32] s: 5D079470BE40A646E0559C198928B5B8
EDCFBDC2297053951DBC51CBD6A3E1D0
}
}
}
}
}
struct HeaderField {
HeaderFieldType type: generation_time (0)
Time64 generation_time: 2015-03-17 15:26:48.000 UTC
}
struct HeaderField {
HeaderFieldType type: its_aid (5)
IntX its_aid: 36
}
}
struct Payload payload_field {
PayloadType type: signed (1)
opaque<85> data: 2050028000310100140030144AD9F87E
599E092B000000000000000080000000
0000000007D10000010200000002092B
4056B49D200D693A401FFFFFFC2230D4
1E40000FC0007E0276EA8733A9D74FFF
D084140000
}
TrailerField<67> trailer_fields {
struct TrailerField {
TrailerFieldType type: signature (1)
struct Signature signature {
PublicKeyAlgorithm algorithm: ecdsa_nistp256_with_sha256 (0)
struct EcdsaSignature ecdsa_signature {
struct EccPoint R {
EccPointType type: x_coordinate_only (0)
opaque[32] x: 616D4237DD2CEAB72731C23BCB5D618F
8817DF0DA87BD2B8D3548F71098AF188
}
opaque[32] s: D24304A8616A95BF5E0745A106E9339F
9E69BAB33CBC6828935A66EA11A03769
}
}
}
}
}
Figure 6: Example of parsed ETSI secured message with signed payload
In the parsed data structure, the contents are presented in the form:
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
+---+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--
01 | 02 01 03 02 02 04 f3 db 4f 6f ca b6 49 65 01 09
02 | 63 65 72 74 4e 61 6d 65 31 01 05 e0 00 00 01 00
03 | 04 00 00 00 00 00 00 00 01 00 02 d4 a8 61 1d ce
04 | d8 8c a7 a2 e9 6a 8d 7e 49 0f 3c 9a 46 27 c0 72
05 | 26 ed 67 8d 04 74 41 02 00 03 9c b6 6f 87 4a 40
06 | 7c 21 83 40 22 db 6d 0a 80 d0 14 cb df 24 fc a0
07 | 83 f8 e2 00 81 b0 7c 14 b8 e7 02 19 90 d0 57 4b
08 | 14 d2 80 29 1f c4 e6 a6 73 12 68 74 96 77 c2 52
09 | 34 ae bb e4 29 da 16 60 61 19 74 c6 b3 53 98 0e
10 | 70 e3 3d 4f b9 03 99 76 05 44 e9 74 70 d9 92 bb
11 | 3c 37 92 c3 51 d4 7d 8e ea b1 03 0a e0 00 00 01
12 | 0c 73 6f 6d 65 20 63 6f 6e 74 65 6e 74 00 00 e7
13 | 2a dc 3e dc 09 00 00 00 00 00 00 00 00 00 00 00
14 | 02 ca bf a2 0d 82 ae 3e 25 a3 8c 9c dd 2e cf 94
15 | 9f cc 7c 7f d9 d8 83 89 f5 08 f7 aa bb 5b ef 21
16 | bd 7a 2e 79 6c c7 de 01 af b1 93 35 5b e2 f5 88
17 | 19 76 70 e4 ae 09 cf 3b ee
Figure 7: Example of encoded IEEE 1609.2 v2 signed data structure
The hex sequence shown in Figure 7 presents an encoded signed data structure as a flat encoded octet string.
protocol_version (0, 1): 02
type (1, 1): 01 (signed)
signed_data (2, 263):
signer (2, 169):
type (2, 1): 03 (certificate)
certificates (3, 168):
version_and_type (3, 1): 02 (explicit)
unsigned_certificate (4, 102):
holder_type (4, 1): 02 (identified localized)
cf (5, 1): 04 (encryption_key)
signer_id (6, 8): f3 db 4f 6f ca b6 49 65
signature_alg (14, 1): 01 (ECDSA NIST P256)
scope (15, 18):
id_scope (15, 18):
name_len (15, 1): 09
name (16, 9): 63 65 72 74 4e 61 6d 65 31
permissions (25, 7):
type (25, 1): 01 (specified)
permissions_list_len (26, 1): 05
permissions_list (27, 5):
psid (27, 4): e0 00 00 01
service_specific_permissions_len (31, 1): 00
region (32, 1):
region_type (32, 1): 04 (none)
expiration (33, 4): 00 00 00 00 (00:00:34 01 Jan 2004 UTC)
crl_series (37, 4): 00 00 00 01
verification_key (41, 30):
algorithm (41, 1): 00 (ECDSA NIST P224)
public_key (42, 29):
type (42, 1): 02 (compressed, lsb of y is 0)
x (43, 28):
d4 a8 61 1d ce d8 8c a7 a2 e9 6a 8d 7e 49 0f 3c
9a 46 27 c0 72 26 ed 67 8d 04 74 41
encryption_key (71, 35):
algorithm (71, 1): 02 (ECIES NIST P256)
supported_symm_alg (72, 1): 00 (AES 128 CCM)
public_key (73, 33):
type (73, 1): 03 (compressed, lsb of y is 1)
x (74, 32):
9c b6 6f 87 4a 40 7c 21 83 40 22 db 6d 0a 80 d0
14 cb df 24 fc a0 83 f8 e2 00 81 b0 7c 14 b8 e7
signature (106, 65):
ecdsa_signature (106, 65):
R (106, 33):
type (106, 1): 02 (compressed, lsb of y is 0)
x (107, 32):
19 90 d0 57 4b 14 d2 80 29 1f c4 e6 a6 73 12 68
74 96 77 c2 52 34 ae bb e4 29 da 16 60 61 19 74
s (139, 32):
c6 b3 53 98 0e 70 e3 3d 4f b9 03 99 76 05 44 e9
74 70 d9 92 bb 3c 37 92 c3 51 d4 7d 8e ea b1 03
unsigned_data (171, 37):
tf (171, 1): 0a (use_generation_time, use_location)
psid (172, 4): e0 00 00 01
data_len (176, 1): 0c
data (177, 12): 73 6f 6d 65 20 63 6f 6e 74 65 6e 74
generation_time (189, 9):
time (189, 8): 00 00 e7 2a dc 3e dc 09
(19:08:23 20 Jan 2012 UTC)
log_std_dev (197, 1): 00 (1.134666 ns or less)
generation_location (198, 10):
latitude (198, 4): 00 00 00 00
longitude (202, 4): 00 00 00 00
elevation (206, 2): 00 00
signature (208, 57):
ecdsa_signature (208, 57):
R (208, 29):
type (208, 1): 02 (compressed, lsb of y is 0)
x (209, 28):
ca bf a2 0d 82 ae 3e 25 a3 8c 9c dd 2e cf 94 9f
cc 7c 7f d9 d8 83 89 f5 08 f7 aa bb
s (237, 28):
5b ef 21 bd 7a 2e 79 6c c7 de 01 af b1 93 35 5b
e2 f5 88 19 76 70 e4 ae 09 cf 3b ee
Figure 8: Example of parsed IEEE 1609.2 v2 signed data structure
In the parsed data structure, the contents are presented in the form: