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, <http://www.blackhat.com/
presentations/bh-dc-09/Marlinspike/
BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf>.
[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]