Gateways and MIME Security Multiparts
RFC 2480

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                        N. Freed
Request for Comments: 2480               Innosoft International, Inc.
Category: Standards Track                                January 1999

                 Gateways and MIME Security Multiparts

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

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
   facilities necessary to properly accomodate the transfer of security
   multiparts through gateways.

2.  Requirements Notation

   This document occasionally uses terms that appear in capital letters.
   When the terms "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   appear capitalized, they are being used to indicate particular
   requirements of this specification. A discussion of the meanings of
   the terms "MUST", "SHOULD", and "MAY" appears in  RFC 1123 [2]; the
   terms "MUST NOT" and "SHOULD NOT" are logical extensions of this
   usage.

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.

Freed                       Standards Track                     [Page 1]
RFC 2480         Gateways and MIME Security Multiparts      January 1999

          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 facilitate traffic analysis.

          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 set of parts
          into whatever form the non-MIME environments uses for
          composite objects. Failure to do so makes the objects unusable
          in any environment that doesn't support MIME. In many cases
          this also means that multi-level MIME structures have 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 region exists between the point
          where the integrity service is applied and the actual end
          point where object tampering is possible. A confidentiality
          service deployed at something other than a connection end
          point means a region exists where the object is transferred in
          the clear. And worse, distributed private keys are usually
          necessary whenever someone other than the originator applies
          an integrity service or someone other than the recipient
          removes a confidentiality service, which in turn may make
          theft of private key information a possibility.

          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

Freed                       Standards Track                     [Page 2]
RFC 2480         Gateways and MIME Security Multiparts      January 1999

          undesireable.