Gateways and MIME Security Multiparts
draft-freed-gatesec-03

Network Working Group                                Ned Freed
Internet Draft                    <draft-freed-gatesec-03.txt>

                           Gateways
                             and
                   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-
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 view the entire list of current Internet-Drafts, please
check the "1id-abstracts.txt" listing contained in the
Internet-Drafts Shadow Directories on ftp.is.co.za (Africa),
ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern
Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East
Coast), or ftp.isi.edu (US West Coast).

Copyright (C) The Internet Society (1998).  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.




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

                      Expires March 1999              [Page 3]



Internet Draft Gateways and Security Multiparts September 1998

4.  Solving the Problem

Since the previously described problem doesn't allow for a
single solution the only viable approach is to require that
gateways provide multiple solutions.  In particular, gateways

 (1)   MUST provide the ability to tunnel multipart/signed and
       multipart/encrypted objects as monolithic entities if
       there is any chance whatsoever that MIME capabilities
       exist on the non-MIME side of the gateway. No changes
       to content of the multipart are permitted, even when
       the content is itself a composite MIME object.

       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.
       As mentioned previously, situations exist where
       application security requirements are absolute and must
       be accomodated, even when meeting them causes problems
       for other agents.

       Exceptions are allowed only when there is no
       possibility of MIME support on one side of the gateway.
       For example, a gateway to a voice messaging system may
       have no useful way to represent a signed MIME object.

 (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 NOT remove the signature. Instead,
       gateways SHOULD keep the signature intact and add to it
       a note that it will probably be invalid for checking
       the message contents, but may still be contain valuable
       information about the sender.

       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

                      Expires March 1999              [Page 4]



Internet Draft Gateways and Security Multiparts September 1998

       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
       application domain behind 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

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-1123]
     Braden, R., Editor, "Requirements for Internet Hosts --
     Application and Support", RFC 1123, October 1989.

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

                      Expires March 1999              [Page 5]



Internet Draft Gateways and Security Multiparts September 1998

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

7.  Author's 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

8.  Full Copyright Statement

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

This document and translations of it may be copied and
furnished  to others, and derivative works that comment on or
otherwise  explain it or assist in its implementation may be
prepared, copied,  published and distributed, in whole or in
part, without  restriction of any kind, provided that the
above copyright notice  and this paragraph are included on all
such copies and derivative  works.  However, this document
itself may not be modified in any  way, such as by removing
the copyright notice or references to the  Internet Society or
other Internet organizations, except as needed for the purpose
of developing Internet standards in which case the  procedures
for copyrights defined in the Internet Standards  process must
be followed, or as required to translate it into languages
other than English.

The limited permissions granted above are perpetual and will
not be revoked by the Internet Society or its successors or

                      Expires March 1999              [Page 6]



Internet Draft Gateways and Security Multiparts September 1998

assigns.

This document and the information contained herein is provided
on  an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
USE OF  THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.

                      Expires March 1999              [Page 7]