| TLS Working Group | Y. Nir |
| Internet-Draft | Check Point |
| Intended status: Standards Track | September 25, 2011 |
| Expires: March 28, 2012 |
A Method for Sharing Record Protocol Keys with a Middlebox in TLS
draft-nir-tls-keyshare-01
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.
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 March 28, 2012.
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.
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:
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.
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].
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 received that extension in the ClientHello. Note that sending this extension only acknowledges understanding the protocol, not agreement to decryption. The extension contains a sequence of SHA-256 hashes of middlebox certificates. The client sends the hashes of the certificates of middleboxes that it knows are on-path to the server. See Section 4 for a discussion of middlebox discovery. The server sends a subset of the same hashes, only those for which it agrees to decryption.
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 after receiving the ClientHello message, if its hash was not present in the client's tls_keyshare extension. It contains two pieces of information:
The middlebox inserts a KeyShareInfo record with a certificate into the client-to-server stream without an alert, immediately following a ServerHello message that does not contain the middlebox hash. The server will reply with either a fatal UNAUTHORIZED_MIDDLEBOX alert, or a fatal RETRY_MIDDLEBOX alert, depending on policy.
In cases where the client and server negotiate either a ciphersuite that the middlebox does not support, or an extension that it doesn't support, the middlebox inserts a different kind of KeyShareInfo record into the stream, that identifies the unsupported ciphersuite or extension. Both kinds of KeyShareInfo records are followed by a fatal alert. The client is expected to add the hashes and remove the unsupported ciphersuites and extensions, before attempting a new TLS connection.
The client inserts a third type of 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.
Client Middlebox Server
------ --------- ------
ClientHello(tls_keyshare=0)
-------->
KeyShareInfo(cert,sig)
KeyShareInfo(reject cipher:0x0044)
alert(MIDDLEBOX_PRESENT)
<--------
ClientHello(tls_keyshare=cert_hash)
-------->
ServerHello(cert_hash)
(Certificate)
(ServerKeyExchange)
ServerHelloDone
<--------
(Certificate)
ClientKeyExchange
(CertificateVerify)
ChangeCipherSpec
KeyShareInfo(keys)
Finished -------->
ChangeCipherSpec
Finished
<--------
The diagram below outlines discovery.
Client Middlebox Server
------ --------- ------
ClientHello(tls_keyshare=cert_hash)
-------->
ServerHello(keyshare=0)
(Certificate)
(ServerKeyExchange)
ServerHelloDone
<--------
KeyShareInfo(cert,sig)
-------->
alert(UNAUTHORIZED_MIDDLEBOX)
<--------
The diagram below outlines the protocol in a case where the server refuses decryption.
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.
The format of the KeyShareInfo record is to be added. The content type is TBA by IANA.
The KeyShareInfo Discovery record gives client or server information about the middlebox. Format is TBA.
The KeyShareInfo Rejection record gives client a list of unsupported ciphersuites and extensions. Format is TBA.
The KeyShareInfo Keys record is send by the client to the middlebox and includes the session keys. Format is TBA.
If the client policy prohibits decryption, the client SHOULD send the tls_keyshare extension without hashes. Note that the middlebox might still try to proxy the connection, but that is in conflict with this specification, and is outside the scope of this document.
If there are some middleboxes that are by policy acceptable to the client, their certificates are known in advance, and the client believes that they are on-path to the server, then the client MUST send the SHA-256 hashes of their certificates in the tls_keyshare extension.
If a KeyShareInfo Discovery 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. There will certainly be controversy about this, but the configuration must happen an some point.
If policy dictates that the particular middlebox referenced in the KeyShareInfo record is not allowed to decrypt, then such a record MUST be ignored. In that case the connection fails. If the middlebox is acceptable, then the client retries the connection, this time adding the SHA-256 hash of the certificate to the tls_keyshare extension. This is the discovery mechanism.
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.
If a KeyShareInfo Rejection record is received, the client SHOULD retry the handshake, this time without the flagged ciphersuites and extensions. If it is not acceptable to run the connection without these ciphersuites or extensions, the client should log the event or inform the user.
If the server sends a RETRY_MIDDLEBOX alert, the client should retry the handshake. If it sends an UNAUTHORIZED_MIDDLEBOX alert, then the client should log the event or alert the user.
The server SHOULD send the tls_keyshare extension even if policy dictates that the decryption is prohibited. If policy allows all middleboxex to decrypt, it makes sense to simply copy the client's tls_keyshare extension.
If some of the middlebox hashes included in the client's tls_keyshare extension are recognized as those of acceptable middleboxes, then only those are copied to the server's tls_keyshare extension. When the middlebox sends a KeyShareInfo Discovery record, the server may decide whether that is acceptable or not, and accordingly send the RETRY_MIDDLEBOX or UNAUTHORIZED_MIDDLEBOX alerts. In any case, every time the server does not copy all hashes from the client's tls_keyshare, the connection is probably going to end in an alert.
The middlebox MUST send a KeyShareInfo Discovery record to the client if the client has indicated support for this extension, and has not included the middlebox hash in the extension. The discovery record is followed by a MIDDLEBOX_PRESENT alert, breaking the connection. Similarly, if the hash is missing from the server's tls_keyshare extension, then the middlebox injects a KeyShareInfo Discovery record into the client-to-server stream. The server will usually then send an Alert record.
If the ServerHello specifies a ciphersuite that the middlebox does not support, or if it includes a TLS extension that might prevent the middlebox from processing, then the middlebox MAY send a KeyShareInfo Reject record with all unacceptable ciphersuites and extension numbers, followed by a MIDDLEBOX_PRESENT alert.
Discovering that the middlebox is present has already been described in Section 3.1. The client that is not aware of the presence of the middlebox receives a KeyShareInfo Discovery record followed by a MIDDLEBOX_PRESENT alert message.
Discovering that a middlebox in no longer on the path is trickier, because the superfluous KeyShareInfo Keys records do not lead to any observable effects for the client. We suggest that the client keep a list of discovered middleboxes, and periodically clear entries from the list, requiring a repeated discovery. System events such as a change to host IP address, a reboot or the computer entering sleep mode MAY be used as triggers for clearing the list.
To be added
To be added.
| [1] | Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. |
| [2] | Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. |
| [3] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [1] | Rescorla, E, "HTTP Over TLS", RFC 2818, May 2000. |
| [2] | McGrew, D and P Gladstone, "TLS Proxy Server Extension", Internet-Draft draft-mcgrew-tls-proxy-server-00, July 2011. |