TLS                                                           P. Wouters
Internet-Draft                                       No Hats Corporation
Intended status: Standards Track                              J. Gilmore
Expires: July 10, September 12, 2012
                                                               S. Weiler
                                                            SPARTA, Inc.
                                                              T. Kivinen
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                        January 20,
                                                          March 11, 2012

                 TLS Out-of-Band Public Key Validation


   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. public key validation.
   Currently, TLS authentication can only occur via PKIX X.509-based Public
   Key Infrastructure (PKI) or OpenPGP certificates.  By specifying a
   minimum resource for raw public key exchange, implementations can use
   alternative authentication public key validation methods.

   One such alternative public key valiation method is using DANE Resource Records secured offered by DNSSEC, the
   DNS-Based Authentication of Named Entities (DANE) together with DNS
   Security.  Another use case alternative is to provide authentication functionality when used
   with devices in a constrained environment that use whitelists and
   blacklists, utilize pre-configured keys, 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. devices.  The new certificate type specified can also be used to reduce the
   latency usage of a TLS client that is already in possession
   raw public keys, instead of X.509-based certificates, leads to a validated
   smaller code footprint.

   The support for raw public key of the keys is introduced into TLS server before it starts via a (non-resumed) TLS
   handshake. new non-
   PKIX certificate type.

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

   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 July 10, September 12, 2012.

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
   ( 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  . . . . . . . . . . . . . . . . . . . . . . . . . 4
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Applicability  . . . . . . . . .
   2.  Terminology . . . . . . . . . . . . .  5
     1.3.  Terminology . . . . . . . . . . . . . 4
   3.  TLS Handshake Extension . . . . . . . . . .  5
   2.  Changes to the Handshake Message Contents . . . . . . . . . . 5
     3.1.  Client Hello  . . . . . . . . . . . . . . . . . . . . . . .  6
     2.2. 5
     3.2.  Server Hello  . . . . . . . . . . . . . . . . . . . . . . .  7
     2.3. 6
     3.3.  Certificate Request . . . . . . . . . . . . . . . . . . . . 7
     3.4.  Other Handshake Messages  . . . . . . . . . . . . . . . . .  8
   3. 7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  8
   4. . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  8
   5. . 7
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1. 8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . .  9
     7.2. 8
     8.2.  Informative References  . . . . . . . . . . . . . . . . . .  9 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 10 9

1.  Introduction

1.1.  Motivation

   Traditionally, TLS server public keys are obtained in PKIX containers
   in-band using the TLS connection handshake 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:

   o  The TLS server public key is obtained from a DNSSEC secured RRset
      resource records using [DANE] DANE [I-D.ietf-dane-protocol].

   o  The TLS server public key is obtained from a [PKIX] certificate
      chain from an Lightweight Directory Access Protocol (LDAP) [LDAP] server

   o  The TLS client and server public key is provisioned by into the
      operating system firmware image, and updated via software updates

   o  A TLS client has connected to the TLS server before and has cached updates.

   Some smart objects use the TLS server certificate chain or TLS UDP-based Constrained Application Protocol
   (CoAP) [I-D.ietf-core-coap] to interact with a Web server public key for re-

   [RFC5246] does not provide to upload
   sensor data at a mechanism regular intervals, such as temperature readings.
   CoAP [I-D.ietf-core-coap] can utilize DTLS for a TLS client to tell securing the
   TLS server it is already in possession client-
   to-server communication.  As part of the authenticated manufacturing process, the
   embeded device may be configured with the address and the public
   key.  Therefore, a TLS server must always send a list key
   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 dedicated CoAP server, as well 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 for the client
   itself.  The usage of a
   dedicated CoAP server to upload sensor data.  Receiving X.509-based PKIX
   information certificates [PKIX] from a webserver may not
   suit all smart object deployments and would therefore 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 burden.

   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 guidelines for
   designing such extensions.  [RFC6066] defines
   several new TLS extensions.  This document extends uses the specifications
   of those RFCs with one new TLS Certificate
   Type extension point 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. define a new non-X.509 certificate type for
   carrying raw public keys.

2.  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",
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Changes to the

3.  TLS Handshake Message Contents Extension

   This section describes the changes to the TLS handshake message
   contents when raw public keys key certificates are to be used for authentication. used.  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.  Note that
   the certificate payloads only contain the SubjectPublicKeyInfo
   structure instead of the entire certificate.

    cert_type="RawPublicKey" ->

                              <-  server_hello,

    finished                  ->

                              <- change_cipher_spec,

   Application Data        <------->     Application Data

                      Figure 1: Example Message Flow


3.1.  Client Hello

   In order to indicate the support of out-of-band raw public keys,
   clients MUST include an extension of type "cert_type" to the extended
   client hello message.  The "cert_type" TLS extension, which is
   defined in [RFC6091], is assigned the value of 9 from the TLS
   ExtensionType registry.  This value is used as the extension number
   for the extensions in both the client hello message and the server
   hello message.  The hello extension mechanism is described in

   The "cert_type" TLS extension carries a list of supported certificate
   types the client can use, sorted by client preference.  This
   extension MUST be omitted if the client only supports X.509
   certificates.  The "extension_data" field of this extension contains
   a CertificateTypeExtension structure.  Note that the
   CertificateTypeExtension structure is being used both by the client
   and the server, even though the structure is only specified once in
   this document.

   The [RFC6091] defined CertificateTypeExtension is extended as

   enum { client, server } ClientOrServerExtension;

   enum { X.509(0), OpenPGP(1),
      (255) } CertificateType;

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

   No new cipher suites are required to use raw public keys.  All
   existing cipher suites that support a key exchange method compatible
   with the defined extension can be used.


3.2.  Server Hello

   If the server receives a client hello that contains the "cert_type"
   extension and chooses a cipher suite then two outcomes are possible.
   The server MUST either select a certificate type from the
   CertificateType field in the extended client hello or terminate the
   session with a fatal alert of type "unsupported_certificate".

   The certificate type selected by the server is encoded in a
   CertificateTypeExtension structure, which is included in the extended
   server hello message using an extension of type "cert_type".  Servers
   that only support X.509 certificates MAY omit including the
   "cert_type" extension in the extended server hello.

   If the negotiated certificate type is RawPublicKey the TLS server
   MUST send a CertificateTypeExtension place the SubjectPublicKeyInfo structure with a PKIX [PKIX]
   certificate containing ONLY into the SubjectPublicKeyInfo. Certificate
   payload.  The public key MUST match the selected key exchange


3.3.  Certificate Request

   The semantics of this message remain the same as in the TLS
   specification.  However, if this message is sent, and the negotiated
   certificate type is RawPublicKey, the "certificate_authorities" list
   MUST be empty.


3.4.  Other Handshake Messages

   All the other handshake messages are identical to the TLS


4.  Security Considerations

   The TLS cert_type extension defined here lets a TLS client attempt to
   supress the sending transmission of server certificate as well raw public keys, as the
   certification chain for that certificate.

   A client using this cert_type needs to be confident described in this document,
   provides benefits by lowering the
   authenticity over-the-air transmission overhead
   since raw public keys are quite naturally smaller than an entire
   certificate.  There are also advantages from a codesize point of view
   for parsing and processing these keys.  The crytographic procedures
   for assocating the public key it is using.  Since those public keys
   were obtained out-of-band extension), with the authentication must possession of a private key
   also be

   Depending on exactly follows standard procedures.

   The main security challenge is, however, how to associate the public keys were obtained, it may
   key with a specific entity.  This information will be
   appropriate to use authentication mechanisms tied needed to make
   authorization decisions.  Without a secure binding, man-in-the-middle
   attacks may be the public key
   transport.  For example, if consequence.  This document assumes that such
   binding can be made out-of-band and we list a few examples in
   Section 1.  DANE [I-D.ietf-dane-protocol] offers one such approach.
   If public keys were are obtained using [DANE] it DANE, these public keys are
   authenticated via DNSSEC.  Pre-configured keys is appropriate another out of band
   method for authenticating raw public keys.  While pre-configured keys
   are not suitable for a generic Web-based e-commerce environment such
   keys are a reasonable approach for many smart object deployments
   where there is a close relationship between the software running on
   the device and the server-side communication endpoint.  Regardless of
   the chosen mechanism for out-of-band public key validation an
   assessment of the most suitable approach has to use DNSSEC be made prior to authenticate the public keys.

   start of a deployment to ensure the security of the system.

