TLS Working Group M. Badra Internet-Draft H. Labiod Intended status: Standards Track B. Lonc Expires: August 18, 2014 F. Lonc A. Serhrouchni February 14, 2014 Transport Layer Security (TLS) Client authentication Using IEEE 1609-2 Certificate draft-lonc-tls-certieee1609-00.txt Abstract This document describes two types of certificates to authenticate TLS entities, the first type enables the use of a certificate specified by the Institute of Electrical and Electronics Engineers (IEEE) and the second by the European Telecommunications Standards Institute (ETSI). This document defines a new extension to enable TLS entities authentication using one of the aforementioned certificate types. 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 http://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 August 18, 2014. Copyright Notice Copyright (c) 2014 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 (http://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 xxxxxxxxxxxxxxxxxxx Expires August 18, 2014 [Page 1] Internet-Draft IEEE and IETS Certificate Types for TLS February 2014 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. Comments are solicited and should be addressed to the authors at francois.lonc@telecom-paristech.fr. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Conventions Used in This Document . . . . . . . . . . . . 2 2. Extension Overview . . . . . . . . . . . . . . . . . . . . . 2 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Normative References . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction Usually, TLS uses X509 digital certificates [RFC5246] for authentication. This document describes how to use a certificate specified by the Institute of Electrical and Electronics Engineers (IEEE) [IEEE-ITS] or a certificate described by the European Telecommunications Standards Institute (ETSI) [ETSI-ITS]. 1.1. Conventions Used in This Document 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]. 2. Extension Overview In order to negotiate the use of IEEE or ETSI certificate-based authentication, clients MAY include an extension of type "accepted_and_supported_certificate_type" in the extended client hello. The "extension_data" field of this extension SHALL contain a list of supported certificate types advertised by the client, where: enum { ieee(0), ets(1), x509(2), (255) } SupportedCertType; enum { ieee(0), etsi(1), x509(2), (255) } AcceptedCertType; xxxxxxxxxxxxxxxxxxxxxx Expires August 18, 2014 [Page 2] Internet-Draft IEEE and IETS Certificate Types for TLS February 2014 struct { SupportedClientCertType supported_certificate_types<1..2^8-1>; AcceptedClientCertType accepted_certificate_types<1..2^8-1>; } SupportedAndAcceptedCertType; DistinguishedName certificate_authorities<0..2^16-1>; Supported_certificate_types A list of certificate types types that the client may support. Accepted_certificate_types A list of certificate types that the client may accept. certificate_authorities A list of the distinguished names as described in [RFC5246] If the TLS server is willing to accept using the extension described here, it selects one of the supported certificate types and one of the accepted certificate types and includes a certificate_authorities list in the extension described here. The CertificateRequest payload is omitted from the response. The same extension type and structure will be used for the server's response to the extension described here. Note that a server MAY send no certificate types if it either does not have an appropriate certificate to send in response to the extension defined here or it wishes to authenticate the client using other authentication methods. The client MAY at its discretion either continue the handshake, or respond with a fatal handshake_failure alert. The end-entity certificate's public key (and associated restrictions) has to be compatible with the certificate types listed in extension described here. At the end of the hello phase, the client generates the pre_master_secret, encrypts it under the server's public key, and sends the result to the server. For servers aware of the extension described here but not wishing to use it, it will gracefully revert to an ordinary TLS handshake or stop the negotiation. Clients return a response along with their certificates by sending the "Certificate" message and immediately after the "ClientKeyExchange" message. The premaster secret is generated according to the cipher algorithm selected by the server in the ServerHello.cipher_suite. xxxxxxxxxxxxxxxxxxxxx Expires August 18, 2014 [Page 3] Internet-Draft IEEE and IETS Certificate Types for TLS February 2014 3. Security Considerations The security considerations described throughout [RFC5246] apply here as well. 4. IANA Considerations This document defines a new TLS extension "accepted_and_supported_certificate_type", assigned the value TBD from the TLS ExtensionType registry defined in [TLSEXT]. 5. Normative References [ETSI-ITS] ETSI-TS-103-097 v1.1.1 (2013-4): Intelligent Transport Systems (ITS); Security; Security header and certificate format, "http://www.etsi.org/deliver/etsi_ts/103000_103099/103097/ 01.01.01_60/ts_103097v010101p.pdf", . [IEEE-ITS] IEEE Std 1609.2, "IEEE Standard for Wireless Access in Vehicular Environments - Security Services for Applications and Management Messages", 2013. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [TLSEXT] Eastlake, D., 3rd, "Transport Layer Security (TLS) Extensions: Extension Definitions", Work in Progress, February 2008. xxxxxxxxxxxxxxxxxxxxxxx Expires August 18, 2014 [Page 4] Internet-Draft IEEE and IETS Certificate Types for TLS February 2014 Authors' Addresses Mohammed Badra LIMOS CNRS Email: badra@isima.fr Houda Labiod Telecom Paristech 46 rue Barrault 75634 Paris cedex 13 France Email: houda.labiod@telecom-paristech.fr Brigitte Lonc Renault Email: brigitte.lonc@renault.com Francois Lonc Telecom Paristech 46 rue Barrault 75634 Paris cedex 13 France Email: francois.lonc@telecom-paristech.fr Ahmed Serhrouchni Telecom Paristech 46 rue Barrault 75634 Paris cedex 13 France Email: ahmed.serhrouchni@telecom-paristech.fr xxxxxxxxxxxxxxxxxxxxxxx Expires August 18, 2014 [Page 5]