Internet Draft Authors: Blake Ramsdell, draft-ramsdell-enc-smime-gateway-01.txt Brute Squad Labs June 30, 2002 Ben Littauer, Consultant Expires December 30, 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 as a profile of [DOMSEC]. 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 This draft is being discussed on the "ietf-smime" mailing list. To subscribe, send a message to: ietf-smime-request@imc.org with the single word subscribe in the body of the message. There is a Web site for the mailing list at <http://www.imc.org/ietf-smime/>. 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]. This document is meant to be an encrypting only profile of [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] as further specified by section 4.1 of [DOMSEC]. [DOMSEC] specifies certain naming restrictions MUST be used and that are specifically inherited by this profile. A summary of the certificate naming considerations is as follows: 1. Inclusion of a CN attribute in the subject of the certificate containing the value "domain-confidentiality-authority". 2. The subject DN or a subjectAltName extension MUST list at least one Internet mail domain of the form "domain-confidentiality-authority@domain". This differs slightly from [DOMSEC] in that this profile requires the inclusion of an email address in order to determine certificate suitability for a particular 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 <sub.domain> and domain, it MUST use the certificate for <sub.domain> when sending to a recipient in <sub.domain>, even though the recipient is also a member of <domain>. 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 [DOMSEC] "Domain Security Services using S/MIME", RFC 3183 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119 [SMIMEV3MSG] "S/MIME Version 3 Message Specification", RFC 2633 [SMIMEV2MSG] "S/MIME Version 2 Message Specification", RFC 2311 [SMIMEV3CERT] "S/MIME Version 3 Certificate Handling", RFC 2632 B. Acknowledgements Comments were made by members of the staffs of: CareGroup, Massachusetts Health Data Consortium, Brute Squad Labs, Tumbleweed Communications, Baltimore Technologies, Dica Technologies, .TFS Technologies, Vanguard Security Technologies, and Viasec (RIP). William Ottaway also provided significant insight into [DOMSEC] and helped clarify the role of this document as a [DOMSEC] profile. C. Authors' addresses Blake Ramsdell Brute Squad Labs Suite 217-C 16451 Redmond Way Redmond, WA 98052-4482 blake@brutesquadlabs.com Ben Littauer Consultant for Massachusetts Health Data Consortium 1 Moon Hill Road Lexington, MA 02421 +1 781 862 8784 littauer@blkk.com D. Changes from last draft Lots of piddly stuff (high-bit characters, author's address, formatting) (Blake Ramsdell) Rewording to profile of DOMSEC (Blake Ramsdell, William Ottaway)