Transglobal Secure Collaboration Program Secure v.1 Gateway Design Principles

Transcription

1 Transglobal Secure Collaboration Program Secure v.1 Gateway Design Principles Prepared by: CP Secure v.1 Project Team Version: Date: 16 July 2012

2 Page i

3 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 (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

4 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 Supporting Documents S e c u r e E - m a i l G a t e w a y s Inbound Gateways Flow Implementation Constraints Enterprise Notification Requirements Inbound Gateway Implementation Constraints Outbound Gateways Impact on Flow Enterprise Notification Requirements Gateway Implementation Constraints R e f e r e n c e s Table of Figures Figure 1. High-Level Workflow of a Typical Inspecting Inbound Gateway... 4 Page iii

5 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 v.1 solution. This document is normative for gateways that will inspect encrypted but optional for pass-through gateways. Enterprises may have business requirements to scan incoming or outgoing messages for sensitive, dangerous, suspicious or objectionable content. Since Secure involves user-to-user encryption of messages, the task of inspecting e- mail messages at the enterprise boundary becomes more complex. This document defines design principles for Gateways inspecting encrypted . 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 S u p p o r t i n g D o c u m e n t s Each CP Secure v.1 supporting document is listed below along with a brief description and its associated hyperlink. All CP Secure v.1 documents are available for download on External references are listed in the CP Secure Technical Specification v.1, Section 4.3 External Specifications. CP Secure v.1 Technical Specification This normative document provides technical specifications, best practices and recommendations for a secure capability; it is mandatory for implementing enterprises. CP Secure 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 use case. The organization-to-organization use case is outside the scope of version 1 of CP Secure v.1. Page 1

6 CP Secure v.1 High Level Design This non-normative document describes the overall design of CP Secure v.1. It enumerates and recommends technical options for enterprise implementation of CP Secure v.1 to achieve interoperability with other enterprises. CP Secure v.1 Requirements to Services Providers This document defines requirements for Service Providers who may provide diverse services to Outsource Enterprises using Secure . CP Secure v.1 Requirements to Community Service Providers This document outlines the functional and operational requirements of the Community Service Provider (CSP) for Secure . CP Secure v.1 Requirements to Vendors This document articulates requirements to software vendors to support the CP Secure capability. In order to implement Secure v.1, vendors must comply with the specifications set forth in other CP documents which provide technical specifications. CP Secure v.1 PKI Trust Framework This normative document sets forth configuration requirements for PKI solution elements. This document takes the secure business objectives and requirements related to trust fabric, and identifies the building blocks that form the foundation for secure collaboration using Secure . CP Secure v.1 Glossary A comprehensive listing of CP Secure v.1 terms, acronyms and their definitions. Page 2

7 2 Secure Gateways Secure 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 content without inspection. The following information explains inspecting gateways only, which are in-scope for this document. Pass-through gateways are out-of-scope for this document. Principles articulated in this section apply equally to inspecting gateways that are operated by the enterprises themselves or by contractors acting on their behalf. Inspecting gateways may be inbound or outbound. Requirements for Inbound and Outbound 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 Gateways respectively are described below. Within the context of an Inbound Gateway, S/MIME encryption of an 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 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 Gateway, S/MIME encryption of an 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 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

8 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 Gateway is described below: The gateway is inserted into the flow of 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 Gateway Some or all shaded steps may be implemented as services external to the Gateway solution element. Depending on what portion of this functionality is implemented by the gateway itself, an Inbound 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

9 Flow Implementation Constraints Document of Origin: Flow Implementation Constraints Receiving enterprises may inspect incoming encrypted using key recovery mechanisms in accordance with CertiPath Key Recovery Policy. 2 An Inbound Gateway shall forward the original message to the intended recipient if it complies with the receiving enterprise s policies An Inbound Gateway shall take action if content does not comply with the receiving enterprise s policies Operation of an Inbound Gateway shall have no impact on the senders of encrypted messages The presence of a gateway shall not impose any additional requirements on the sender, the sender s Client or the infrastructure of the sender s enterprise with the exception of those necessary for inspection An Inbound Gateway should not add any significant delays to the delivery time of encrypted messages An Inbound Gateway should not serve as a source of decrypted messages to any other system, including archiving systems If an Enterprise has a policy of archiving all messages received by its users, it shall notify all enterprises from which it receives or plans to receive encrypted e- mail if an Inbound Gateway feeds decrypted messages from the gateway to its archiving system. Based on its enterprise s policies, if an Inbound Gateway forwards an message to the intended recipient, it should forward the original encrypted (andpossibly, signed) message. 2 CertiPath KRP version 1.4 states in section 1.1: Some Organizations require that the contents of incoming and/or outgoing 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 message with the public key it contains. Page 5

10 Document of Origin: Flow Implementation Constraints The Inbound 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 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 Enterprise Notification Requirements The CP Secure v.1 specification ensures the confidentiality of messages by enabling encryption from the sender s client to the recipient s 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: Enterprise Notification Requirements Enterprises that operate an Inbound 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 Gateway is operated may notify the sending enterprise when an encrypted message from one of its users has been blocked. Page 6

11 2.1.3 Inbound Gateway Implementation Constraints Document of Origin: Inbound Gateway Implementation Constraints An Inbound 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 The Enterprise shall be responsible for compliance of its Inbound E- mail Gateway. An Inbound Gateway shall be used only for inspection of incoming messages. An Inbound Gateway may be responsible for inspecting both encrypted and unencrypted messages. An Inbound Gateway shall have appropriate technical, physical, procedural, personnel and other controls in place that will prevent private keys, session keys and decrypted messages from exposure to personnel. messages shall exist in their decrypted state for the least possible time. 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 Gateway should log the following types of events: Receipt of an message. Decryption of an message. Outcome of the inspection of an message. Forwarding of an approved message to the recipient. Deletion or forwarding of a blocked message to the exception/quarantine facility. Page 7

12 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 Gateway adopted in this document was introduced in the CP Secure v.1 Technical Specifications. An Outbound Gateway operates as follows: The 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 Impact on Flow Document of Origin: Impact on Flow Sending enterprises may inspect outgoing encrypted using mechanisms that maintain the confidentiality of the message in transit. Outbound Gateway shall forward the original message to the intended recipient if it complies with the sending enterprise s policies. An Outbound Gateway shall take action if content does not comply with the sending enterprise s policies. Operation of an Outbound Gateway shall have no impact on the recipients of encrypted messages from the hosting enterprise. The presence of a gateway shall not impose any additional requirements on the recipient, the recipient s Client or the e- mail infrastructure of the recipient s enterprise with the exception of those necessary for inspection Messages shall be signed by the senders only The Outbound Gateway should preserve the sender s signature. An Outbound Gateway should not add any significant delays to the delivery time of encrypted messages. Page 8

13 Document of Origin: Impact on Flow An Outbound Gateway should not serve as a source of decrypted messages to any other system in the enterprise. An Enterprise should not feed decrypted messages from the Outbound Gateway to the archiving system. An Enterprise shall notify all enterprises to which it sends or plans to send encrypted if it feeds decrypted messages from the Outbound Gateway to the archiving system. If an Outbound Gateway blocks a message, it should notify the sender of the message Enterprise Notification Requirements The Secure specification ensures the confidentiality of messages by enabling encryption from the sender s client to the recipient s 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: Enterprise Notification Requirements An Enterprise operating an Outbound 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 Gateway should notify potential receiving enterprises about the use of the gateway and its functionality, subject to policy. Page 9

14 Gateway Implementation Constraints Document of Origin: Gateway Implementation Constraints An Outbound 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 Gateway shall be used only for inspection of outgoing messages. An Outbound Gateway may be responsible for inspecting both encrypted and unencrypted messages. An Outbound Gateway shall have appropriate technical, physical, procedural, personnel and other controls in place that will prevent clear-text messages from exposure to personnel. The gateway should log the following types of events: Receipt of an message. Decryption of an message. Outcome of the inspection of an message. Forwarding of an approved message to the recipient. Deletion or forwarding of a blocked message to the exception/quarantine facility. Page 10

15 3 References CertiPath X.509 Certificate Policy, CertiPath LLC, November CertiPath Key Recovery Policy, CertiPath LLC, May [RFC2246] Dierks T. and C. Allen, The TLS Protocol, Version 1.0. RFC 2246, IETF, January [RFC2401] Kent S. and R. Atkinson, Security Architecture for the Internet Protocol. RFC 2401, IETF, November [RFC2409] Harkins D. and D. Carrel, The Internet Key Exchange (IKE). RFC 2409, IETF, November [RFC3207] Hoffman P., SMTP Service Extension for Secure SMTP over Transport Layer Security. RFC 3207, IETF, February [RFC 4301] Security Architecture for the Internet Protocol. RFC 4301, IETF, December [RFC 4306] Internet Key Exchange (IKEv2) Protocol. RFC 4306, IETF, December [RFC 4346] The Transport Layer Security (TLS) Protocol Version 1.1. RFC 4346, IETF, April [RFC 5246] The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246, IETF, August CP Secure v.1 Technical Profile, Version 2.0.1, Published Sept. 30, Available at CP Secure v.1 Technical Specification, Version 3.0.1, CP, Published Sept. 30, Available at Page 11