One document matched: draft-wouters-tls-oob-pubkey-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="no" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-wouters-tls-oob-pubkey-00" ipr="trust200902">
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="TLS oob pubkey">TLS Extension for out-of-band public key validation
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Paul Wouters" initials="P." surname="Wouters">
<organization>Xelerance</organization>
<address>
<postal>
<street>4130 Ramsayville Road</street>
<city>Ottawa</city>
<region>On</region>
<code>K1G 3N4</code>
<country>Canada</country>
</postal>
<phone>+1-647-722-5653</phone>
<email>paul@xelerance.com</email>
<uri>https://www.xelerance.com/</uri>
</address>
</author>
<author fullname="John Gilmore" initials="J." surname="Gilmore">
<organization></organization>
<address>
<postal>
<street>PO Box 170608</street>
<city>San Francisco</city>
<region>California</region>
<code>94117</code>
<country>USA</country>
</postal>
<phone>+1 415 221 6524</phone>
<email>gnu@toad.com</email>
<uri>https://www.toad.com/</uri>
</address>
</author>
<author fullname="Sam Weiler" initials="S." surname="Weiler">
<organization>SPARTA, Inc.</organization>
<address>
<postal>
<street>7110 Samuel Morse Drive</street>
<city>Columbia, Maryland</city>
<code>21046</code>
<country>US</country>
</postal>
<email>weiler@tislabs.com</email>
</address>
</author>
<date month="July" year="2011" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>Applications</area>
<workgroup>IETF</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>TLS</keyword>
<keyword>DNSSEC</keyword>
<keyword>DANE</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<section title="Motivation" anchor="motivation">
<t>Traditionally, TLS server public keys are obtained in PKIX containers
in-band using the TLS connection and validated using trust anchors
based on a <xref target='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
<xref target='Defeating-SSL'/>.</t>
<t>Alternative methods are available that allow a TLS client to obtain
the TLS server public key:</t>
<t><list style="symbols">
<t>The TLS server public key is obtained from a <xref target='PKIX'/>
certificate chain from an <xref target="LDAP"/> server</t>
<t>The TLS server public key is obtained from a DNSSEC secured RRset
using <xref target='DANE'/></t>
<t>The TLS server public key is provisioned by the operating system
and updated via software updates</t>
<t>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</t>
</list>
</t>
<t><xref target='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.</t>
<t><xref target='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.</t>
</section>
<section title="Applicability" anchor="applicability">
<t>The Transport Layer Security (TLS) Protocol Version 1.2 is specified
in <xref target="RFC5246">RFC 5246</xref>. RFC 5246 also provides
a framework for extensions to TLS as well as considerations for
designing such extensions. <xref target="RFC6066">RFC 6066</xref>
defines several new TLS extensions. This document extends the
specifications of those RFCs with one new TLS extension to facilitate
suppressing unneeded <xref target='PKIX'/> information from being sent
during the TLS handshake when this information is not required
to authenticate the TLS server.</t>
</section>
<section title="Terminology" anchor="terminology">
<t>Most security-related terms in this document are to be understood in the
sense defined in <xref target="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".</t>
<t>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 <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section title="Specific Extension Covered">
<t>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.</t>
<t>The extension type is defined in this document are:
<figure><artwork><![CDATA[
enum {
oob_pubkey_list([TBD]) (65535)
} ExtensionType;
]]></artwork></figure>
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.
</t>
<t>TLS clients and TLS servers may use the extension described in this
document. The extension is designed to be backwards compatible,
meaning that TLS clients that support the extension can talk to TLS
servers that do not support the extension, and vice versa.</t>
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="TLS extension specifying Out-of-band public key retrieval">
<t>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:</t>
<figure><artwork><![CDATA[
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;
]]></artwork></figure>
<t>In each entry in the list, the client can either include the full public
key, in the form of a subjectPublicKeyInfo
(see <xref target="RFC2528">RFC 2528</xref> and
<xref target="RFC5480">RFC 5480</xref>) or a SHA-256 hash of the
subjectPublicKeyInfo. The PublicKeyList MUST contain at least one PublicKey
entry.</t>
<t>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.</t>
<t>If the TLS server responds with an extension of type "oob_pubkey_list",
it SHOULD omit sending a "Server Certificate" message.</t>
<t>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.</t>
</section>
<section title="Security Considerations" anchor="security">
<t>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.</t>
<t>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.</t>
<t>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 <xref target="DANE"/>
it is appropriate to use DNSSEC to authenticate the public keys.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>We request that IANA assign a TLS Extension Type value for oob_pubkey_list</t>
</section>
<section title="Contributors" anchor="contributors">
<t>The following individuals made important contributions to this document: Paul Hoffman.</t>
</section>
<section title="Acknowledgements" anchor="acknowledgements">
<t>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.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2528.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5480.xml"?>
<reference anchor='PKIX'>
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
<author initials='D.' surname='Cooper' fullname='D. Cooper'>
<organization /></author>
<author initials='S.' surname='Santesson' fullname='S. Santesson'>
<organization /></author>
<author initials='S.' surname='Farrell' fullname='S. Farrell'>
<organization /></author>
<author initials='S.' surname='Boeyen' fullname='S. Boeyen'>
<organization /></author>
<author initials='R.' surname='Housley' fullname='R. Housley'>
<organization /></author>
<author initials='W.' surname='Polk' fullname='W. Polk'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5280' />
<format type='TXT' octets='352580' target='ftp://ftp.isi.edu/in-notes/rfc5280.txt' />
</reference>
<reference anchor='SECTERMS'>
<front>
<title>Internet Security Glossary, Version 2</title>
<author initials='R.' surname='Shirey' fullname='R. Shirey'>
<organization /></author>
<date year='2007' month='August' />
<abstract>
<t>This Glossary provides definitions, abbreviations, and
explanations of terminology for information system security.
The 334 pages of entries offer recommendations to improve the
comprehensibility of written material that is generated in the
Internet Standards Process (RFC 2026). The recommendations
follow the principles that such writing should (a) use the same
term or definition whenever the same concept is mentioned; (b)
use terms in their plainest, dictionary sense; (c) use terms that
are already well-established in open publications; and (d) avoid
terms that either favor a particular vendor or favor a particular
technology or mechanism over other, competing techniques
that already exist or could be developed. This memo provides
information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='4949' />
<format type='TXT' octets='867626' target='ftp://ftp.isi.edu/in-notes/rfc4949.txt' />
</reference>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6066.xml"?>
<reference anchor='LDAP'>
<front>
<title>Lightweight Directory Access Protocol (LDAP): The Protocol</title>
<author initials='J.' surname='Sermersheim' fullname='J. Sermersheim'>
<organization /></author>
<date year='2006' month='June' />
<abstract>
<t>This document describes the protocol elements, along with
their semantics and encodings, of the Lightweight Directory
Access Protocol (LDAP). LDAP provides access to distributed
directory services that act in accordance with X.500 data
and service models. These protocol elements are based
on those described in the X.500 Directory Access Protocol
(DAP). [STANDARDS TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='4511' />
<format type='TXT' octets='150116' target='ftp://ftp.isi.edu/in-notes/rfc4511.txt' />
</reference>
<reference anchor='DANE'>
<front>
<title>Using Secure DNS to Associate Certificates with Domain Names For TLS</title>
<author initials='P' surname='Hoffman' fullname='Paul Hoffman'>
<organization />
</author>
<author initials='J' surname='Schlyter' fullname='J. Schlyter'>
<organization />
</author>
<date month='July' day='1' year='2011' />
<abstract><t>TLS and DTLS use certificates for authenticating the server. Users
want their applications to verify that the certificate provided by
the TLS server is in fact associated with the domain name they
expect. DNSSEC provides a mechanism for a zone operator to sign DNS
information directly. This way, bindings of keys to domains are
asserted not by external entities, but by the entities that operate
the DNS. This document describes how to use secure DNS to associate
the TLS server's certificate with the intended domain name.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-dane-protocol-08' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-dane-protocol-08.txt' />
</reference>
<reference anchor='Defeating-SSL' target='http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf'>
<front>
<title>New Tricks for Defeating SSL in Practice</title>
<author initials='M.' surname='Marlinspike' fullname='Moxie Marlinspike'>
<organization /></author>
<date year='2009' month='February' />
</front>
<format type='PDF' target='http://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 09:00:29 |