Hi all,
Please find attached a new version of the draft. We took account of pevious TLS
group comments.
William, editor of 1609.2, proposes to add the section certificate verify
(section 4.3 in the draft).
It concerns the addition of IEEE 1609.2 signature for the the Certificate
verify.
We are soliciting your feedbacks.
Regards
Mounira
----- Mail original -----
De: "Hubert Kario" <[email protected]>
À: "tls" <[email protected]>
Cc: "Mounira Msahli" <[email protected]>, "Ilari Liusvaara"
<[email protected]>
Envoyé: Lundi 27 Août 2018 19:39:12
Objet: Re: [TLS] TLS 1.3 Authentication using ETSI TS 103 097 and IEEE 1609..2
certificates
On Monday, 27 August 2018 19:24:34 CEST Mounira Msahli wrote:
> One could abbrevate the handshake traces to just show the relevant
> parts (which could also cut some clutter)? I think the relevant
> messages always occur in the same order (clienthello, serverhello/
> encryptedextensions, certificate, certificate).
the draft doesn't change the order of messages, doesn't add new messages and
doesn't change the place in which the relevant extensions are placed – so,
what is the utility of duplicating the message flow from the TLS RFCs?
e.g. RFC 8449 and RFC 7685 don't, and they did define new extensions
> The table in section 4.2. Extensions of [RFC 8446] (TLS 1.3) indicates the
> messages where a given extension may
> appear:
> | client_certificate_type [RFC7250] | CH, EE |
> |
> | server_certificate_type [RFC7250] | CH, EE |
>
> But in RFC 7250 (TLS 1.2), the same extensions could appear in CH and SH.
correct, this RFC 8446 table applies only to connections that negotiated TLS
1.3
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
TLS Working Group P. Kampanakis, Ed.
Internet-Draft Cisco
Intended status: Informational M. Msahli, Ed.
Expires: March 26, 2019 Telecom ParisTech
September 22, 2018
TLS Authentication using IEEE 1609.2 and ETSI TS 103 097 certificates
draft-tls-certieee1609-01.txt
Abstract
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) [IEEE1609.2] and the second by the European
Telecommunications Standards Institute (ETSI) [TS103097].
Status of This Memo
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 March 26, 2019.
Copyright Notice
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
Kampanakis & Msahli Expires March 26, 2019 [Page 1]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
3. Extension Overview . . . . . . . . . . . . . . . . . . . . . 3
4. TLS Client and Server Handshake . . . . . . . . . . . . . . . 4
4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Certificate Verify . . . . . . . . . . . . . . . . . . . 7
5. Certificate Verification . . . . . . . . . . . . . . . . . . 7
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. TLS Server and TLS Client use the 1609Dot2 Certificate . 8
6.2. TLS Server uses the IEEE 1609.2 certificate and TLS
Client uses the X 509 certificate . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Co-Authors . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
TLS protocol [RFC8446] [RFC5246] uses X509 and Raw Public Key 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) [IEEE1609.2] or the
European Telecommunications Standards Institute (ETSI) [TS103097].
It is worth to mention that ETSI TS 103097certificate is a profile of
IEEE 1609.2 certificate and it has the same data structure. These
standards are defined in order to secure communications in vehicular
environments. Existing authentication methods, such as X509 and Raw
Public 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 are defined and standardized to
secure data exchange in highly dynamic vehicular environment in
Intelligent Transportation System (ITS).
Two new values referring the previously mentioned certificates will
be added to the "client_certificate_type" and the
"server_certificate_type" extensions defined in [RFC7250].
Kampanakis & Msahli Expires March 26, 2019 [Page 2]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
2. Requirements Terminology
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].
3. Extension Overview
To extend Client Hello and Server Hello messages, the
"extension_data" field of the "Certificate_Type_Extension" structue
defined in RFC7250 is used. In order to negotiate the support of
IEEE 1609.2 or ETSI TS 103097 certificate-based authentication, the
clients and the servers MAY include the extension of type
"client_certificate_type" and "server_certificate_type" in the
extended Client Hello and "EncryptedExtensions". The
"extension_data" field of this extension SHALL contain a list of
supported certificate types proposed by the client as provided in
figure below:
/* Managed by IANA */
enum {
X509(0),
RawPublicKey(2),
1609Dot2(?), /* Number 3 will be requested for 1609.2 */
(255)
} CertificateType;
struct {
select (certificate_type) {
/* certificate type defined in this document.*/
case 1609Dot2:
opaque cert_data<1..2^24-1>;
/* RawPublicKey defined in RFC 7250*/
case RawPublicKey:
opaque ASN.1_subjectPublicKeyInfo<1..2^24-1>;
/* X.509 certificate defined in RFC 5246*/
case X.509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
Kampanakis & Msahli Expires March 26, 2019 [Page 3]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
In case where TLS server accepts the described extension, it selects
one of the certificate types in the extension described below. Note
that a server MAY authenticate the client using other authentication
methods.
The end-entity certificate's public key has to be compatible with one
of the certificate types listed in the extension described above.
It is worth to mention that the TLS client or server public keys are
obtained from a certificate chain from a web page.
4. TLS Client and Server Handshake
The "client_certificate_type" and "server_certificate_type"
extensions MUST be sent in handshake phase as illustrated in Figure 1
below. The reply of the server MUST be sent in EncryptedExtensions
for TLS 1.3. The same extension shall be sent in Server Hello for
TLS 1.2.
Kampanakis & Msahli Expires March 26, 2019 [Page 4]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
Client Server
Key ^ ClientHello
Exch | + server_certificate_type*
| + client_certificate_type*
| + key_share*
v + signature_algorithms* -------->
ServerHello ^ Key
+ key_share* v Exch
{EncryptedExtensions} ^ Server
{+ server_certificate_type*}| Params
{+ client_certificate_type*}|
{CertificateRequest*} v
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
+ Indicates noteworthy extensions sent in the
previously noted message.
* Indicates optional or situation-dependent
messages/extensions that are not always sent.
{} Indicates messages protected using keys
derived from a [sender]_handshake_traffic_secret.
[] Indicates messages protected using keys
derived from [sender]_application_traffic_secret_N.
Figure 1: Message Flow with certificate type extension for Full TLS
1.3 Handshake
4.1. Client Hello
In order to indicate the support of IEEE 1609.2 or ETSI TS 103097
certificates, client MUST include an extension of type
"client_certificate_type" and "server_certificate_type" in the
extended Client Hello message. The Hello extension is described in
Section 4.1.2 of TLS 1.3 [RFC8446].
Kampanakis & Msahli Expires March 26, 2019 [Page 5]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
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.
Client MAY respond along with supported certificates by sending a
"Certificate" message immediately followed by the "CetificateVerify"
message. These specifications are valid for TLS 1.2 and TLS 1.3.
All implementations SHOULD be prepared to handle extraneous
certificates and arbitrary orderings from any TLS version, with the
exception of the end-entity certificate which MUST be first.
4.2. Server Hello
When the server receives the Client Hello containing the
client_certificate_type extension and/or the server_certificate_type
extension, the following options are possible:
- The server supports the extension described in this document.
It selects a certificate type from the client_certificate_type
field in the extended Client Hello and must take into account the
client authentication list priority.
- The server does not support the proposed certificate type and
terminates the session with a fatal alert of type
"unsupported_certificate".
- The server does not support the extension defined in this
document. In this case, the server returns the server hello
without the extensions defined in this document in case of TLS
1.2.
- The server supports the extension defined in this document, but
it does not have any certificate type in common with the client.
Then, the server terminates the session with a fatal alert of type
"unsupported_certificate".
- The server supports the extensions defined in this document and
has at least one certificate type in common with the client. In
this case, the server MUST include the client_certificate_type
extension in the Server Hello for TLS 1.2 and in Encrypted
Extension for TLS 1.3. Then, the server requests a certificate
from the client (via the certificate_request message)
Kampanakis & Msahli Expires March 26, 2019 [Page 6]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
4.3. Certificate Verify
In the case where the certificate_type is 1609Dot2, the
CertificateVerify message is subject to the following constraints:
1) The algorithm field MUST be secp256r1 or secp384r1.
2) The signature field contains a Canonical Octet Encoding Rules
(COER)-encoded Ieee1609Dot2Data of type signed where:
o payload contains an extDataHash containing the SHA-256 hash of
the data the signature is calculated over. This is identical to
the data the signature is calculated over in standard TLS, which
is reproduced below for clarity.
o psid indicates the application activity that the certificate is
authorizing.
o generationTime is the current time.
o All other optional fields in the HeaderInfo structure are
omitted.
o signer is of type digest.
o The signature is calculated over the contents of the ToBeSigned
structure as specified in [1609.2]
The data the signature is calculated over is as follows:
- A string that consists of octet 32 (0x20) repeated 64 times.
- The context string.
- A single 0 byte which serves as the separator.
- The content to be signed.
5. Certificate Verification
Verification of an IEEE 1609.2/ ETSI TS 103097 certificates or
certificate chain is described in section 5.5.2 of [IEEE1609.2].
6. Examples
Some of exchanged messages examples are illustrated in Figures 2 and
3.
Kampanakis & Msahli Expires March 26, 2019 [Page 7]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
6.1. TLS Server and TLS Client use the 1609Dot2 Certificate
This section shows an example where the TLS Client as well as the TLS
Server use the IEEE 1609.2 certificate. In consequence, both the
server and the client populate the client_certificate_type and the
server_certificate_type with extension IEEE 1609.2 certificates as
mentioned in figure 2.
Client Server
ClientHello,
client_certificate_type*=1609Dot2,
server_certificate_type*=1609Dot2, --------> ServerHello,
{EncryptedExtensions}
{client_certificate_type*=1609Dot2}
{server_certificate_type*=1609Dot2}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
{Certificate*} <------- [Application Data*]
{CertificateVerify*}
{Finished} -------->
[Application Data] <-------> [Application Data]
Figure 2: TLS Client and TLS Server use the IEEE 1609.2 certificate
6.2. TLS Server uses the IEEE 1609.2 certificate and TLS Client uses
the X 509 certificate
This example shows the TLS authentication, where the TLS Client
populates the server_certificate_type extension with the X509
certificate and Raw Public Key type as presented in figure 3. The
client indicates its ability to receive and to validate an X509
certificate from the server. The server chooses the X509 certificate
to make its authentication with the Client.
Kampanakis & Msahli Expires March 26, 2019 [Page 8]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
Client Server
ClientHello,
client_certificate_type*=(1609Dot2),
server_certificate_type*=(1609.9Dot, X509,RawPublicKey), ------->
ServerHello,
{EncryptedExtensions}
{client_certificate_type*=1609Dot2}
{server_certificate_type*=X509}
{Certificate*}
{CertificateVerify*}
{Finished}
<--------- [Application Data*]
{Finished} --------->
[Application Data] <--------> [Application Data]
Figure 3: TLS Server uses the IEEE 1609.2 certificate and TLS Client
uses the X 509 certificate
7. Security Considerations
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 [RFC8446] and [RFC5246] apply
here as well.
For security considerations in a vehicular environment, the minimal
use of any TLS extensions is recommended such as :
The "client_certificate_type" [IANA value 19] extension who's
purpose was previously described in [RFC7250].
The "server_certificate_type" [IANA value 20] extension who's
purpose was previously described in [RFC7250].
The "SessionTicket" [IANA value 35] extension for session
resumption.
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.
8. Privacy Considerations
For privacy considerations in a vehicular environment the use of EEE
1609.2/ETSI TS 103097 certificate is recommended for many reasons:
Kampanakis & Msahli Expires March 26, 2019 [Page 9]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
In order to address the risk of a personal data leakage, messages
exchanged for V2V communications are signed using IEEE 1609.2/ETSI
TS 103097 pseudonym certificates
The purpose of these certificates is to provide privacy relying on
geographical and/or temporal validity criteria, and minimizing the
exchange of private data
9. IANA Considerations
Existing IANA references have not been updated yet to point to this
document.
IANA is asked to register a new value in the "TLS Certificate Types"
registry of Transport Layer Security (TLS) Extensions [TLS-
Certificate-Types-Registry], as follows:
o Value: TBD Description: 1609Dot2 Reference: [THIS RFC]
10. Acknowledgements
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.
11. References
11.1. Normative References
[IEEE1609.2]
IEEE, "IEEE Standard for Wireless Access in Vehicular
Environments - Security Services for Applications and
Management Messages", 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", May 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", August 2008.
Kampanakis & Msahli Expires March 26, 2019 [Page 10]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
[RFC5746] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension"", February 2010.
[RFC7250] Wouters, P., Tschofenig, H., Weiler, S., and T. Kivinen,
"Using Raw Public Keys in Transport Layer Security (TLS)
and Datagram Transport Layer Security (DTLS)", June 2014.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", August 2018.
[TS103097]
ETSI, "ETSI TS 103 097 v1.3.1 (2017-10): Intelligent
Transport Systems (ITS); Security; Security header and
certificate formats", October 2017.
11.2. Informative References
[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.
Kampanakis & Msahli Expires March 26, 2019 [Page 11]
Internet-Draft IEEE and ETSI Certificate Types for TLS September 2018
Appendix A. Co-Authors
o Nancy Cam-Winget
CISCO, USA
[email protected]
o Maik Seewald
CISCO, USA
[email protected]
o Houda Labiod
Telecom Paristech, France
[email protected]
o Ahmed Serhrouchni
Telecom ParisTech
[email protected]
o William Whyte
OnBoard Security, Inc., USA
[email protected]
Authors' Addresses
Panos Kampanakis (editor)
Cisco
USA
EMail: EMail: [email protected]
Mounira Msahli (editor)
Telecom ParisTech
France
EMail: [email protected]
Kampanakis & Msahli Expires March 26, 2019 [Page 12]
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
