Transglobal Secure Collaboration Program Secure v.1 Gateway Design Principles

(1)

Transglobal Secure Collaboration Program

Secure E-mail v.1

Gateway Design Principles

Prepared by:

TSCP Secure E-mail v.1 Project Team

Version:

2.0.2

(2)

(3)

Terms and Conditions

Transglobal Secure Collaboration Participation, Inc. (TSCP) is a consortium comprising a number of commercial and government members (as further specified at http://www.tscp.org) (each a “TSCP

Member”). This specification was developed and is being released under this open source license by TSCP. 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.

 TSCP’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. TSCP AND EACH TSCP 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 TSCP NOR ANY TSCP MEMBER WARRANTS (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 TSCP OR ANY THIRD PARTY.

4. IN NO EVENT SHALL TSCP OR ANY TSCP 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 RIGHTS OR THAT IT FAILS TO COMPLY WITH APPLICABLE LAWS OR REGULATIONS. BY USE OF THIS SPECIFICATION, THE USER WAIVES ANY SUCH CLAIM AGAINST TSCP OR ANY TSCP MEMBER RELATING TO THE USE OF THIS SPECIFICATION. IN NO EVENT SHALL TSCP OR ANY TSCP MEMBER BE LIABLE FOR ANY DIRECT OR INDIRECT DAMAGES OF ANY KIND, INCLUDING CONSEQUENTIAL, INCIDENTAL, SPECIAL, PUNITIVE, OR OTHER DAMAGES

WHATSOEVER ARISING OUT OF OR RELATED TO ANY USER OF THIS SPECIFICATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

5. TSCP 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 TSCP Secure E-mail v.1 Gateway Design Principles

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

(5)

NOT FOR DISTRIBUTION

1 Introduction and Purpose

This document, the TSCP Secure E-mail v.1 Gateway Design Principles, is one of a set of documents prepared by the Transglobal Secure Collaboration Program (TSCP) that introduces the TSCP 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 TSCP Secure E- mail v.1 Technical Specification, the main document in the set, and the TSCP 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 TSCP Secure E-mail v.1 supporting document is listed below along with a brief description and its associated hyperlink. All TSCP Secure E-mail v.1 documents are available for download on www.tscp.org.

External references are listed in the TSCP Secure E-mail Technical Specification v.1, Section 4.3 External Specifications.

• TSCP 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.

• TSCP 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 TSCP Secure E-mail v.1.

(6)

• TSCP Secure E-mail v.1 High Level Design

This non-normative document describes the overall design of TSCP Secure E-mail v.1. It enumerates and recommends technical options for enterprise implementation of TSCP Secure E-mail v.1 to achieve interoperability with other enterprises.

• TSCP 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.

• TSCP 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.

• TSCP Secure E-mail v.1 Requirements to Vendors

This document articulates requirements to software vendors to support the TSCP Secure E-mail capability. In order to implement Secure E-mail v.1, vendors must comply with the specifications set forth in other TSCP documents which provide technical specifications.

• TSCP 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.

• TSCP Secure E-mail v.1 Glossary

A comprehensive listing of TSCP Secure E-mail v.1 terms, acronyms and their definitions.

(7)

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/MIME- encrypted 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/MIME- encrypted 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 TSCP Secure E-mail v.1 Gateway Design Principles

(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 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 Encrypted Message Encrypted Session Key Encrypted Content Decrypt Session Key Clear Session Key Encrypted Content Decrypt Message Content Clear Content Inspect Encrypted Session Key Encrypted Content Recipient Private Key Yes Policy- No Compliant? Key Escrow Database Forward Encrypted Message Finish Block Encrypted 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.

(9)

2.1.1 E-mail Flow Implementation Constraints

Document of Origin:

TS

E-mail Flow Implementation Constraints

2.1.1.1 5.6.7

Receiving enterprises may inspect incoming encrypted e-mail using key recovery mechanisms in accordance with CertiPath Key Recovery Policy.2

2.1.1.2 5.6.8

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 5.6.15

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.

2.1.1.9 5.6.16

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.

(10)

TS

E-mail Flow Implementation Constraints

2.1.1.10 5.6.17

The Inbound E-mail Gateway should decrypt the inbound message, verify its content, and forward it in its original encrypted form to the recipient.

2.1.1.11 5.6.18

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 re- encrypt 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 TSCP 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.

TS

Enterprise Notification Requirements

2.1.2.1 5.6.19

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.

2.1.2.2 5.6.20

An Enterprise on whose behalf an Inbound E-mail Gateway is operated

may notify the sending enterprise when an encrypted e-mail message

(11)

2.1.3 Inbound E-mail Gateway Implementation Constraints

Document of Origin:

TS

Inbound E-mail Gateway Implementation Constraints

2.1.3.1 5.6.21 An Inbound E-mail Gateway may be operated by an Enterprise or a contractor on behalf of an Enterprise.

2.1.3.2 5.6.22

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 The Enterprise shall be responsible for compliance of its Inbound E- mail Gateway.

2.1.3.4 5.6.24 An Inbound E-mail Gateway shall be used only for inspection of incoming e-mail messages.

2.1.3.5 5.6.25 An Inbound E-mail Gateway may be responsible for inspecting both encrypted and unencrypted e-mail messages.

2.1.3.6 5.6.26

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.

2.1.3.7 5.6.27 E-mail messages shall exist in their decrypted state for the least possible time.

2.1.3.8 5.6.28 Encrypted e-mail shall be deleted immediately after inspection if it is not archived.

2.1.3.9 5.6.29

Private keys and session keys shall be safely deleted immediately after use in accordance with stipulations of the CertiPath Key Recovery Policy.

2.1.3.10 5.6.30

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.

(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 E-mail Gateway adopted in this document was introduced in the TSCP 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

TS

Impact on E-mail Flow

2.2.1.1 5.6.7

Sending enterprises may inspect outgoing encrypted e-mail using mechanisms that maintain the confidentiality of the message in transit.

2.2.1.2 5.6.8

Outbound E-mail Gateway shall forward the original e-mail message to the intended recipient if it complies with the sending enterprise’s policies.

2.2.1.3 5.6.9 An Outbound E-mail Gateway shall take action if content does not comply with the sending enterprise’s policies.

2.2.1.4 5.6.10

Operation of an Outbound E-mail Gateway shall have no impact on the recipients of encrypted e-mail messages from the hosting enterprise.

2.2.1.5 5.6.11

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.

(13)

TS

Impact on E-mail Flow

2.2.1.9 5.6.13 An Outbound E-mail Gateway should not serve as a source of decrypted e-mail messages to any other system in the enterprise. 2.2.1.10 5.6.14 An Enterprise should not feed decrypted messages from the

Outbound E-mail Gateway to the e-mail archiving system.

2.2.1.11 5.6.15

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.

2.2.1.12 5.6.33 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.

TS

Enterprise Notification Requirements

2.2.2.1

5.6.19

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.

2.2.2.2

5.6.20

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.

(14)

2.2.3 E-mail Gateway Implementation Constraints

TS

E-mail Gateway Implementation Constraints

2.2.3.1 5.6.21 An Outbound E-mail Gateway may be operated by an Enterprise or a _{contractor on behalf of an Enterprise.}

2.2.3.2 5.6.23 The Enterprise shall be responsible for compliance of its Outbound E- mail Gateway.

2.2.3.3 5.6.24 An Outbound E-mail Gateway shall be used only for inspection of outgoing e-mail messages.

2.2.3.4 5.6.25 An Outbound E-mail Gateway may be responsible for inspecting both encrypted and unencrypted e-mail messages.

2.2.3.5 5.6.26

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.

2.2.3.6 5.6.30

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

(15)

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.

TSCP Secure E-mail v.1 Technical Profile, Version 2.0.1, Published Sept. 30, 2011.

Available at http://www.tscp.org/library/documents.

TSCP Secure E-mail v.1 Technical Specification, Version 3.0.1, TSCP, Published Sept.

30, 2011. Available at http://www.tscp.org/library/documents.