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.


. 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

<TBD>


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


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


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


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


. 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
 NE 65th St Ste 201
Redmond, WA 98052
+1 425 376 0225
blake.ramsdell@tumbleweed.com

Ben Littauer
Consultant for Massachusetts Health Data Consortium
 Moon Hill Road
Lexington, MA 02421
+1 781 862 8784
littauer@blkk.com