One document matched: draft-nir-tls-keyshare-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="no"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='./rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc subcompact="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc ipr="trust200902" docName="draft-nir-tls-keyshare-00" category="std">
<front>
<title abbrev="TLS Key Sharing">A Method for Sharing Record Protocol Keys with a Middlebox in
TLS</title>
<author initials="Y." surname="Nir" fullname="Yoav Nir">
<organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
<address>
<postal>
<street>5 Hasolelim st.</street>
<city>Tel Aviv</city>
<code>67897</code>
<country>Israel</country>
</postal>
<email>ynir@checkpoint.com</email>
</address>
</author>
<date year="2011"/>
<area>Security Area</area>
<workgroup>TLS Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t> This document contains a straw man proposal for a method for sharing symmetric session
keys between a TLS client and a middlebox, so that the middlebox can decrypt the
TLS-protected traffic.</t>
<t> This method is an alternative to the middlebox becoming a proxy.</t>
</abstract>
</front>
<middle>
<!-- ====================================================================== -->
<section anchor="introduction" title="Introduction">
<t> TLS (<xref target="TLS"/>) is used in a wide variety of protocols. The most common use is
for protecting HTTP, as described in <xref target="HTTPS"/>. Middleboxes such as firewalls
scan protocols for attacks. For HTTP common attacks to scan for are cross-site scripting and
transfer of files containing malware.</t>
<t> TLS provides authentication and privacy against eavesdropping, but it hides the traffic
not only from mallicious intercepters. It also hides the traffic from the middlebox, and
prevents it from doing its job. Our goal is to allow the middlebox to inspect the traffic,
without allowing others to do the same.</t>
<t> The requirements can be summed up in the following points: <list style="symbols">
<t> The middlebox should be able to decrypt all TLS traffic, and optionally (the client's
option) also modify it.</t>
<t> The protocol must not make it easier for other entities to decrypt the traffic.</t>
<t> The client should be able to opt out of TLS decryption, but opting out may mean that
the connection is blocked.</t>
<t> The server should be able to opt out of TLS decryption, but opting out may mean that
the connection is blocked.</t></list></t>
<t> Two proposals have been offered to achieve these goals. One is having the middlebox be
a proxy, acting as server to the client, and as a client to the server. This option is
implemented in several commercial products. <xref target="proxy_server_ext"/> describes
an extension to TLS for improving that mechanism, and also contains a good description
in the introduction.</t>
<t> This document describes an alternative mechanism, where the client sends the keys to the
middlebox in the TLS record stream. This requires more changes to clients and servers, but
has the advantage that it does not break many of TLS guarantees.</t>
<section anchor="mustshouldmay" title="Conventions Used in This Document">
<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"/>.</t>
</section>
</section>
<!-- ====================================================================== -->
<section anchor="protocol" title="Protocol Overview">
<t> A supporting client will send a new extension in the ClientHello message. This new
extension is called tls_keyshare. A server that supports this extension will send the
extension in the ServerHello if it has been received in the ClientHello. Note that sending
this extension only acknowledges understanding the protocol, not agreement to decryption.
The extension may contain a sequence of SHA-256 hashes of known middlebox certificates.</t>
<t> This document defines a new record type called KeyshareInfo. This is a new content type
rather than a new handshake message so that it doesn't figure in hash calculation of the
hash message. A middlebox inserts a KeyShareInfo record into the server-to-client stream
immediately following the ServerHello message. It contains two pieces of information: <list
style="symbols">
<t> A certificate of the middlebox, or a SHA-256 hash thereof, if that hash was included in
the tls_keyshare extension. The public key in the certificate MUST be of the RSA type.</t>
<t> A signature using the private key associated with the certificate over the concatenation
of the ClientHello and ServerHello messages.</t></list></t>
<t> The middlebox inserts a KeyShareInfo record into the client-to-server stream immediately
preceding the ClientKeyExchange handshake record with a similar construction, except that
this time the signature is over all the handshake records from ClientHello to
ServerHelloDone. This is sent only if the server indicated support.</t>
<t> The client inserts a KeyShareInfo record into the client-to-server stream immediately
following the ChangeCipherSpec record (before the Finished handshake record). This
KeyShareInfo record is constructed differently, and contains an RSA encrypted record of
the write keys for both client and server. The client may send several records if there is
more than one middlebox.</t>
<t> The diagram below outlines the protocol structure.<figure>
<artwork><![CDATA[
Client Middlebox Server
------ --------- ------
ClientHello(*) -------->
ServerHello(*)
KeyShareInfo(cert,sig)
(Certificate)
ServerKeyExchange
<-------- ServerHelloDone
KeyShareInfo(cert,sig)
ClientKeyExchange
(CertificateVerify)
ChangeCipherSpec
KeyShareInfo(keys) - removed by middlebox
Finished -------->
ChangeCipherSpec
Finished
<--------
(*) The ClientHello and ServerHello include the tls_keyshare
extension to indicate support
]]></artwork>
</figure></t>
<section anchor="keyshare_ind" title="The tls_keyshare Extension">
<t> The tls_keyshare extension is a ClientHello and ServerHello extension as defined in
section 2.3 of <xref target="TLS-EXT"/>.
The extension_type field is TBA by IANA. The format is to be added.</t>
</section>
<section anchor="keyshareinfo" title="The KeyShareInfo Record">
<t> The format of the KeyShareInfo record is to be added. The content type is TBA by IANA.</t>
</section>
</section>
<section anchor="processing" title="Processing">
<section anchor="proc_client" title="Client Processing">
<t> If the client policy prohibits decryption, the client SHOULD NOT send the tls_keyshare
extension. Note that the middlebox might still try to proxy the connection, but that is
outside the scope of this document.</t>
<t> If there are some middleboxes that are by policy acceptable to the client and their
certificates are known in advance, the client MAY send the SHA-256 hashes of their
certificates in the tls_keyshare extension. </t>
<t> If a KeyShareInfo record is received with an unknown hash, it MUST be ignored.</t>
<t> If a KeyShareInfo record is received with an unknown certificate, it MAY be ignored,
or the user MAY be prompted to authorize the decryption, and optionally change the
configuration to allow future decryption by this certificate.</t>
<t> If policy dictates that the particular middlebox referenced in the KeyShareInfo record
is not allowed to decrypt, then such a record is ignored.</t>
<t> For all the middleboxes that are not ignored, the client MUST send a KeyShareInfo
record with the symmetric keys immediately following the ChangeCipherSpec record before
any protected record is sent. </t>
</section>
<section anchor="proc_server" title="Server Processing">
<t> The server SHOULD send the tls_keyshare extension even if policy dictates that the
decryption is prohibited. If a middlebox is detected, either by its KeyShareInfo record
or by the client's KeyShareInfo record, the server MAY terminate the connection with a
DECRYPTION_PROHIBITED alert.</t>
<t> The server MAY also terminate the connection with a DECRYPTION_PROHIBITED alert if it
is just the particular middlebox that is not authorized.</t>
</section>
<section anchor="proc_mb" title="Middlebox Processing">
<t> The middlebox MUST send a KeyShareInfo record to the client if the client has indicated
support for this extension. The middlebox MUST send a KeyShareInfo record to the server
if the server has indicated support for this extension. The middlebox MUST use the full
certificate format if the hash was not included in the extension, or the hash format if
it was.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t> To be added</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>To be added.</t>
</section>
<!-- ====================================================================== -->
</middle>
<!-- ====================================================================== -->
<back>
<references title="Normative References">
<reference anchor='TLS'>
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
<author initials='T.' surname='Dierks' fullname='T. Dierks'>
<organization /></author>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2008' month='August' />
</front>
<seriesInfo name='RFC' value='5246' />
<format type='TXT' target='http://tools.ietf.org/rfc/rfc5246.txt' />
<format type='HTML' target='http://tools.ietf.org/html/rfc5246' />
</reference>
<reference anchor='TLS-EXT'>
<front>
<title>Transport Layer Security (TLS) Extensions</title>
<author initials='S.' surname='Blake-Wilson' fullname='S. Blake-Wilson'>
<organization /></author>
<author initials='M.' surname='Nystrom' fullname='M. Nystrom'>
<organization /></author>
<author initials='D.' surname='Hopwood' fullname='D. Hopwood'>
<organization /></author>
<author initials='J.' surname='Mikkelsen' fullname='J. Mikkelsen'>
<organization /></author>
<author initials='T.' surname='Wright' fullname='T. Wright'>
<organization /></author>
<date year='2006' month='April' />
<abstract><t>This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.</t><t> The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa. [STANDARDS TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4366' />
<format type='TXT' octets='66344' target='http://www.ietf.org/rfc/rfc4366.txt' />
</reference>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='ftp://ftp.isi.edu/in-notes/rfc2119.txt' />
<format type='HTML' octets='16553' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5703' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
</references>
<references title="Informative References">
<reference anchor='HTTPS'>
<front>
<title>HTTP Over TLS</title>
<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
<organization>RTFM, Inc.</organization>
</author>
<date month='May' year='2000' />
</front>
<seriesInfo name='RFC' value='2818' />
<format type='TXT' target='http://www.ietf.org/rfc/rfc2818.txt' />
<format type='HTML' target='http://tools.ietf.org/html/rfc2818' />
</reference>
<reference anchor='proxy_server_ext'>
<front>
<title>TLS Proxy Server Extension</title>
<author initials='D' surname='McGrew' fullname='David A. McGrew'><organization>Cisco Systems</organization></author>
<author initials='P' surname='Gladstone' fullname='Philip Gladstonew'><organization>Cisco Systems</organization></author>
<date month='July' day='4' year='2011' />
</front>
<seriesInfo name='Internet-Draft' value='draft-mcgrew-tls-proxy-server-00' />
<format type='TXT' target='http://www.ietf.org/internet-drafts/draft-mcgrew-tls-proxy-server-00.txt' />
</reference>
</references>
<!-- ====================================================================== -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:02:26 |