TLS Out-of-Band Public Key Validation
draft-ietf-tls-oob-pubkey-00.txt

Abstract

This document specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band authentication. Currently, TLS authentication can only occur via PKIX or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative authentication methods.

One such method is using DANE Resource Records secured by DNSSEC, Another use case is to provide authentication functionality when used with devices in a constrained environment that use whitelists and blacklists, as is the case with sensors and other embedded devices that are constrained by memory, computational, and communication limitations where the usage of PKIX is not feasible.

The new certificate type specified can also be used to reduce the latency of a TLS client that is already in possession of a validated public key of the TLS server before it starts a (non-resumed) TLS handshake.

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 April 19, 2013.

Copyright Notice

Copyright (c) 2012 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 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.

Table of Contents

• 1. Introduction
• 1.1. Motivation
• 1.2. Applicability
• 1.3. Terminology
• 2. Changes to the Handshake Message Contents
• 2.1. Client Hello
• 2.2. Server Hello
• 2.3. Certificate Request
• 2.4. Other Handshake Messages
• 3. Security Considerations
• 4. IANA Considerations
• 5. Contributors
• 6. Acknowledgements
• 7. References
• 7.1. Normative References
• 7.2. Informative References
• Authors' Addresses

1. Introduction

1.1. Motivation

Traditionally, TLS server public keys are obtained in PKIX containers in-band using the TLS connection and validated using trust anchors based on a [PKIX] certification authority (CA). This method can add a complicated trust relationship that is difficult to validate. Examples of such complexity can be seen in [Defeating-SSL].

Alternative methods are available that allow a TLS client to obtain the TLS server public key:

• The TLS server public key is obtained from a DNSSEC secured RRset using [DANE]
• The TLS server public key is obtained from a [PKIX] certificate chain from an [LDAP] server
• The TLS server public key is provisioned by the operating system and updated via software updates
• A TLS client has connected to the TLS server before and has cached the TLS server certificate chain or TLS server public key for re-use

[RFC5246] does not provide a mechanism for a TLS client to tell the TLS server it is already in possession of the authenticated public key. Therefore, a TLS server must always send a list of trusted CA keys and its EE certificate containing its public key, even when the TLS client does not require or desire that data for authentication.

[RFC6066] allows suppression of the certificate trust anchor chain, but not suppression of the PKIX EE certificate container. These certificate chains are large opaque blocks of data containing much more than the public key of the TLS server. Since the TLS client might only be able to validate the PKIX SubjectPublicKeyInfo via an out-of-band method such as [DANE], it has to ignore any additional information received that was sent by the server that it could not validate. Furthermore, information that comes in via these certificate chains could contain contradicting or additional information that the TLS client cannot validate or trust, such as an expiry date that conflicts with information obtained from DNS or LDAP. This document specifies a method to suppress sending this additional information.

Some small embedded devices use the UDP based [CoAP], a specialized constrained networks and nodes for machine-to-machine applications. These devices interact with a Web server to upload data such as temperature sensor readings at a regular intervals. Constrained Application Protocol (CoAP) [CoAP] can utilize DTLS for its communication security. As part of the provisioning procedure, the embeded device is configured with the address and public key of a dedicated CoAP server to upload sensor data. Receiving PKIX information [PKIX] from a webserver would be an unneccesarry burden on a sensor networking deployment environment that requires pre-configured client-server public keys. These devices often also lack a real-time clock to perform any PKIX epixry checks.

1.2. Applicability

The Transport Layer Security (TLS) Protocol Version 1.2 is specified in [RFC5246] and provides a framework for extensions to TLS as well as considerations for designing such extensions. [RFC6066] defines several new TLS extensions. This document extends the specifications of those RFCs with one new TLS Certificate Type to facilitate suppressing unneeded [PKIX] information from being sent during the TLS handshake when this information is not required to authenticate the TLS server.

1.3. Terminology

Most security-related terms in this document are to be understood in the sense defined in [SECTERMS]; such terms include, but are not limited to, "attack", "authentication", "authorization", "certification authority", "certification path", "certificate", "credential", "identity", "self-signed certificate", "trust", "trust anchor", "trust chain", "validate", and "verify".

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 RFC 2119 [RFC2119].

2. Changes to the Handshake Message Contents

This section describes the changes to the TLS handshake message contents when raw public keys are to be used for authentication. Figure 1 illustrates the exchange of messages as described in the sub-sections below. The new "RawPublicKey" value in the cert_type extension indicates the ability and desire to exchange raw public keys, which are then exchanged as part of the certificate payloads.

 
 client_hello, 
 cert_type="RawPublicKey" ->

                           <-  server_hello,
                               cert_type="RawPublicKey",
                               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

    
enum { client, server } ClientOrServerExtension;

enum { X.509(0), OpenPGP(1), 
   RawPublicKey([TBD]), 
   (255) } CertificateType;

struct {
   select(ClientOrServerExtension) 
       case client:
         CertificateType certificate_types<1..2^8-1>;
       case server:
         CertificateType certificate_type;
   }
} CertificateTypeExtension;