Internet Draft Authors: Blake Ramsdell, draft-ramsdell-enc-smime-gateway-00.txt Tumbleweed Communications July 12, 2001 Ben Littauer, Consultant Expires January 12, 2002 Massachusetts Health Data Consortium S/MIME Gateway Protocol Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Overview In addition to desktop-to-desktop security, S/MIME can be used for server-to-server encryption between cooperating domains. This document will describe a method for implementing server-to-server (gateway) encryption with S/MIME. 1.1 Terminology 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 [MUSTSHOULD]. 1.2 Discussion of This Draft 2. Problem Overview In order to prevent exposure of confidential content in e-mail messages traversing the Internet, it is desirable to encrypt such traffic between cooperating domains. S/MIME provides the protocol and message format for such encryption, but conventions must be established for domain-level certificates to enable an encrypting gateway to recognize when a message is going to a foreign domain that requires encryption. Note that an encryption gateway is not a signing entity for purposes of this protocol. Signing at the domain level is an important function, but it is beyond the scope of this memo, and is being addressed by the Domain Security effort as published in [DOMSEC]. 3. Message Structure Overview An encrypted message as described in [SMIMEV3MSG] or [SMIMEv2MSG] is used in an S/MIME gateway context. A gateway-encrypted message will simply encapsulate an existing MIME or S/MIME message in an encryption "wrapper". 4. Domain Certificates A gateway is associated with one or more domains or sub-domains. Messages between gateways are handled based on their domains, not on the basis of individual addressees. Gateway certificates are called "Domain Certificates", and have the same format as S/MIME Version 3 certificates [SMIMEV3CERT] with the exception that the subject DN or a subjectAltName extension MUST list at least one Internet mail domain of the form "smg_encryptor@domain". Multiple domains that are handled by a gateway MAY be listed in a single certificate, or multiple certificates MAY be used. Note that the naming convention in use here uses the same notion of domain "membership" as that used in [DOMSEC] section 3.1.1. Loosely, an entity is a member of a domain if its RFC-822 address has the domain as its rightmost component. Note further that the gateway must process ô@domainö components in order from most specific to least specific, i.e. if it holds domain certificates for both and domain, it MUST use the certificate for when sending to a recipient in , even though the recipient is also a member of . 5. Message Processing An S/MIME Gateway must be associated with one or more domains. A message received for processing by the gateway is defined to be "outbound" if the originator of the message is a member of one of the domains associated with the gateway. All other messages are defined to be "inbound". 5.1 Outbound Message Processing S/MIME gateway outbound processing is as follows: When a message is received with a destination within a domain for which the gateway has a domain certificate, the gateway MUST perform S/MIME encryption with the domain certificate for that destination. Mechanisms for the lookup and validity checking of destination mail gateway certificates are beyond the scope of this document. 5.2 Inbound Message Processing S/MIME gateway inbound processing is as follows, if a message is received encrypted using the public key contained in the gatewayÆs domain certificate: 1. The gateway MUST perform S/MIME decryption of the message. 2. If the decryption is unsuccessful, the gateway will process the failure according to local convention (log an event, etc.) The gateway MUST NOT relay the encrypted message onto the next hop. 3. The gateway MUST relay the decrypted message to the next hop. Any other message SHOULD be relayed unaltered. 6. Security Considerations If the gateway has valid certificates for some, but not all of the domains represented by recipients of the outbound message, there is a security issue, namely that the message may be encrypted on the Internet for some destinations, but not others. Of course, this increases the risk of exposure for that message. A gateway SHOULD provide an administrative option to prevent transmission of a message to a secured and un-secured recipient in order to reduce this risk. A. References [SMIMEV3MSG] "S/MIME Version 3 Message Specification", RFC 2633 [SMIMEV2MSG] "S/MIME Version 2 Message Specification", RFC 2311 [DOMSEC] "Domain Security Services using S/MIME", http://www.ietf.org/internet-drafts/draft-ietf-smime-domsec-08.txt [SMIMEV3CERT] "S/MIME Version 3 Certificate Handling", RFC 2632 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119 B. Acknowledgements Comments were made by members of the staffs of: CareGroup, Massachusetts Health Data Consortium, Tumbleweed Communications, Baltimore Technologies, Dica Technologies, .TFS Technologies, Vanguard Security Technologies, and Viasec (RIP). C. Changes from last draft Revision û01 (Littauer) Moved handling of message to multiple domains, some secured, some not, to ôSecurity Considerations Sectionö. Added note regarding of handling of sub-domains in Domain Certificates section. Revision û02 (Littauer and Ramsdell) Changed status from draft to informational. Cleaned up formatting Revised reference to latest domsec draft (-08) Added acknowledgements D. AuthorsÆ addresses Blake Ramsdell Tumbleweed Communications 17720 NE 65th St Ste 201 Redmond, WA 98052 +1 425 376 0225 blake.ramsdell@tumbleweed.com Ben Littauer Consultant for Massachusetts Health Data Consortium 1 Moon Hill Road Lexington, MA 02421 +1 781 862 8784 littauer@blkk.com