Transglobal Secure Collaboration Program Secure E-mail v.1 Gateway Design Principles Prepared by: CP Secure E-mail v.1 Project Team Version: 2.0.2 Date: 16 July 2012
Page i
Copyright 2012 Transglobal Secure Collaboration Participation, Inc. All rights reserved. Terms and Conditions Transglobal Secure Collaboration Participation, Inc. (CP) is a consortium comprising a number of commercial and government members (as further specified at http://www.tscp.org) (each a CP Member ). This specification was developed and is being released under this open source license by CP. Use of this specification is subject to the disclaimers and limitations described below. By using this specification you (the user) agree to and accept the following terms and conditions: 1. This specification may not be modified in any way. In particular, no rights are granted to alter, transform, create derivative works from, or otherwise modify this specification. Redistribution and use of this specification, without modification, is permitted provided that the following conditions are met: Redistributions of this specification must retain the above copyright notice, this list of conditions, and all terms and conditions contained herein. Redistributions in conjunction with any product or service must reproduce the above copyright notice, this list of conditions, and all terms and conditions contained herein in the documentation and/or other materials provided with the distribution of the product or service. CP s name may not be used to endorse or promote products or services derived from this specification without specific prior written permission. 2. The use of technology described in or implemented in accordance with this specification may be subject to regulatory controls under the laws and regulations of various jurisdictions. The user bears sole responsibility for the compliance of its products and/or services with any such laws and regulations and for obtaining any and all required authorizations, permits, or licenses for its products and/or services as a result of such laws or regulations. 3. THIS SPECIFICATION IS PROVIDED AS IS AND WITHOUT WARRANTY OF ANY KIND. CP AND EACH CP MEMBER DISCLAIMS ALL EXPRESS, IMPLIED AND STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF TITLE, NONINFRINGEMENT, MERCHANTABILITY, QUIET ENJOYMENT, ACCURACY, AND FITNESS FOR A PARTICULAR PURPOSE. NEITHER CP NOR ANY CP MEMBER WARRAN (A) THAT THIS SPECIFICATION IS COMPLETE OR WITHOUT ERRORS, (B) THE SUITABILITY FOR USE IN ANY JURISDICTION OF ANY PRODUCT OR SERVICE WHOSE DESIGN IS BASED IN WHOLE OR IN PART ON THIS SPECIFICATION, OR (C) THE SUITABILITY OF ANY PRODUCT OR A SERVICE FOR CERTIFICATION UNDER ANY CERTIFICATION PROGRAM OF CP OR ANY THIRD PARTY. 4. IN NO EVENT SHALL CP OR ANY CP MEMBER BE LIABLE TO YOU OR ANY THIRD PARTY FOR ANY CLAIM ARISING FROM OR RELATING TO THE USE OF THIS SPECIFICATION, INCLUDING, WITHOUT LIMITATION, A CLAIM THAT SUCH USE INFRINGES A THIRD PARTY S INTELLECTUAL PROPERTY RIGH OR THAT IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS SPECIFICATION, THE USER WAIVES ANY SUCH CLAIM AGAINST CP OR ANY CP MEMBER RELATING TO THE USE OF THIS SPECIFICATION. IN NO EVENT SHALL CP OR ANY CP MEMBER BE LIABLE FOR ANY DIRECT OR INDIRECT DAMAGES OF ANY KIND, INCLUDING CONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, OR OTHER DAMAGES WHAOEVER ARISING OUT OF OR RELATED TO ANY USER OF THIS SPECIFICATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. 5. CP reserves the right to modify or amend this specification at any time, with or without notice to the user, and in its sole discretion. The user is solely responsible for determining whether this specification has been superseded by a later version or a different specification. 6. These terms and conditions will be interpreted and governed by the laws of the State of Delaware without regard to its conflict of laws and rules. Any party asserting any claims related to this specification irrevocably consents to the personal jurisdiction of the U.S. District Court for the District of Delaware and to any state court located in such district of the State of Delaware and waives any objections to the venue of such court. Page ii
Table of Contents 1 I n t r o d u c t i o n a n d P u r p o s e... 1 1.1 Supporting Documents... 1 2 S e c u r e E - m a i l G a t e w a y s... 3 2.1 Inbound E-mail Gateways... 4 2.1.1 E-mail Flow Implementation Constraints... 5 2.1.2 Enterprise Notification Requirements... 6 2.1.3 Inbound E-mail Gateway Implementation Constraints... 7 2.2 Outbound E-mail Gateways... 8 2.2.1 Impact on E-mail Flow... 8 2.2.2 Enterprise Notification Requirements... 9 2.2.3 E-mail Gateway Implementation Constraints... 10 3 R e f e r e n c e s...1 1 Table of Figures Figure 1. High-Level Workflow of a Typical Inspecting Inbound E-mail Gateway... 4 Page iii
NOT FOR DISTRIBUTION 1 Introduction and Purpose This document, the, is one of a set of documents prepared by the Transglobal Secure Collaboration Program (CP) that introduces the CP Secure E-mail v.1 solution. This document is normative for e-mail gateways that will inspect encrypted e-mail but optional for pass-through e-mail gateways. Enterprises may have business requirements to scan incoming or outgoing e-mail messages for sensitive, dangerous, suspicious or objectionable content. Since Secure E-mail involves user-to-user encryption of e-mail messages, the task of inspecting e- mail messages at the enterprise boundary becomes more complex. This document defines design principles for E-mail Gateways inspecting encrypted e-mail. 1 For an implementing enterprise, this document is a supplement to the CP Secure E- mail v.1 Technical Specification, the main document in the set, and the CP Secure E- mail v.1 Technical Profile which together describe the actors, solution elements, and characteristics of insource and outsource enterprises and the requirements imposed on them. Supporting documents are available for reference and are listed below. 1. 1 S u p p o r t i n g D o c u m e n t s Each CP Secure E-mail v.1 supporting document is listed below along with a brief description and its associated hyperlink. All CP Secure E-mail v.1 documents are available for download on www.tscp.org. External references are listed in the CP Secure E-mail Technical Specification v.1, Section 4.3 External Specifications. CP Secure E-mail v.1 Technical Specification This normative document provides technical specifications, best practices and recommendations for a secure e-mail capability; it is mandatory for implementing enterprises. CP Secure E-mail v.1 Technical Profile This normative document provides configuration requirements for solution elements and is mandatory for implementing enterprises. It addresses the business requirement to protect information in transit by applying technical constraints and controls to the selected solution elements. 1 This document considers only the user-to-user Secure E-mail use case. The organization-to-organization use case is outside the scope of version 1 of CP Secure E-mail v.1. Page 1
CP Secure E-mail v.1 High Level Design This non-normative document describes the overall design of CP Secure E-mail v.1. It enumerates and recommends technical options for enterprise implementation of CP Secure E-mail v.1 to achieve interoperability with other enterprises. CP Secure E-mail v.1 Requirements to Services Providers This document defines requirements for Service Providers who may provide diverse services to Outsource Enterprises using Secure E-mail. CP Secure E-mail v.1 Requirements to Community Service Providers This document outlines the functional and operational requirements of the Community Service Provider (CSP) for Secure E-mail. CP Secure E-mail v.1 Requirements to Vendors This document articulates requirements to software vendors to support the CP Secure E-mail capability. In order to implement Secure E-mail v.1, vendors must comply with the specifications set forth in other CP documents which provide technical specifications. CP Secure E-mail v.1 PKI Trust Framework This normative document sets forth configuration requirements for PKI solution elements. This document takes the secure e-mail business objectives and requirements related to trust fabric, and identifies the building blocks that form the foundation for secure collaboration using Secure E-mail. CP Secure E-mail v.1 Glossary A comprehensive listing of CP Secure E-mail v.1 terms, acronyms and their definitions. Page 2
2 Secure E-mail Gateways Secure E-mail Gateways are implemented as: Inspecting gateways, which receive the original message, create a copy to decrypt and inspect, and take appropriate action on the original message, or Pass-through gateways, which forward on encrypted e-mail content without inspection. The following information explains inspecting e-mail gateways only, which are in-scope for this document. Pass-through e-mail gateways are out-of-scope for this document. Principles articulated in this section apply equally to inspecting e-mail gateways that are operated by the enterprises themselves or by contractors acting on their behalf. Inspecting e-mail gateways may be inbound or outbound. Requirements for Inbound and Outbound E-mail Gateways are similar but not identical; each is covered in its own sub-section. S/MIME encryption and decryption principles within the context of Inbound and Outbound E-mail Gateways respectively are described below. Within the context of an Inbound E-mail Gateway, S/MIME encryption of an e-mail message includes three steps: 1. Generation of a symmetric content encryption key (also called a session key). 2. Encryption of the message content with the session key. 3. Encryption of the session key with the recipient s public key. Similarly, in the context of an Inbound E-mail Gateway, decryption of an S/MIMEencrypted message includes three steps: 1. Recovery of the recipient s private key. 2. Decryption (recovery) of the session key using the recovered private key. 3. Decryption (recovery) of the message content with the recovered session key. Within the context of an Outbound E-mail Gateway, S/MIME encryption of an e-mail message includes four steps: 1. Generation of a symmetric content encryption key (also called a session key). 2. Encryption of the message content with the session key. 3. Encryption of the session key with the recipient s public key. 4. Encryption of the session key with the gateway s public key for the message copy. Similarly, in the context of an Outbound E-mail Gateway, decryption of an S/MIMEencrypted message includes three steps: 1. Access to the gateway s private key. 2. Decryption of the session key using the gateway s private key. 3. Decryption of the message content with the gateway s session key. Page 3
2. 1 I n b o u n d E - m a i l G a t e w a y s The basic model of an inspecting Inbound E-mail Gateway is described below: The gateway is inserted into the flow of e-mail messages at the recipient s enterprise. Messages received by the gateway are always encrypted. The gateway decrypts and inspects the message, and either forwards it to the recipient or drops it (Figure 1). Start Receive Message Session Key Content Decrypt Session Key Clear Session Key Content Decrypt Message Content Clear Content Inspect Session Key Content Recipient Private Key Key Escrow Database Yes Policy- Compliant? Forward Message Finish No Block Message Figure 1. High-Level Workflow of a Typical Inspecting Inbound E-mail Gateway Some or all shaded steps may be implemented as services external to the E-mail Gateway solution element. Depending on what portion of this functionality is implemented by the gateway itself, an Inbound E-mail Gateway may need to communicate with: 1. A Key Escrow Database (KED) or, more broadly, a Key Recovery Service (KRS), to recover recipients private keys. 2. A Session Key Recovery Service (SKRS) to recover session keys. 3. A Data Recovery Service to recover message content. Security requirements for the last two cases are equivalent since a recovered session key gives the gateway an opportunity to decrypt only one message. Thus, in the rest of this section, only two cases are distinguished: the KED case and the SKRS case. Page 4
2.1.1 E-mail Flow Implementation Constraints Document of Origin: E-mail Flow Implementation Constraints 2.1.1.1 2.1.1.2 5.6.7 5.6.8 Receiving enterprises may inspect incoming encrypted e-mail using key recovery mechanisms in accordance with CertiPath Key Recovery Policy. 2 An Inbound E-mail Gateway shall forward the original e-mail message to the intended recipient if it complies with the receiving enterprise s policies. 2.1.1.3 5.6.9 An Inbound E-mail Gateway shall take action if content does not comply with the receiving enterprise s policies. 2.1.1.4 5.6.10 Operation of an Inbound E-mail Gateway shall have no impact on the senders of encrypted e-mail messages. 3 2.1.1.5 5.6.11 The presence of a gateway shall not impose any additional requirements on the sender, the sender s E-mail Client or the e-mail infrastructure of the sender s enterprise with the exception of those necessary for inspection. 2.1.1.6 5.6.12 An Inbound E-mail Gateway should not add any significant delays to the delivery time of encrypted e-mail messages. 2.1.1.7 5.6.13 An Inbound E-mail Gateway should not serve as a source of decrypted e-mail messages to any other system, including archiving systems. 2.1.1.8 2.1.1.9 5.6.15 5.6.16 If an Enterprise has a policy of archiving all e-mail messages received by its users, it shall notify all enterprises from which it receives or plans to receive encrypted e- mail if an Inbound E-mail Gateway feeds decrypted messages from the gateway to its e-mail archiving system. Based on its enterprise s policies, if an Inbound E-mail Gateway forwards an e-mail message to the intended recipient, it should forward the original encrypted (andpossibly, signed) e-mail message. 2 CertiPath KRP version 1.4 states in section 1.1: Some Organizations require that the contents of incoming and/or outgoing e-mail be examined for compliance with the Organization Policy. This Key Recovery Policy (KRP) provides guidance to ensure that encrypted data is recovered expeditiously when appropriate. The purpose of this document is to describe the security and authentication requirements to implement key recovery operations. 3 Sending an encrypted S/MIME 3.x message involves obtaining a suitable X.509 End-User Encryption Certificate for the recipient and encrypting the e-mail message with the public key it contains. Page 5
2.1.1.10 2.1.1.11 Document of Origin: 5.6.17 5.6.18 E-mail Flow Implementation Constraints The Inbound E-mail Gateway should decrypt the inbound message, verify its content, and forward it in its original encrypted form to the recipient. If an Enterprise does not forward an encrypted e-mail message in its original encrypted form to the recipient, e.g., if it is necessary to reencrypt a message or to transmit it within the enterprise in the clear, it shall notify the sending enterprise. 2.1.2 Enterprise Notification Requirements The CP Secure E-mail v.1 specification ensures the confidentiality of messages by enabling encryption from the sender s e-mail client to the recipient s e-mail client. It is important for enterprises to communicate with partners so that they may determine what impact gateway inspection has upon the assurance of message confidentiality. Document of Origin: 2.1.2.1 5.6.19 2.1.2.2 5.6.20 Enterprise Notification Requirements Enterprises that operate an Inbound E-mail Gateway shall notify all potential sending enterprises about the use of the gateway, provide the necessary (mutually agreed-to) information to them and possibly sign an authorization agreement to that effect. An Enterprise on whose behalf an Inbound E-mail Gateway is operated may notify the sending enterprise when an encrypted e-mail message from one of its users has been blocked. Page 6
2.1.3 Inbound E-mail Gateway Implementation Constraints Document of Origin: Inbound E-mail Gateway Implementation Constraints 2.1.3.1 5.6.21 2.1.3.2 5.6.22 An Inbound E-mail Gateway may be operated by an Enterprise or a contractor on behalf of an Enterprise. A gateway may use additional services (such as a Key Escrow Database or Session Key Recovery Service) operated by the Enterprise or by contractors in support of the Enterprise. 2.1.3.3 5.6.23 2.1.3.4 5.6.24 2.1.3.5 5.6.25 2.1.3.6 5.6.26 2.1.3.7 5.6.27 2.1.3.8 5.6.28 2.1.3.9 5.6.29 2.1.3.10 5.6.30 The Enterprise shall be responsible for compliance of its Inbound E- mail Gateway. An Inbound E-mail Gateway shall be used only for inspection of incoming e-mail messages. An Inbound E-mail Gateway may be responsible for inspecting both encrypted and unencrypted e-mail messages. An Inbound E-mail Gateway shall have appropriate technical, physical, procedural, personnel and other controls in place that will prevent private keys, session keys and decrypted e-mail messages from exposure to personnel. E-mail messages shall exist in their decrypted state for the least possible time. e-mail shall be deleted immediately after inspection if it is not archived. Private keys and session keys shall be safely deleted immediately after use in accordance with stipulations of the CertiPath Key Recovery Policy. The Inbound E-mail Gateway should log the following types of events: Receipt of an e-mail message. Decryption of an e-mail message. Outcome of the inspection of an e-mail message. Forwarding of an approved e-mail message to the recipient. Deletion or forwarding of a blocked e-mail message to the exception/quarantine facility. Page 7
2. 2 O u t b o u n d E - m a i l G a t e w a y s The basic model of an E-mail Gateway adopted in this document was introduced in the CP Secure E-mail v.1 Technical Specifications. An Outbound E-mail Gateway operates as follows: The E-mail Client sends the encrypted message to the external recipients with a copy to the gateway based on enterprise policy. If the message arrives at the gateway encrypted, the gateway decrypts the copy of the message with its key. The gateway inspects the copy of the message, and if the message content does not violate the sending enterprise s policies, the gateway forwards the original encrypted message to the recipient. 2.2.1 Impact on E-mail Flow Document of Origin: Impact on E-mail Flow 2.2.1.1 5.6.7 2.2.1.2 5.6.8 2.2.1.3 5.6.9 2.2.1.4 5.6.10 2.2.1.5 5.6.11 Sending enterprises may inspect outgoing encrypted e-mail using mechanisms that maintain the confidentiality of the message in transit. Outbound E-mail Gateway shall forward the original e-mail message to the intended recipient if it complies with the sending enterprise s policies. An Outbound E-mail Gateway shall take action if content does not comply with the sending enterprise s policies. Operation of an Outbound E-mail Gateway shall have no impact on the recipients of encrypted e-mail messages from the hosting enterprise. The presence of a gateway shall not impose any additional requirements on the recipient, the recipient s E-mail Client or the e- mail infrastructure of the recipient s enterprise with the exception of those necessary for inspection. 2.2.1.6 5.6.31 Messages shall be signed by the senders only. 2.2.1.7 5.6.32 2.2.1.8 5.6.12 The Outbound E-mail Gateway should preserve the sender s signature. An Outbound E-mail Gateway should not add any significant delays to the delivery time of encrypted e-mail messages. Page 8
Document of Origin: 2.2.1.9 5.6.13 2.2.1.10 5.6.14 2.2.1.11 5.6.15 2.2.1.12 5.6.33 Impact on E-mail Flow An Outbound E-mail Gateway should not serve as a source of decrypted e-mail messages to any other system in the enterprise. An Enterprise should not feed decrypted messages from the Outbound E-mail Gateway to the e-mail archiving system. An Enterprise shall notify all enterprises to which it sends or plans to send encrypted e-mail if it feeds decrypted messages from the Outbound E-mail Gateway to the e-mail archiving system. If an Outbound E-mail Gateway blocks a message, it should notify the sender of the message. 2.2.2 Enterprise Notification Requirements The Secure E-mail specification ensures the confidentiality of messages by enabling encryption from the sender s e-mail client to the recipient s e-mail client. It is important for enterprises to communicate with partners so that they may determine what impact gateway inspection has upon the assurance of message confidentiality. 2.2.2.1 2.2.2.2 Document of Origin: 5.6.19 5.6.20 Enterprise Notification Requirements An Enterprise operating an Outbound E-mail Gateway may notify potential receiving enterprises about the use of the gateway subject to its own and the other enterprises policies. An Enterprise operating an encrypting Outbound E-mail Gateway should notify potential receiving enterprises about the use of the gateway and its functionality, subject to policy. Page 9
2.2.3 E-mail Gateway Implementation Constraints Document of Origin: E-mail Gateway Implementation Constraints 2.2.3.1 5.6.21 2.2.3.2 5.6.23 2.2.3.3 5.6.24 2.2.3.4 5.6.25 2.2.3.5 5.6.26 2.2.3.6 5.6.30 An Outbound E-mail Gateway may be operated by an Enterprise or a contractor on behalf of an Enterprise. The Enterprise shall be responsible for compliance of its Outbound E- mail Gateway. An Outbound E-mail Gateway shall be used only for inspection of outgoing e-mail messages. An Outbound E-mail Gateway may be responsible for inspecting both encrypted and unencrypted e-mail messages. An Outbound E-mail Gateway shall have appropriate technical, physical, procedural, personnel and other controls in place that will prevent clear-text e-mail messages from exposure to personnel. The gateway should log the following types of events: Receipt of an e-mail message. Decryption of an e-mail message. Outcome of the inspection of an e-mail message. Forwarding of an approved e-mail message to the recipient. Deletion or forwarding of a blocked e-mail message to the exception/quarantine facility. Page 10
3 References CertiPath X.509 Certificate Policy, CertiPath LLC, November 2006. CertiPath Key Recovery Policy, CertiPath LLC, May 2007. [RFC2246] Dierks T. and C. Allen, The TLS Protocol, Version 1.0. RFC 2246, IETF, January 1999. [RFC2401] Kent S. and R. Atkinson, Security Architecture for the Internet Protocol. RFC 2401, IETF, November 1998. [RFC2409] Harkins D. and D. Carrel, The Internet Key Exchange (IKE). RFC 2409, IETF, November 1998. [RFC3207] Hoffman P., SMTP Service Extension for Secure SMTP over Transport Layer Security. RFC 3207, IETF, February 2002. [RFC 4301] Security Architecture for the Internet Protocol. RFC 4301, IETF, December 2005. [RFC 4306] Internet Key Exchange (IKEv2) Protocol. RFC 4306, IETF, December 2005. [RFC 4346] The Transport Layer Security (TLS) Protocol Version 1.1. RFC 4346, IETF, April 2006. [RFC 5246] The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246, IETF, August 2008. CP Secure E-mail v.1 Technical Profile, Version 2.0.1, Published Sept. 30, 2011. Available at http://www.tscp.org/library/documents. CP Secure E-mail v.1 Technical Specification, Version 3.0.1, CP, Published Sept. 30, 2011. Available at http://www.tscp.org/library/documents. Page 11