TSCP Secure Technical Specification Version 2.0

Transcription

1 TSCP Secure Technical Specification Version 2.0 Prepared by: SE v.2 Project Team Lead Author: Stephen Skordinski Edition: 0.5 Published: 11/20/2012

2 Copyright 2012 Transglobal Secure Collaboration Participation, Inc. All rights reserved. Terms and Conditions Transglobal Secure Collaboration Participation, Inc. (TSCP) is a consortium comprising a number of commercial and government members (as further specified at (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 deriva tive 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 contr ols 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 license s 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. Secure v.2 Technical Specification Page i

3 Document Change History for: Technical Specification for SE v.2 Version Number Version Date Information Affected Author (s) Authorized by 0.1 First Draft Stephen Skordinski SE v.2 Project Team 0.2 SME s completed first draft of the document, completing their assigned sections Steph Charbonneau Andrew Cowan Trevor Freeman Colin Nash Stephen Skordinski Simon Wiseman SE v.2 Project Team 0.3 Incorporated changes from Chicago Business Week. Stephen Skordinski SE v.2 Project Team 0.4 Project team review changes incorporated 0.5 Final document review for grammar, content updates, and clarification. Piers Chivers Colin Nash Richard Skedd Stephen Skordinski Justin Gercken Colin Nash Richard Skedd Stephen Skordinski SE v.2 Project Team SE v.2 Document Review Team Secure v.2 Technical Specification Page ii

4 Document Contributors in alphabetical order by organization / company: Contributor Name Richard Skedd Andrew Cowan Colin Nash Simon Wiseman Patrick Patterson Trevor Freeman Steph Charbonneau Paul Reid Ed Simon Stephen Skordinski BAE Systems Boldon James Deep-Secure Deep-Secure EADS Microsoft Titus Titus Titus TSCP Contributing Company Secure v.2 Technical Specification Page 3

5 TABLE OF CONTENTS 1. Introduction and Document Purpose Document Notation Secure (SE) v.2 Overview Business Authorization Identification and Labeling Scheme (BAILS) Business Authorization Framework (BAF) Technical Specifications Label Structure Technical Specifications for SE v.2 Clients and SE v.2 Client Administration Visual Markings Applying Policy to Constraining of Policy Labels Availability to Authors Managing Business Authorization Policies Authentication Enforcement Authorization Enforcement Inheritance of Labels from OOXML Documents Client Behavior When Receiving Unrecognized Policy Labels Client Behavior When Receiving Recognized Policy Labels for Which the Recipient Is Not Authorized Enabling Inspection of S/MIME Encrypted Messages by Inspecting Gateways Technical Specifications for SE v.2 Inspecting Gateways Translation of SE v.2 messages to Alternate Format Recipients Translation of Messages to SE v.2 Recipients Inspection of S/MIME Encrypted Messages Inspecting Gateway Key Management Distribution of Configuration Information Recommended Configuration Data Exchange Methodology: TSCP Business Authorization Framework Alternative Configuration Data Exchange Methodology Compatibility with SE v References Secure v.2 Technical Specification Page 4

6 Table of Figures Figure 1. SE v.2 Architecture... 3 Figure 2. SE v.2 Example Message Format... 7 Figure 3. Visual Marking Example... 8 Figure 4. Sending and Receiving Inspecting Gateway Configuration Figure 5. Conversion of SE v.2 Message to Single Policy ESS Message Figure 6. Conversion of SE v.2 Message to SMTP X-Header Message Figure 7. Single Policy ESS Security Label Sender to SE v.2 Equivalent Label Attribute Message Recipient Inspecting Gateway Conversion Figure 8. Message with SMTP X-headers Sender to SE v.2 Equivalent Label Attribute Message Recipient Inspecting Gateway Conversion Table of Tables Table 1. Component Descriptions... 4 Table 2. SE v.2 ESS Label Format Requirements... 5 Table 3. Format of Policy Information for Different File Types Table 4. Inspecting Gateway Use Cases Table 5. PKI Policy OID Levels of Assurance Table Table 6. SE v.2 Policy Table Table 7. Right of Inspection Table Secure v.2 Technical Specification Page 5

7 1. Introduction and Document Purpose Within defense sector companies and government organizations, much of the traffic is commercially sensitive or protected by national security or export controls and must be protected against Internet eavesdropping. However, Simple Mail Transfer Protocol (SMTP), the protocol of the Internet, has inherent security weaknesses that make it easy for attackers to intercept, forge (spoof), and modify messages. In addition, once received, without policy markings on the message, it is up to the discretion of the recipient to determine the sensitivity of the data contained in the . Mitigation of these risks means assurance that sensitive information is getting to the intended person at the other end, without being intercepted, corrupted, or leaked. The purpose of this document is to identify the technical specification of Secure v.2 (SE v.2) which, when implemented at both the sending and receiving organization, allows for the exchange of s that are encrypted, labeled, and digitally signed. This document is intended to build upon the SE v.1 specification; SE v.2 adds to SE v.1 rather than supersedes it. 1.1 Document Notation 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]. Secure v.2 Technical Specification Page 1 of 24

8 2. Secure (SE) v.2 Overview TSCP Secure v.1 (SE v.1) provides the following functions: Sending and receiving encrypted which ensures the confidentiality of content between the sender and the recipient. Sending and receiving signed which validates the identities of both the sender and recipient and ensures that content arrives in the recipient s mailbox without changes being made to either the text, or its attachments while en route. Where TSCP SE v.1 provides an effective means to assure messages reach their intended recipients with both integrity and confidentiality, it does not address the sensitivity of the message contents. TSCP SE v.2 builds on the existing infrastructure and standards in place in SE v.1. In addition to signing and encrypting capabilities, SE v.2 provides support for the following: Policy labeling of which allows users to apply policy labels that visually and systemically mark an with the sensitivity of the data contained in the message. Data leakage can be reduced by identifying the sensitivity of data such that both users and systems can take measures to ensure the data is handled in accordance with the applicable security policies. Gateway inspection of encrypted messages allows organizations to scan encrypted s for malware before they reach the end user s local client. Enforcement of digital signatures and encryption allows organizations to require a message be signed and/or encrypted, based on the policy label assigned to the message. Enforcement of the use of public key infrastructure (PKI) certificates which provide, at least, the minimum level of identity assurance required by policy. Inheritance of labels from attached Office Open Extensible Markup Language (OOXML) documents. Figure 1 below describes the SE v.2 architecture. During a typical SE v.2 message flow, a user from one domain will author an for a user on another domain (there are no restrictions placed on internal domain messages by this specification). The user will open their client and create a new message. The user selects the appropriate policy marking to apply to the message from a list, which has been preconfigured with the labeling tool management service. Upon selecting the appropriate policy label and sending the message, the client will sign, and may encrypt the (in accordance with the TSCP SE v.1 specifications). The message is then routed via the server to the external recipient. Before exiting the organization, the traffic may pass through an inspecting gateway. The inspecting gateway, if configured to do so, can decrypt the message to scan the message for malware, as well as scan for message content not permitted to leave the local domain. Likewise, the receiving inspecting gateway, if configured to do so, can decrypt the message to scan the message for malware before it is permitted into the local domain. The message is then delivered to the recipient s server for distribution to the recipient s client. Upon receiving the message, it is decrypted by the client, and the appropriate policy labels displayed on the message. Secure v.2 Technical Specification Page 2 of 24

9 Community Services Labeling Tool Configuration Management Service Labeling Tool Configuration Management Service Clients w/ Labeling Plug In Certificate Lookup Service Certificate Lookup Service Clients w/ Labeling Plug In Server Inspecting Gateway Inspecting Gateway Server End User Certificate Certificate Authority Repository End User Certificate Repository Certificate Authority Unchanged from SE v.1 Change from SE v.1 CertiPath PKI Bridge New Component for SE v.2 Figure 1. SE v.2 Architecture Secure v.2 Technical Specification Page 3 of 24

10 Table 1. Component Descriptions Component Certificate Authority (CA) Certificate Lookup Service CertiPath PKI Bridge Community Services Client with Plug-in Server End User Certificate Repository Inspecting Gateway Labeling Tool Configuration Management Service Description An entity that issues digital certificates. The CA in SE v.1 must be cross certified with CertiPath, or be part of the extended trust structure via the Federal Bridge Certification Authority (FBCA). A specialized LDAP proxy used to look up X.509 encryption certificates for prospective recipients in secure applications. It can be used to fetch end user certificates, CA certificates, and certificate revocation lists (CRLs). A bridge that enables cross-certified PKIs to recognize and trust digital signatures and certificates sent from, and between, other participating PKIs. CertiPath is specifically targeted for support of the Aerospace and Defense sector. A shared repository for the configuration data is required to configure the certificate lookup service. An S/MIME-enabled client (e.g., Microsoft Outlook, Lotus Notes, and Mozilla Thunderbird). In addition, the client has an installed plug-in which allows the user to send and receive s with policy labels. An application that receives incoming for local users and forwards outgoing for delivery. A directory service used to publish user digital certificates. A service that sits on the perimeter of a network and monitors all incoming and outgoing traffic. A service which is used to centrally manage the configuration of the client plug-ins for labeling. 2.1 Business Authorization Identification and Labeling Scheme (BAILS) SE v.2 utilizes TSCP BAILS as a standard for expression of information sensitivity. BAILS is a metadata specification for information objects. BAILS provides a means for sensitivity information to be expressed, and may be used between parties if interoperable systems are to be implemented. It provides a set of standard fields that can be used to hold sensitivity information. 2.2 Business Authorization Framework (BAF) SE v.2 builds upon the TSCP BAF as a framework for the administration and management of business authorizations that enable a higher level of automated processing of business protection policies. This framework and the associated protection profiles carry the data required for deploying organizations to configure SE v.2 compliant solutions. The labeling tool configuration management service will receive configuration information that has been generated by BAF processes. Secure v.2 Technical Specification Page 4 of 24

11 3. Technical Specifications The following section of the document is intended to provide the specifications to which SE v.2 environments MUST be configured and deployed Label Structure SE v.2 leverages the RFC 2634 Enhanced Security Services for S/MIME as the standard format for carrying message policies in messages. The esssecuritylabel syntax MUST be carried in the equivalentlabel attribute. The SE v.2 sending organization MUST ensure the policy label or labels attached to an message are transmitted to external domains in esssecuritylabel syntax. Organizations MAY convert this label format to other formats for use within internal domains. The esssecuritylabel syntax MUST be formatted as follows: SecurityPolicyIdentifier: The SecurityPolicyIdentifier MUST be included in the ESS label and assigned the following object identifier (OID): This field is used by the receiving system to consistently identify that the incoming ESS label is one created in compliance with this technical specification, thus differentiating it from other ESS labels. SecurityClassification: The SecurityClassification MUST NOT be used. ESSPrivacyMark: The ESSPrivacyMark MUST NOT be used. SecurityCategories: This specification further constrains the SecurityCategories used within the ESS label. The ESS label MUST contain at least one, but no more than three, OIDs, that represent the policy identifiers applicable to the content of the message. Table 2. SE v.2 ESS Label Format Requirements ESS Component Inclusion Value SecurityPolicyIdentifier MUST be included The value of the security policy identifier MUST always be SecurityClassification MUST NOT be included None ESSPrivacyMark MUST NOT be included None SecurityCategories MUST be included MUST contain at least one, but no more than three OIDs. Throughout this document are visual depictions of SE v.2 formatted s, along with the potential message translations that may be carried out by the inspecting gateway. These visuals are intended to assist the reader in understanding the proper formatting of a TSCP SE v.2 message. Figure 2 below is an example of an SE v.2 formatted message. The diagrams do not provide a comprehensive list of all S/MIME message components, but rather highlight those that are most relevant to the TSCP SE v.2 specification. ContentType = Application/pkcs7 The ContentType field is used to specify the nature of the data in the body of a MIME entity, by giving media type and subtype identifiers. In the case of S/MIME messages, the ContentType is indicated as application/pkcs7. The application/pkcs7- mime media type is used to carry Cryptographic Message Syntax (CMS) content types, as defined in RFC 5652, including EnvelopedData, SignedData, and CompressedData. Secure v.2 Technical Specification Page 5 of 24

12 SignedData The message digest algorithms for all the signers and the SignerInfo values for all the signers are collected together with the content into a SignedData value. A security label may be included in the signed attributes of any SignedData object. A security label attribute may be included in either the inner signature, outer signature, or both. DigestAlgorithmID Indicates the message digest algorithm used to produce the hash value. SignedMessageContents The user generated message contents SignerInfo - For each signer, the encrypted message digest and other signer-specific information is collected into a SignerInfo value SignerInfo #1 Client S Indicates the system used to sign the message. Client S is an indication that the signature was created by the Sending Client (See Figure 4). In later examples, signatures are added by the recipient s inspecting gateway. Signer ID the signerid indicates who the signer of the message is. It contains either the issuerandserialnumber or the subjectkeyidentifier Signed Attributes - The SignerInfo type allows the inclusion of signed attributes along with a signature. ESS Labels EquivalentLabels contain a sequence of esssecuritylabels which hold the OIDs for the policy labels. Within TSCP SE v.2 messages, equivlanentlabels are always used to contain the BAILS Policy OIDS of the policy labels. Signature The result of digital signature generation, using the message digest and the signer's private key. The details of the signature depend on the signature algorithm employed. For additional detail on S/MIME message format, see RFC 5751, Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification; RFC 5652, Cryptographic Message Syntax ; and RFC 2634, Enhanced Security Services for S/MIME. Secure v.2 Technical Specification Page 6 of 24

13 Content Type = Application/pkcs7 Signed Data Digest Alg ID Signed Message Contents Signer Infos Signer Info #1 Client S Signer ID Signed Attributes ESS Label BAILS policy OID s Signature Figure 2. SE v.2 Example Message Format 3.2 Technical Specifications for SE v.2 Clients and SE v.2 Client Administration Visual Markings Visual markings are the identifiers that users of the SE v.2 system can see and use to identify the policy or policies that are applicable to the . Secure v.2 Technical Specification Page 7 of 24

14 Client Interface Send Save Address Book Client Interface Label Message To: Subject: Body: Prefix - Message Subject - Suffix First Lines of Text First Lines of Text First Lines of Text Lorem ipsum dolor sit amet, consectetur adipiscing elit. Quisque rhoncus orci sit amet erat pretium eu aliquam nisi congue. Vestibulum neque ipsum, accumsan at tincidunt quis, dignissim et erat. Quisque eros nisl, volutpat dapibus venenatis nec, lobortis porta massa. Fusce Last Lines of Text Last Lines of Text Last Lines of Text Figure 3. Visual Marking Example Client Interface Display of Policy Labels A client interface policy label may be required by every policy associated with the message. If a policy associated with an message by the policy identifier OID states that a client interface policy label is required, then the client MUST retrieve and display the appropriate policy label within the client user interface. All required client interface policy labels MUST be displayed within the client user interface. The client interface MUST display a policy label in the client interface. The marking values for a given policy are documented in the TSCP BAF under Marking Rules. Subject and Body Markings There are four places where the markings can be added to the message content: the subject prefix, subject suffix, first line(s) of text in the message body, and last line(s) of text in the message body. In all four of these cases, the marking values for a given policy are documented in the TSCP BAF Business Authorization Category under Marking Rules. Additionally, these markings will be displayed to all recipients upon receipt of the message, either in the message subject, or the message body. Secure v.2 Technical Specification Page 8 of 24

15 Subject Prefix If one or more policy labels are attached to an message by the author, the client MAY include a prefix to the subject that identifies the policies associated with the message. The subject prefix, if included, MUST be included in the message subject before the message is sent. If multiple policies exist, the policy markings SHOULD be delineated by a space, hyphen, and another space, such that each policy is separated. Example: Policy Label 1 - Policy Label 2 - Message Subject. Subject Suffix If one or more policy labels are attached to an message by the author, the client MAY include a suffix to the subject that identifies the policies associated with the message. The subject suffix, if included, MUST be included in the message subject before the message is sent. If multiple policies exist, the policy markings SHOULD be delineated by a space, hyphen, and another space, such that each policy is separated. Example: Message Subject - Policy Label 1 - Policy Label 2. First Line(s) of Text in Message Body If one or more policy labels are attached to an message by the author, the client MAY include a first line(s) of text in the message body that identifies the policies associated with the message. If the first line(s) of text is used for visual marking, the first line(s) of text MUST be included in the message body before the message is sent. If multiple policies exist, the policy markings SHOULD be delineated by a carriage return, such that each policy is contained on a separate line within the . Last Line(s) of Text in Message Body If one or more policy labels are attached to an message by the author, the client MAY include a last line(s) of text in the message body that identifies the policies associated with the message. If the last line(s) of text is used for visual marking, the last line(s) of text MUST be included in the message body before the message is sent. If multiple policies exist, the policy markings SHOULD be delineated by a carriage return, such that each policy is contained on a separate line within the Applying Policy to In order to communicate the context of the information contained in an for recipients, the author of the MAY attach a policy label(s) to an message. The author MAY choose not to apply any policy labels to an . The client MUST provide a means for authors to use their authoring tools to attach policy labels to an message. The client MUST allow the user to attach up to three policy labels to each message Constraining of Policy Labels Availability to Authors The author SHOULD be presented with only those policy labels they are authorized to use Managing Business Authorization Policies A labeling administration tool SHOULD be used to administer which labels are available to the system users. The labeling administration tool SHOULD provide a means to restrict the creation and modification of policies to only authorized administrators. Secure v.2 Technical Specification Page 9 of 24

16 Authentication Enforcement If an ESS label is attached to a message, the client MUST require the sender to digitally sign the message (in accordance with RFC 2634). The message digital signature MUST meet the requirements of the TSCP SE v.1 specifications. The client SHOULD ensure the certificate policy of the signing certificate meets the level of assurance requirement for the selected policy label(s) (see TSCP BAF). The client MUST ensure that the signature of a received is verified and that the user is alerted if the signature fails Authorization Enforcement If a policy requires a message be encrypted (see TSCP BAF), the client MAY be configured to require the sender to encrypt the message for all recipients. The message encryption MUST meet the requirements of the TSCP SE v.1 specifications. The client MAY allow a sender to encrypt a message, even if the policy does not require it. The client SHOULD ensure the certificate policy of the recipient s encryption certificate meets the level of assurance requirement for the selected policy label(s) (see TSCP BAF) Inheritance of Labels from Attachments When adding an attachment to an message, the client SHOULD check the attachment for policy information. The policy information MUST be provided in the following manner: Table 3. Format of Policy Information for Different File Types File Type Policy Identifier Location Policy Identifier Name OOXML Document Customer Property urn:bails:{type}:businessauthorizationcategory:identifier:oid Values for attachment policy identifiers will be explicitly identified in TSCP BAF. If an attachment policy identifier is identified, the client SHOULD determine if the OID is recognized. If the OID is not recognized, the client MAY: Ignore the policy identifier in the attachment Create a log of the event including the policy identifiers in the attachment Display an administrator authored warning message to the user Block the file from being attached If the OID is recognized, the client MAY: Apply the policy label(s) to the which correspond to the policy identifier in the attachment Display an administrator authored warning message to the user, allowing them to opt in or out of applying a policy label to the If the document attached is protected by encryption (e.g., by a digital rights management system), then the client will not be able to inherit any labels from the document. Secure v.2 Technical Specification Page 10 of 24

17 Client Behavior When Receiving Unrecognized Policy Labels The client MUST allow at least one of the following actions when receiving a message with an unrecognized policy label: Create a log of the event Display an administrator authored warning message to the user Block the message from being viewed by the user Client Behavior When Receiving Recognized Policy Labels for Which the Recipient Is Not Authorized The client MUST allow at least one of the following actions when receipt of a message is recognized by the organization, but the user is not explicitly configured to view the information: Ignore the policy and display the message Create a log of the event Display an administrator authored warning message to the user Block the message from being viewed by the user Enabling Inspection of S/MIME Encrypted Messages by Inspecting Gateways If a policy authority requires inspection of encrypted message content by the sending and or receiving organization, the client message MAY include a Cryptographic Message Syntax RecipientInfo token (for the sending and/or receiving inspecting gateway). This token contains the message key encrypted via the inspecting gateway s public key so the inspecting gateway can decrypt the message using its private key to recover the message key. The sender s client SHOULD add the inspecting gateway s CMS RecipientInfo token (as documented in RFC 5652) on the basis of the sender and recipient(s) inspection policies. This process SHOULD occur without user intervention. The sender s client SHOULD check the assurance level of the certificate used by the inspecting gateway. 3.3 Technical Specifications for SE v.2 Inspecting Gateways The inspecting gateway MAY also be used to convert an internal label format to the SE v.2 standard format (see 3.1) for outgoing messages, and for converting from the SE v.2 format to the internal label format for incoming messages. An inspecting gateway is required by organizations that support labeling mechanisms that are not natively capable of producing SE v.2 compliant messages. Where the sender and recipient systems both support non-standard labeling mechanisms, both the sender and recipient will require inspecting gateways if they are to communicate using the standard. However, if the two systems are compatible with each other, and the sender knows this, then it is possible for the communication to be made directly without conversion by any inspecting gateway. For avoidance of doubt, the primary focus of SE v.2 is to ensure the consistent formatting of messages being sent between organizations so the use of non-standard label formats between organizations are not compliant with this specification. The use of inspecting gateways is an OPTIONAL component in the SE v.2 design that would be required to allow interoperability between organizations where the clients support the label structure identified in this specification (see section 3.1) and those organizations wherein clients only support alternative label formats (e.g., SMTP X-headers). Single policy ESS Security labels also represent a known subset of labeling clients. In addition, an inspecting gateway MAY be used to enforce security policy over the messages that are exported from, or imported to, an SE v.2 compliant system. Secure v.2 Technical Specification Page 11 of 24

18 Table 4 below summarizes the use cases under which an inspecting gateway is required, and when it is optional. Table 4. Inspecting Gateway Use Cases Inspecting Gateway Requirement Use Cases Sender SE v.2 Client Single Policy ESS Security Label Client Alternative Format Labeling Client SE v.1 Client with No Labeling Support SE v.2 Client See Section See Section Recipient Single Policy ESS Security Label Client See Section Alternative Format Labeling Client See Section SE v.1 Client with No Labeling Support Key: Sender Inspecting Gateway Required Inspecting Gateway Required Sender and Recipient Inspecting Gateway Required Inspecting Gateway Optional The specifications for SE v.2 are designed to allow interworking with SE v.1 without an inspecting gateway, though in this case, an inspecting gateway MAY still be employed to enforce security controls. SE v.2 specifies particular ways to associate security label information with messages ESS equivalent label attributes carry policy information. Where systems support security label information in other formats, such as SMTP X-headers, and single policy ESS Security Labels (i.e., esssecuritylabel attribute), an inspecting gateway is required for the systems to interwork. An inspecting gateway is not required in the following scenarios, but MAY be deployed to provide for border inspection of encrypted content: SE v.2 client sends to another SE v.2 client SE v.1 client which does not support labeling sends to any client SE v.1 client which does not support labeling receives from any client A sender s inspecting gateway is REQUIRED in the following scenarios to perform label translation: Alternative format labeling client sends to an SE v.2 client Secure v.2 Technical Specification Page 12 of 24

19 Single policy esssecuritylabel client sends to an SE v.2 client A recipient s inspecting gateway is REQUIRED in the following scenarios to perform label translation: SE v.2 client sends to an alternative format labeling client SE v.2 client sends to a single policy esssecuritylabel client A sender and recipient inspecting gateway is REQUIRED in the following scenarios to perform label translation when SE v.2 is desired as the common transmission format: Alternative format labeling client sends to an alternative format labeling client Alternative format labeling client sends to a single policy esssecuritylabel client Single policy esssecuritylabel client sends to a single policy esssecuritylabel client Single policy esssecuritylabel client sends to an alternative format labeling client Sender s Organization Recipient s Organization Internet Client S Gateway S Gateway R Client R Figure 4. Sending and Receiving Inspecting Gateway Configuration Translation of SE v.2 messages to Alternate Format Recipients The following section identifies the conversion REQUIRED by a recipient s inspecting gateway to perform label translation from the SE v.2 format to single policy ESS or an alternative labeling format. Currently, SMTP X-headers are a common alternative labeling format for carrying labels in messages. For exemplary purposes, this section will document how an inspecting gateway can support SMTP X-headers; however, this specification does not limit translations to alternative format labeling format types Translation of Messages to Single Policy ESS Recipients Where an SE v.2 client is used to prepare a message, the sender will label the message using the ESS equivalent label attribute. If such a message is sent to a single policy esssecuritylabel client, the recipient system s inspecting gateway MUST modify the message to allow the label information to be carried from originator to recipient. On receipt of such a message, the recipient s inspecting gateway extracts the OIDs representing the message s TSCP BAILS policies from the ESS signed attributes. The inspecting gateway MUST map the BAILS policies to a single ESS policy of the receiving organization by adding an equivalent ESS label to the message. Rules for the mapping between multiple labels to single labels are specified in BAF. It then amends the message to include an additional signature. This signature belongs to the inspecting gateway and contains some representation, using the recipient s policy, of the BAILS OIDs in a single ESS equivalent label attribute. This does not alter any of the message s signed data, though the recipient will find the message is signed by the originator and the inspecting gateway. An inspecting gateway SHOULD support the addition of a signature with a single ESS equivalent label carrying the recipient s mapped ESS equivalent labels. The signature carrying the additional label SHALL belong to the inspecting gateway. The inspecting gateway SHALL include the signing key s certificate in the signature. Secure v.2 Technical Specification Page 13 of 24

20 Content Type = Application/pkcs7 Signed Data Digest Alg ID Content Type = Application/pkcs7 Signed Data Digest Alg ID Signed Message Contents Signed Message Contents Signer Infos Signer Infos Signer Info #1 Client S Signer Info #1 Client s Signer ID Signed Attributes Recipient Gateway Signer ID Signed Attributes ESS Label ESS Label BAILS policy OID s BAILS policy OID s Signature Signature SE v.2 Message Signer Infos Signer Info #2 Gateway R Signer ID Signed Attributes ESS Label Local Org Policy Signature Message Augmented With Single ESS Policy Figure 5. Conversion of SE v.2 Message to Single Policy ESS Message Secure v.2 Technical Specification Page 14 of 24

21 SE v.2 Sender to an Alternate Format Label Recipient Where an SE v.2 client is used to prepare a message, it will label the message by adding an ESS equivalent label attribute to each labeled message. If such a message is sent to a client that uses SMTP X-headers to carry message security labels, the recipient system s inspecting gateway MUST modify the message to allow the label information to be carried from the originator to the recipient. On receipt of such a message, the recipient s inspecting gateway extracts the OIDs representing the message s TSCP BAILS policies from the ESS equivalent label attribute. It then amends the message to include the OIDs as data in SMTP X-headers. This does not alter any of the message s signed data because the SMTP headers are outside the signature, thus end-to-end integrity of the message content is preserved. An inspecting gateway SHOULD support the addition of SMTP X-headers carrying the BAILS policy OIDs taken from SE v.2 messages ESS equivalent labels. X-header BAILS policy OIDs Content Type = Application/pkcs7 Content Type = Application/pkcs7 Signed Data Digest Alg ID Signed Data Digest Alg ID Signed Message Contents Signed Message Contents Signer Infos Signer Infos Signer Info #1 Client S Signer ID Signed Attributes Recipient Gateway Signer Info #1 Client S Signer ID Signed Attributes ESS Label ESS Label BAILS policy OID s BAILS policy OID s Signature Signature SE v.2 Message Message Augmented With SMTP X-header Figure 6. Conversion of SE v.2 Message to SMTP X-Header Message Secure v.2 Technical Specification Page 15 of 24

22 3.3.2 Translation of Messages to SE v.2 Recipients The following section identifies the conversion REQUIRED by a sender s inspecting gateway to perform label translation from the single policy ESS or SMTP X-headers to the SE v.2 format Translation of Single Policy ESS Security Messages to SE v.2 Equivalent Recipients Where a single policy esssecuritylabel client uses a single ESS label to carry a policy in messages that are to be delivered to an SE v.2 client, the sender s inspecting gateway MUST modify the message to allow the label information to be carried from originator to recipient. On receipt of such a message, the sender s inspecting gateway extracts the OID(s) representing the message s policies in some local format from the ESS signed attributes and maps to the BAILS policies, as well as adds the SE v.2 equivalent ESS equivalent label attribute to the message. The inspecting gateway then amends the message to include an additional signature. This signature belongs to the inspecting gateway. This does not alter any of the message s signed data, though the recipient will find both the originator and the inspecting gateway signed the message. The recipient s inspecting gateway MAY check the incoming message to confirm that the signature containing the BAILS label belongs to the inspecting gateway of the sender. An inspecting gateway SHOULD support the addition of a signature with an ESS equivalent label carrying the BAILS policy OIDs taken from a single ESS label. The original signature and single ESS label SHALL be preserved. The signature carrying the added label SHALL belong to the inspecting gateway. The sender s inspecting gateway SHALL include the signing key s certificate in the signature. Secure v.2 Technical Specification Page 16 of 24

23 Content Type = Application/pkcs7 Signed Data Digest Alg ID Content Type = Application/pkcs7 Signed Data Digest Alg ID Signed Message Contents Signed Message Contents Signer Infos Signer Info #1 Client S Signer ID Signed Attributes esssecuritylabel ESS Label Local Org Policy Sender s Gateway Signer Infos Signer Info #1 Client S Signer ID Signed Attributes esssecuritylabel ESS Label Local Org Policy Signature Signature Single Policy ESS Security Label Signer Infos Signer Info #2 Gateway S Signer ID Signed Attributes ESS Label BAILS policy OID s Signature Message Augmented With SE v.2 ESS Equivalent Attribute Label Figure 7. Single Policy ESS Security Label Sender to SE v.2 Equivalent Label Attribute Message Recipient Inspecting Gateway Conversion Secure v.2 Technical Specification Page 17 of 24

24 Translation of Alternate Format Labels to SE v.2 Recipients Where an SMTP X-headers client uses X-headers to carry the labels in messages that are to be delivered to an SE v.2 client, the sender s inspecting gateway MUST modify the outgoing message to allow the label information to be carried from the originator to the recipient. In most circumstances, it is expected that the inspecting gateway will extract the OIDs representing the message s TSCP BAILS policies from the SMTP X-headers. The inspecting gateway MUST add the SE v.2 equivalent label to the . The inspecting gateway MUST sign the message using one of the following approaches: Option 1: Inspecting Gateway Replaces the Signature of the Sender with the Signature of the Inspecting Gateway. If the inspecting gateway removes the sender s signature, and adds an inspecting gateway signature, the follow requirements apply: The inspecting gateway MUST validate the original signature of the sender and ensure the sender s signature validates to a trusted Certificate Authority. The inspecting gateway MUST check the sender s certificate revocation status to ensure the certificate of the sender is not revoked. The inspecting gateway SHOULD ensure the certificate policy of the sender s signing certificate meets the level of assurance requirement for the attached policy label(s). The inspecting gateway MUST sign the message with a certificate that is commensurate with, or higher than, the level of the sender s certificate The inspecting gateway SHOULD add text into the body of the to indicate what changes have been made to the message. If there is a requirement for nonrepudiation, then the inspecting gateway MUST add text into the body of the to indicate what changes have been made to the message. Option 2: Inspecting Gateway Adds a Second Signature. If the inspecting gateway adds a second signature to the message, the following requirements apply: The inspecting gateway MUST maintain the sender s signature in the message. The inspecting gateway MUST sign the message with a certificate which is commensurate with, or higher than, the level of the sender s certificate. The sender s inspecting gateway SHOULD remove the SMTP X-headers. The inspecting gateway SHALL include the signing key s certificate in the signature. The recipient s inspecting gateway MAY check the incoming message to confirm that the signature containing the BAILS label belongs to the inspecting gateway of the sender. Secure v.2 Technical Specification Page 18 of 24

25 X-header BAILS policy OIDs X-header BAILS policy OIDs Content Type = Application/ pkcs7 Signed Data Content Type = Application/pkcs7 Signed Data Content Type = Application/ pkcs7 Signed Data Content Type = Application/pkcs7 Signed Data Digest Alg ID Digest Alg ID Digest Alg ID Digest Alg ID Signed Message Contents Signed Message Contents Signed Message Contents Encapsulated Message Contents Signer Infos Signer Info #1 Client S Sender s Gateway Signer Infos Signer Info #1 Gateway S Signer Infos Signer Info #1 Client S Sender s Gateway Signer Infos Signer Info #1 Client S Signer ID Signer ID Signer ID Signer ID Signed Attributes Signed Attributes Signed Attributes Signed Attributes Signature Message with Alternate Format Label ESS Label BAILS policy OID s Signature Signature Message with Alternate Format Label Signature Signer Infos Signer Info #2 Gateway S Message Generated by an Inspecting Gateway Signer ID Signed Attributes ESS Label BAILS Policy OIDs Signature Message Generated by an Inspecting Gateway Gateway Signing Option 1 Gateway Signing Option 2 Figure 8. Message with SMTP X-headers Sender to SE v.2 Equivalent Label Attribute Message Recipient Inspecting Gateway Conversion Inspection of S/MIME Encrypted Messages S/MIME encryption provides end to end confidentiality of the message content. However, this security also prevents scanners from detecting malware in the message. In some cases, a sending and/or receiving organization MAY wish to allow trusted inspecting gateways to decrypt and inspect the contents of the message for malware before allowing it to pass into or out of the organization. Where messages are encrypted and there is a requirement for the message to be inspected at the boundary of the sender or receiver s system, the sender or receiver s inspecting gateway MUST decrypt the message so it can apply the required checks. The checks might be needed to ensure that the recipients are authorized to receive the content, that sensitive content is not released, and that the content is free of known viruses. Secure v.2 Technical Specification Page 19 of 24

26 Encrypting for the Senders Inspecting Gateway In order to decrypt the message, the message MUST include a CMS RecipientInfo token for the sender s inspecting gateway. This contains the message key encrypted using the inspecting gateway s public key, so the inspecting gateway can decrypt this using its private key to recover the message key, which it uses to decrypt the message. Based on the domains of a message s recipient, an inspecting gateway SHOULD support the addition of other inspecting gateways as CMS recipients of outgoing messages. Encrypting for the Recipients Inspecting Gateway It may also be a requirement for the recipient s inspecting gateway to be able to inspect incoming encrypted messages before they are delivered to the recipient. The checks might be needed to ensure the content is appropriate for the business and free of malware. In order to apply these checks, the recipient s inspecting gateway MUST be able to decrypt the message and so the message MUST include a CMS RecipientInfo token for the inspecting gateway. The recipient inspecting gateway CMS token MAY either be added by the sender s client or by the sender s inspecting gateway. Encrypting Requirements Applicable to both the Sender and Recipient Inspecting Gateways An inspecting gateway MAY support the inspection of encrypted messages. The sender MUST trust the inspecting gateway to protect the clear text form of the message content it handles. The inspecting gateway MUST not disclose the message key or message content. If local policy dictates the inspecting gateway MUST keep a record of all released messages, this data SHOULD be retained in encrypted form. Once an inspecting gateway has checked an encrypted message, it SHOULD remove its CMS RecipientInfo token from the message to avoid disclosing cryptographic material unnecessarily. An inspecting gateway SHALL NOT record the plain text of an encrypted message in any audit log Inspecting Gateway Key Management An inspecting gateway SHALL protect its private signing key in accordance with the conditions of the certificate policy that governs its signing certificate. An inspecting gateway SHALL protect private decryption keys if it is decrypting messages passing through it in accordance with the conditions of the certificate policy that governs its signing certificate Receiving organizations that require their inspecting gateway to decrypt S/MIME encrypted messages MUST notify their partners in sending domains. The inspecting gateway certificate MUST be made public to allow senders to include the CMS RecipientInfo token for the inspecting gateway in their S/MIME encrypted s. 3.4 Distribution of Configuration Information The SE v.2 specification requires that sending and receiving organizations share a predetermined set of data in order for both sides to configure their systems in an interoperable and commensurate manner Recommended Configuration Data Exchange Methodology: TSCP Business Authorization Framework Both the sending and receiving organizations SHOULD use TSCP BAF to exchange configuration data. BAF defines a process model, a logical data model, and interchange formats which Secure v.2 Technical Specification Page 20 of 24