idnits 2.17.1 draft-freed-gatesec-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 141 has weird spacing: '...ltipart are p...' == Line 239 has weird spacing: '...rnished to ot...' == Line 240 has weird spacing: '...herwise expla...' == Line 242 has weird spacing: '...without restr...' == Line 243 has weird spacing: '... notice and t...' == (5 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9379 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC-822' is defined on line 193, but no explicit reference was found in the text == Unused Reference: 'RFC-2049' is defined on line 213, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ned Freed 3 Internet Draft 5 Gateways 6 and 7 MIME Security Multiparts 9 August 1998 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted 21 by other documents at any time. It is not appropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as a "working draft" or "work in progress". 25 To view the entire list of current Internet-Drafts, please check 26 the "1id-abstracts.txt" listing contained in the Internet-Drafts 27 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 28 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 29 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 30 (US West Coast). 32 Copyright (C) The Internet Society (1998). All Rights 33 Reserved. 35 1. Abstract 37 This document examines the problems associated with use of 38 MIME security multiparts and gateways to non-MIME 39 environments. A set of requirements for gateway behavior are 40 defined which provide facilities necessary to properly 41 accomodate the transfer of security multiparts through 42 gateways. 44 2. Requirements Notation 46 This document occasionally uses terms that appear in capital 47 letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD 48 NOT", and "MAY" appear capitalized, they are being used to 49 indicate particular requirements of this specification. A 50 discussion of the meanings of these terms appears in [RFC- 51 2119]. 53 3. The Problem 55 Security multiparts [RFC-1847] provide an effective way to add 56 integrity and confidentiality services to protocols that 57 employ MIME objects [RFC-2045, RFC-2046]. Difficulties arise, 58 however, in heterogeneous environments involving gateways to 59 environments that don't support MIME. Specifically: 61 (1) Security services have to be applied to MIME objects in 62 their entirety. Failure to do so can lead to security 63 exposures. 65 For example, a signature that covers only object data 66 and not the object's MIME labels would allow someone to 67 tamper with the labels in an undetectable fashion. 68 Similarly, failure to encrypt MIME label information 69 exposes information about the content that could 70 facilitate traffic analysis. 72 Composite MIME objects (e.g., multipart/mixed, 73 message/rfc822) also have to be secured as a unit. 74 Again, failure to do so may facilitate tampering, 75 reveal important information unnecessarily, or both. 77 (2) Gateways that deal with MIME objects have to be able to 78 convert them to non-MIME formats. 80 For example, gateways often have to transform MIME 81 labelling information into other forms. MIME type 82 information may end up being expressed as a file 83 extension or as an OID. 85 Gateways also have to take apart composite MIME objects 86 into their component parts, converting the resulting 87 set of parts into whatever form the non-MIME 88 environments uses for composite objects. Failure to do 89 so makes the objects unusable in any environment that 90 doesn't support MIME. In many cases this also means 91 that multi-level MIME structures having to be converted 92 into a sequential list of parts. 94 (3) Security services have to be deployed in an end-to-end 95 fashion. Failure to do so again can lead to security 96 exposures. 98 An integrity service deployed at something other than a 99 connection end point means a region exists between the 100 point where the integrity service is applied and the 101 actual end point where object tampering is possible. A 102 confidentiality service deployed at something other 103 than a connection end point means a region exists where 104 the object is transferred in the clear. And worse, 105 distibuted private keys are usually necessary whenever 106 someone other than the originator applies an integrity 107 service or someone other than the recipient removes a 108 confidentiality service, which in turn may make theft 109 of private key information a possibility. 111 All of these issues can be addressed, of course. For 112 example, it may be possible to use multiple overlapping 113 security services to assure that no exposure exists 114 even though there is no end-to-end security per se. And 115 keys can be distributed in a secure fashion. However, 116 such designs tend to be quite complex, and complexity 117 in a security system is highly undesireable. 119 The preceeding three requirments are fundamentally in 120 conflict: It is possible to satisfy two of them at once, but 121 not all three at once. 123 In fact the conflict is even worse than it first appears. In 124 most situations of this sort some sort of compromise is 125 possible which, while not satisfying any of the requirements 126 completely, does optimize some sort of average of all the 127 requirements. Such a solution does not exist in this case, 128 however, because many real world situations exist where any 129 one of these requirements absolutely must be satisfied. 131 4. Solving the Problem 133 Since the previously described problem doesn't allow for a 134 single solution the only viable approach is to require that 135 gateways provide multiple solutions. In particular, gateways 137 (1) MUST provide the ability to tunnel multipart/signed and 138 multipart/encrypted objects as monolithic entities if 139 there is any chance whatsoever that MIME capabilities 140 exist on the non-MIME side of the gateway. No changes 141 to content of the multipart are permitted, even when 142 the content is itself a composite MIME object. 144 This option must be provided so that entities behind 145 the gateway that are capable of processing security 146 multiparts and their MIME content will work properly. 147 As mentioned previously, situations exist where 148 security requirements are absolute and must be 149 accomodated, even when the price of meeting them causes 150 problems for other agents. 152 Exceptions are allowed only when there is no 153 possibility of MIME support on one side of the gateway. 154 For example, a gateway to a voice messaging system may 155 have no useful way to represent a signed MIME object. 157 (2) MUST provide the ability to take apart multipart/signed 158 objects, exposing the content (and in the process 159 ruining the signature). When this approach is selected 160 gateways SHOULD remove the signature entirely and 161 replace it with a note indicating that it was removed. 163 This option must be provided so that entities behind 164 the gateway which are incapable of processing MIME will 165 work properly. 167 (3) SHOULD provide the ability to select between the 168 previous two options on per-user basis. 170 (4) MAY provide facilities to check signatures and decrypt 171 encrypted content. Such facilities MUST NOT be enabled 172 by default; the potential security exposure involved 173 has to be assessed before such capabilities can be 174 used. 176 (5) MAY provide facilities to sign and/or encrypt material 177 passing from the non-MIME side to the MIME side of the 178 gateway. Again, such facilities MUST NOT be enabled by 179 default; the potential security exposure involved in 180 the transfer of unsecured content within the gateway 181 has to be assessed before such capabilities can be 182 used. 184 A gateway which complies with the above requirements is 185 considered to be security multiparts compliant. 187 5. Security Considerations 189 This entire document is about security. 191 6. References 193 [RFC-822] 194 Crocker, D., "Standard for the Format of ARPA Internet 195 Text Messages", RFC 822, August, 1982. 197 [RFC-1847] 198 Galvin, J., Murphy, S., Crocker, S., Freed, N., " 199 Security Multiparts for MIME: Multipart/Signed and 200 Multipart/Encrypted", RFC 1847, October 1995. 202 [RFC-2045] 203 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 204 Extensions (MIME) Part One: Format of Internet Message 205 Bodies", RFC 2045, Innosoft, First Virtual Holdings, 206 December 1996. 208 [RFC-2046] 209 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 210 Extensions (MIME) Part Two: Media Types", RFC 2046, 211 Innosoft, First Virtual Holdings, December 1996. 213 [RFC-2049] 214 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 215 Extensions (MIME) Part Five: Conformance Criteria and 216 Examples", RFC 2049, Innosoft, FIrst Virtual Holdings, 217 December 1996. 219 [RFC-2119] 220 Bradner, S., "Key words for use in RFCs to Indicate 221 Requirement Levels", RFC 2119, March 1997. 223 7. Author's Address 225 Ned Freed 226 Innosoft International, Inc. 227 1050 Lakes Drive 228 West Covina, CA 91790 229 USA 230 tel: +1 626 919 3600 fax: +1 626 919 3614 231 email: ned.freed@innosoft.com 233 8. Full Copyright Statement 235 Copyright (C) The Internet Society (1998). All Rights 236 Reserved. 238 This document and translations of it may be copied and 239 furnished to others, and derivative works that comment on or 240 otherwise explain it or assist in its implementation may be 241 prepared, copied, published and distributed, in whole or in 242 part, without restriction of any kind, provided that the 243 above copyright notice and this paragraph are included on all 244 such copies and derivative works. However, this document 245 itself may not be modified in any way, such as by removing 246 the copyright notice or references to the Internet Society or 247 other Internet organizations, except as needed for the purpose 248 of developing Internet standards in which case the procedures 249 for copyrights defined in the Internet Standards process must 250 be followed, or as required to translate it into languages 251 other than English. 253 The limited permissions granted above are perpetual and will 254 not be revoked by the Internet Society or its successors or 255 assigns. 257 This document and the information contained herein is provided 258 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 259 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 260 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 261 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 262 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 263 PARTICULAR PURPOSE.