5.  IANA Considerations

   We request that

   This document requests IANA to assign a TLS cert_type value for

5.  The cert_type registry is established with [RFC6091].

6.  Contributors

   The following individuals made important contributions to this
   document: Paul Hoffman.


7.  Acknowledgements

   This document is based on material from RFC 6066 for which the author
   is Donald Eastlake 3rd.  Contributions to that document also include
   Joseph Salowey, Alexey Melnikov, Peter Saint-Andre, and Adrian

   The feedback from the TLS working group meeting at IETF#81 has
   substantially shaped the document and we would like to thank the
   meeting participants for their input.  The support for hashes of
   public keys has been removed moved to [I-D.ietf-tls-cached-info] after the
   discussions at the IETF#82 meeting and the feedback from Eric


   We would like to thank Martin Rex, Bill Frantz, Zach Shelby, Carsten
   Bormann, Cullen Jennings, Rene Struik, Alper Yegin, and Jim Schaad.

8.  References


8.1.  Normative References

   [PKIX]     Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [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.

              Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.


8.2.  Informative References

   [CoAP]     Shelby, Z., Hartke, K.,

              Marlinspike, M., "New Tricks for Defeating SSL in
              Practice", February 2009, <

              Frank, B., Bormann, C., Hartke, K., and B. Frank, Z. Shelby,
              "Constrained Application Protocol",
              draft-ietf-core-coap-07 Protocol (CoAP)",
              draft-ietf-core-coap-08 (work in progress), July October 2011.


              Hoffman, P. and J. Schlyter, "Using Secure DNS to
              Associate Certificates with Domain Names For TLS",
              draft-ietf-dane-protocol-14 "The DNS-Based Authentication
              of Named Entities (DANE) Protocol for Transport Layer
              Security (TLS)", draft-ietf-dane-protocol-18 (work in
              September 2011.

              Marlinspike, M., "New Tricks for Defeating SSL March 2012.

              Santesson, S. and H. Tschofenig, "Transport Layer Security
              (TLS) Cached Information Extension",
              draft-ietf-tls-cached-info-11 (work in
              Practice", February 2009, <
              BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>. progress),
              December 2011.

   [LDAP]     Sermersheim, J., "Lightweight Directory Access Protocol
              (LDAP): The Protocol", RFC 4511, June 2006.

   [RFC6066]  Eastlake, D., "Transport Layer Security (TLS) Extensions:
              Extension Definitions", RFC 6066, January 2011.

   [RFC6091]  Mavrogiannopoulos, N. and D. Gillmor, "Using OpenPGP Keys
              for Transport Layer Security (TLS) Authentication",
              RFC 6091, February 2011.

Authors' Addresses

   Paul Wouters
   No Hats Corporation


   John Gilmore
   PO Box 170608
   San Francisco, California  94117

   Phone: +1 415 221 6524

   Samuel Weiler
   SPARTA, Inc.
   7110 Samuel Morse Drive
   Columbia, Maryland  21046

   Tero Kivinen
   Eerikinkatu 28
   HELSINKI  FI-00180


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600

   Phone: +358 (50) 4871445