IETF P. Wouters Internet-Draft Xelerance Intended status: Standards Track J. Gilmore Expires: January 5, 2012 S. Weiler SPARTA, Inc. July 4, 2011 TLS Extension for out-of-band public key validation draft-wouters-tls-oob-pubkey-00 Abstract This document specifies a new TLS extension as well as modified TLS client and TLS server behaviour when public keys are authenticated out-of-band to the current TLS connection. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The new extension specified is "oob_pubkey_list" which can be used when the TLS client is already in possession of a validated public key of the TLS server before it starts the 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 January 5, 2012. Copyright Notice Copyright (c) 2011 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 Wouters, et al. Expires January 5, 2012 [Page 1] Internet-Draft TLS oob pubkey July 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Specific Extension Covered . . . . . . . . . . . . . . . . 4 2. TLS extension specifying Out-of-band public key retrieval . . . 5 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Wouters, et al. Expires January 5, 2012 [Page 2] Internet-Draft TLS oob pubkey July 2011 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: o The TLS server public key is obtained from a [PKIX] certificate chain from an [LDAP] server o The TLS server public key is obtained from a DNSSEC secured RRset using [DANE] o The TLS server public key is provisioned by the operating system and updated via software updates o 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 opague blocks of data containing much more then 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, it has to explicitly forget 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. Wouters, et al. Expires January 5, 2012 [Page 3] Internet-Draft TLS oob pubkey July 2011 1.2. Applicability The Transport Layer Security (TLS) Protocol Version 1.2 is specified in RFC 5246 [RFC5246]. RFC 5246 also provides a framework for extensions to TLS as well as considerations for designing such extensions. RFC 6066 [RFC6066] defines several new TLS extensions. This document extends the specifications of those RFCs with one new TLS extension 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]. 1.4. Specific Extension Covered The extension described here describes a method for the TLS client to instruct the TLS server to omit sending the PKIX End Entity certificate and trusted root CA certificates. The extension type is defined in this document are: enum { oob_pubkey_list([TBD]) (65535) } ExtensionType; Specifically, the extension described in this document allows a TLS client to indicate to TLS servers that it already has a trusted copy of one or more of the TLS server's public keys. Since the TLS server can have multiple public keys for a TLS connection, the TLS client sends the TLS server a set of public keys or hashes of public keys. The TLS server responds with sending the oob_pubkey_list back containing the preferred public key or hash thereof, selected from the client's proposed list. TLS clients and TLS servers may use the extension described in this document. The extension is designed to be backwards compatible, Wouters, et al. Expires January 5, 2012 [Page 4] Internet-Draft TLS oob pubkey July 2011 meaning that TLS clients that support the extension can talk to TLS servers that do not support the extension, and vice versa. Note that any messages associated with this extension that are sent during the TLS handshake MUST be included in the hash calculations involved in "Finished" messages. Note also that the extension defined in this document is relevant only when a session is initiated. A client that requests session resumption does not in general know whether the server will accept this request, and therefore it SHOULD send the same extension as it would send if it were not attempting resumption. When a client includes the defined extension type in an extended ClientHello while requesting session resumption, the server MUST, when agreeing to resume the older session, ignore the extension and send a ServerHello that does not contain the extension. In this case, the functionality of this extension negotiated during the original session initiation is applied to the resumed session. If the resumption request is denied, the use of the extension is negotiated as normal. 2. TLS extension specifying Out-of-band public key retrieval In order to indicate which server public keys they trust, clients MAY include an extension of type "oob_pubkey_list" in the (extended) ClientHello. The "extension_data" field of this extension SHALL contain "PublicKeyList" where: struct { IdentifierType identifier_type; select (identifier_type) { case key_raw_pubkey: subjectPublicKeyInfo; case key_sha256_hash: SHA256Hash; } identifier; } PublicKey; enum { key_raw_pubkey(0), key_sha1_hash(1) (255) } IdentifierType; opaque subjectPublicKeyInfo<1..2^16-1>; opaque SHA256Hash<32>; struct { PublicKey public_key_list<1..2^16-1> } PublicKeyList; Wouters, et al. Expires January 5, 2012 [Page 5] Internet-Draft TLS oob pubkey July 2011 In each entry in the list, the client can either include the full public key, in the form of a subjectPublicKeyInfo (see RFC 2528 [RFC2528] and RFC 5480 [RFC5480]) or a SHA-256 hash of the subjectPublicKeyInfo. The PublicKeyList MUST contain at least one PublicKey entry. The TLS server MAY respond with an extension of type "oob_pubkey_list" in the (extended) server hello. The "extension_data" field of this extension SHALL contain "PublicKeyList" containing exactly one of the "PublicKey" identifiers used in the received client hello message. It SHALL use the same IdentifierType as the TLS client used to send the identifier to the TLS server. It MUST NOT send and empty PublicKeyList. If the TLS server responds with an extension of type "oob_pubkey_list", it SHOULD omit sending a "Server Certificate" message. If the TLS server does not respond with an extension of type "oob_pubkey_list", the TLS client MUST assume the extension is not supported. The TLS client MAY fall back to using in-band PKIX validation. If the TLS client cannot fallback to PKIX authentication, it MUST abort the TLS handshake. 3. Security Considerations The TLS extension defined here lets a TLS client attempt to supress the sending of server certificate as well as the certification chain for that certificate. A client using this extension needs to be confident in the authenticity of the public key it is using. Since those public keys were obtained out-of-band (hence the name of the extension), the authentication must also be out-of-band. Depending on exactly how the public keys were obtained, it may be appropriate to use authentication mechanisms tied to the public key transport. For example, if public keys were obtained using [DANE] it is appropriate to use DNSSEC to authenticate the public keys. 4. IANA Considerations We request that IANA assign a TLS Extension Type value for oob_pubkey_list Wouters, et al. Expires January 5, 2012 [Page 6] Internet-Draft TLS oob pubkey July 2011 5. Contributors The following individuals made important contributions to this document: Paul Hoffman. 6. 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 Farrel. 7. References 7.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. [RFC2528] Housley, R. and T. Polk, "Internet X.509 Public Key Infrastructure Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates", RFC 2528, March 1999. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009. [SECTERMS] Shirey, R., "Internet Security Glossary, Version 2", RFC 4949, August 2007. 7.2. Informative References [DANE] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names For TLS", draft-ietf-dane-protocol-08 (work in progress), July 2011. Wouters, et al. Expires January 5, 2012 [Page 7] Internet-Draft TLS oob pubkey July 2011 [Defeating-SSL] Marlinspike, M., "New Tricks for Defeating SSL in Practice", February 2009, . [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. Authors' Addresses Paul Wouters Xelerance 4130 Ramsayville Road Ottawa, On K1G 3N4 Canada Phone: +1-647-722-5653 Email: paul@xelerance.com URI: https://www.xelerance.com/ John Gilmore PO Box 170608 San Francisco, California 94117 USA Phone: +1 415 221 6524 Email: gnu@toad.com URI: https://www.toad.com/ Sam Weiler SPARTA, Inc. 7110 Samuel Morse Drive Columbia, Maryland 21046 US Email: weiler@tislabs.com Wouters, et al. Expires January 5, 2012 [Page 8]