TLS Working Group Y. Nir
Internet-Draft Check Point
Intended status: Standards Track August 25, 2011
Expires: February 26, 2012
A Method for Sharing Record Protocol Keys with a Middlebox in TLS
draft-nir-tls-keyshare-00
Abstract
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.
This method is an alternative to the middlebox becoming a proxy.
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 February 26, 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
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.
Nir Expires February 26, 2012 [Page 1]
Internet-Draft TLS Key Sharing August 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The tls_keyshare Extension . . . . . . . . . . . . . . . . 5
2.2. The KeyShareInfo Record . . . . . . . . . . . . . . . . . 5
3. Processing . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Client Processing . . . . . . . . . . . . . . . . . . . . 6
3.2. Server Processing . . . . . . . . . . . . . . . . . . . . 6
3.3. Middlebox Processing . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Nir Expires February 26, 2012 [Page 2]
Internet-Draft TLS Key Sharing August 2011
1. Introduction
TLS ([TLS]) is used in a wide variety of protocols. The most common
use is for protecting HTTP, as described in [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.
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.
The requirements can be summed up in the following points:
o The middlebox should be able to decrypt all TLS traffic, and
optionally (the client's option) also modify it.
o The protocol must not make it easier for other entities to decrypt
the traffic.
o The client should be able to opt out of TLS decryption, but opting
out may mean that the connection is blocked.
o The server should be able to opt out of TLS decryption, but opting
out may mean that the connection is blocked.
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. [proxy_server_ext] describes an extension to TLS
for improving that mechanism, and also contains a good description in
the introduction.
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.
1.1. Conventions Used in This Document
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 [RFC2119].
Nir Expires February 26, 2012 [Page 3]
Internet-Draft TLS Key Sharing August 2011
2. Protocol Overview
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.
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:
o 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.
o A signature using the private key associated with the certificate
over the concatenation of the ClientHello and ServerHello
messages.
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.
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.
The diagram below outlines the protocol structure.
Nir Expires February 26, 2012 [Page 4]
Internet-Draft TLS Key Sharing August 2011
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
2.1. The tls_keyshare Extension
The tls_keyshare extension is a ClientHello and ServerHello extension
as defined in section 2.3 of [TLS-EXT]. The extension_type field is
TBA by IANA. The format is to be added.
2.2. The KeyShareInfo Record
The format of the KeyShareInfo record is to be added. The content
type is TBA by IANA.
Nir Expires February 26, 2012 [Page 5]
Internet-Draft TLS Key Sharing August 2011
3. Processing
3.1. Client Processing
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.
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.
If a KeyShareInfo record is received with an unknown hash, it MUST be
ignored.
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.
If policy dictates that the particular middlebox referenced in the
KeyShareInfo record is not allowed to decrypt, then such a record is
ignored.
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.
3.2. Server Processing
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.
The server MAY also terminate the connection with a
DECRYPTION_PROHIBITED alert if it is just the particular middlebox
that is not authorized.
3.3. Middlebox Processing
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
Nir Expires February 26, 2012 [Page 6]
Internet-Draft TLS Key Sharing August 2011
certificate format if the hash was not included in the extension, or
the hash format if it was.
Nir Expires February 26, 2012 [Page 7]
Internet-Draft TLS Key Sharing August 2011
4. Security Considerations
To be added
Nir Expires February 26, 2012 [Page 8]
Internet-Draft TLS Key Sharing August 2011
5. IANA Considerations
To be added.
Nir Expires February 26, 2012 [Page 9]
Internet-Draft TLS Key Sharing August 2011
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS-EXT] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
6.2. Informative References
[HTTPS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[proxy_server_ext]
McGrew, D. and P. Gladstone, "TLS Proxy Server Extension",
draft-mcgrew-tls-proxy-server-00 (work in progress),
July 2011.
Nir Expires February 26, 2012 [Page 10]
Internet-Draft TLS Key Sharing August 2011
Author's Address
Yoav Nir
Check Point Software Technologies Ltd.
5 Hasolelim st.
Tel Aviv 67897
Israel
Email: ynir@checkpoint.com
Nir Expires February 26, 2012 [Page 11]