Gateways and MIME Security Multiparts

The information below is for an old version of the document that is already published as an RFC
Document Type RFC Internet-Draft (individual)
Author Ned Freed 
Last updated 2013-03-02 (latest revision 1998-09-10)
Stream Legacy stream
Formats pdf htmlized (tools) htmlized bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 2480 (Proposed Standard)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                Ned Freed
Internet Draft                    <draft-freed-gatesec-03.txt>

                   MIME Security Multiparts

                        September 1998

                     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-

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 view the entire list of current Internet-Drafts, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on (Africa), (Northern Europe), (Southern
Europe), (Pacific Rim), (US East
Coast), or (US West Coast).

Copyright (C) The Internet Society (1998).  All Rights

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

Internet Draft Gateways and Security Multiparts September 1998

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

       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

                      Expires March 1999              [Page 2]

Internet Draft Gateways and Security Multiparts September 1998

       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

       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
Show full document text