[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 rfc2480                                           
Network Working Group                                Ned Freed
Internet Draft                    <draft-freed-gatesec-00.txt>

                           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]