HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 23:58:33 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 05 Nov 1997 18:13:00 GMT ETag: "2e999b-2453-3460b72c" Accept-Ranges: bytes Content-Length: 9299 Connection: close Content-Type: text/plain Network Working Group Ned Freed Internet Draft Gateways and MIME Security Multiparts November 1997 Status of this Memo This document is an Internet-Draft. 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. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The current draft of this memo reflects comments received during the last call period. In particular, a reference to RFC 2119 has been added, as have some directives on how to handle character sets with embedded language tagging facilities. 1. Abstract This document examines the problems associated with use of MIME security multiparts and gateways to non-MIME environments. A set of requirements for gateway behavior are defined which provide satisfactory facilities to accomodate the transfer of security multiparts through gateways. Internet Draft Gateways and Security Multiparts November 1997 2. Requirements notation This document occasionally uses terms that appear in capital letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD NOT", and "MAY" appear capitalized, they are being used to indicate particular requirements of this specification. A discussion of the meanings of these terms appears in RFC 2119 [3]. 3. The Problem Security multiparts [RFC-1847] provide an effective way to add integrity and confidentiality services to protocols that employ MIME objects [RFC-2045, RFC-2046]. Difficulties arise, however, in heterogeneous environments involving gateways to environments that don't support MIME. Specifically: (1) Security services have to be applied to MIME objects in their entirety. Failure to do so can lead to security exposures. For example, a signature that covers only object data and not the object's MIME labels would allow someone to tamper with the labels in an undetectable fashion. Similarly, failure to encrypt MIME label information exposes information about the content that could be exploited by an eavesdropper. Composite MIME objects (e.g. multipart/mixed, message/rfc822) also have to be secured as a unit. Again, failure to do so may facilitate tampering, reveal important information unnecessarily, or both. (2) Gateways that deal with MIME objects have to be able to convert them to non-MIME formats. For example, gateways often have to transform MIME labelling information into other forms. MIME type information may end up being expressed as a file extension or as an OID. Gateways also have to take apart composite MIME objects into their component parts, converting the resulting Expires May 1998 [Page 2] Internet Draft Gateways and Security Multiparts November 1997 set of parts into whatever form the non-MIME environments uses for composite objects. Failure to do so makes the objects unusable. In many cases this means that multi-level MIME structures having to be converted into a sequential list of parts. (3) Security services have to be deployed in an end-to-end fashion. Failure to do so again can lead to security exposures. An integrity service deployed at something other than a connection end point means a window exists where object tampering is possible. A confidentiality service deployed at something other than a connection end point means a window exists where the object is transferred in the clear. And worse, distibuted keys are usually necessary whenever someone other than the originator applies an integrity service or someone other than the recipient removes a confidentiality service. All of these issues can be addressed, of course. For example, it may be possible to use multiple overlapping security services to assure that no exposure exists even though there is no end-to-end security per se. And keys can be distributed in a secure fashion. However, such designs tend to be quite complex, and complexity in a security system is highly undesireable. The preceeding three requirments are fundamentally in conflict: It is possible to satisfy two of them at once, but not all three at once. In fact the conflict is even worse than it first appears. In most situations of this sort some sort of compromise is possible which, while not satisfying any of the requirements completely, does optimize some sort of average of all the requirements. Such a solution does not exist in this case, however, because many real world situations exist where any one of these requirements absolutely must be satisfied. 4. Solving the Problem Since the previously described problem doesn't allow for a single solution the only viable approach is to require that Expires May 1998 [Page 3] Internet Draft Gateways and Security Multiparts November 1997 gateways provide multiple solutions. In particular, gateways (1) MUST provide the ability to tunnel multipart/signed and multipart/encrypted objects as monolithic entities. No changes to content of the multipart are permitted. This option must be provided so that entities behind the gateway that are capable of processing security multiparts and their MIME content will work properly. (2) MUST provide the ability to take apart multipart/signed objects, exposing the content (and in the process ruining the signature). When this approach is selected gateways SHOULD remove the signature entirely and replace it with a note indicating its removal. This option must be provided so that entities behind the gateway which are incapable of processing MIME will work properly. (3) SHOULD provide the ability to select between the previous two options on per-user basis. (4) MAY provide facilities to check signatures and decrypt encrypted content. Such facilities MUST NOT be enabled by default; the potential security exposure involved has to be assessed before such capabilities can be used. (5) MAY provide facilities to sign and/or encrypt material passing from the non-MIME side to the MIME side of the gateway. Again, such facilities MUST NOT be enabled by default; the potential security exposure involved in the transfer of unsecured content within the gateway has to be assessed before such capabilities can be used. A gateway which complies with the above requirements is considered to be security multiparts compliant. 5. Security Considerations Expires May 1998 [Page 4] Internet Draft Gateways and Security Multiparts November 1997 This entire document is about security. 6. References [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822 August, 1982. [RFC-1847] Galvin, J., Murphy, S., Crocker, S., Freed, N., " Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [RFC-2045] Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, Innosoft, First Virtual Holdings, December 1996. [RFC-2046] Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual Holdings, December 1996. [RFC-2049] Freed, N. and Borenstein, N., "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, Innosoft, FIrst Virtual Holdings, December 1996. [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 7. Author Address Ned Freed Innosoft International, Inc. 1050 Lakes Drive West Covina, CA 91790 USA tel: +1 626 919 3600 fax: +1 626 919 3614 email: ned.freed@innosoft.com Expires May 1998 [Page 5] Internet Draft Gateways and Security Multiparts November 1997 Expires May 1998 [Page 6]