idnits 2.17.1 draft-freed-gatesec-01.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 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 140 has weird spacing: '...ltipart are p...' == Line 238 has weird spacing: '...rnished to ot...' == Line 239 has weird spacing: '...herwise expla...' == Line 241 has weird spacing: '...without restr...' == Line 242 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 (December 1997) is 9627 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 192, but no explicit reference was found in the text == Unused Reference: 'RFC-2049' is defined on line 212, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 11 errors (**), 0 flaws (~~), 11 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 December 1997 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 learn the current status of any Internet-Draft, please 26 check the 1id-abstracts.txt listing contained in the 27 Internet-Drafts Shadow Directories on ds.internic.net (US East 28 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 29 or munnari.oz.au (Pacific Rim). 31 Copyright (C) The Internet Society (1997). All Rights 32 Reserved. 34 1. Abstract 36 This document examines the problems associated with use of 37 MIME security multiparts and gateways to non-MIME 38 environments. A set of requirements for gateway behavior are 39 defined which provide facilities necessary to properly 40 accomodate the transfer of security multiparts through 41 gateways. 43 2. Requirements Notation 45 This document occasionally uses terms that appear in capital 46 letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD 47 NOT", and "MAY" appear capitalized, they are being used to 48 indicate particular requirements of this specification. A 49 discussion of the meanings of these terms appears in [RFC- 50 2119]. 52 3. The Problem 54 Security multiparts [RFC-1847] provide an effective way to add 55 integrity and confidentiality services to protocols that 56 employ MIME objects [RFC-2045, RFC-2046]. Difficulties arise, 57 however, in heterogeneous environments involving gateways to 58 environments that don't support MIME. Specifically: 60 (1) Security services have to be applied to MIME objects in 61 their entirety. Failure to do so can lead to security 62 exposures. 64 For example, a signature that covers only object data 65 and not the object's MIME labels would allow someone to 66 tamper with the labels in an undetectable fashion. 67 Similarly, failure to encrypt MIME label information 68 exposes information about the content that could 69 facilitate traffic analysis. 71 Composite MIME objects (e.g. multipart/mixed, 72 message/rfc822) also have to be secured as a unit. 73 Again, failure to do so may facilitate tampering, 74 reveal important information unnecessarily, or both. 76 (2) Gateways that deal with MIME objects have to be able to 77 convert them to non-MIME formats. 79 For example, gateways often have to transform MIME 80 labelling information into other forms. MIME type 81 information may end up being expressed as a file 82 extension or as an OID. 84 Gateways also have to take apart composite MIME objects 85 into their component parts, converting the resulting 86 set of parts into whatever form the non-MIME 87 environments uses for composite objects. Failure to do 88 so makes the objects unusable in any environment that 89 doesn't support MIME. In many cases this also means 90 that multi-level MIME structures having to be converted 91 into a sequential list of parts. 93 (3) Security services have to be deployed in an end-to-end 94 fashion. Failure to do so again can lead to security 95 exposures. 97 An integrity service deployed at something other than a 98 connection end point means a region exists between the 99 point where the integrity service is applied and the 100 actual end point where object tampering is possible. A 101 confidentiality service deployed at something other 102 than a connection end point means a region exists where 103 the object is transferred in the clear. And worse, 104 distibuted private keys are usually necessary whenever 105 someone other than the originator applies an integrity 106 service or someone other than the recipient removes a 107 confidentiality service, which in turn may make theft 108 of private key information a possibility. 110 All of these issues can be addressed, of course. For 111 example, it may be possible to use multiple overlapping 112 security services to assure that no exposure exists 113 even though there is no end-to-end security per se. And 114 keys can be distributed in a secure fashion. However, 115 such designs tend to be quite complex, and complexity 116 in a security system is highly undesireable. 118 The preceeding three requirments are fundamentally in 119 conflict: It is possible to satisfy two of them at once, but 120 not all three at once. 122 In fact the conflict is even worse than it first appears. In 123 most situations of this sort some sort of compromise is 124 possible which, while not satisfying any of the requirements 125 completely, does optimize some sort of average of all the 126 requirements. Such a solution does not exist in this case, 127 however, because many real world situations exist where any 128 one of these requirements absolutely must be satisfied. 130 4. Solving the Problem 132 Since the previously described problem doesn't allow for a 133 single solution the only viable approach is to require that 134 gateways provide multiple solutions. In particular, gateways 136 (1) MUST provide the ability to tunnel multipart/signed and 137 multipart/encrypted objects as monolithic entities if 138 there is any chance whatsoever that MIME capabilities 139 exist on the non-MIME side of the gateway. No changes 140 to content of the multipart are permitted, even when 141 the content is itself a composite MIME object. 143 This option must be provided so that entities behind 144 the gateway that are capable of processing security 145 multiparts and their MIME content will work properly. 146 As mentioned previously, situations exist where 147 security requirements are absolute and must be 148 accomodated, even when the price of meeting them causes 149 problems for other agents. 151 Exceptions are allowed only when there is no 152 possibility of MIME support on one side of the gateway. 153 For example, a gateway to a voice messaging system may 154 have no useful way to represent a signed MIME object. 156 (2) MUST provide the ability to take apart multipart/signed 157 objects, exposing the content (and in the process 158 ruining the signature). When this approach is selected 159 gateways SHOULD remove the signature entirely and 160 replace it with a note indicating that it was removed. 162 This option must be provided so that entities behind 163 the gateway which are incapable of processing MIME will 164 work properly. 166 (3) SHOULD provide the ability to select between the 167 previous two options on per-user basis. 169 (4) MAY provide facilities to check signatures and decrypt 170 encrypted content. Such facilities MUST NOT be enabled 171 by default; the potential security exposure involved 172 has to be assessed before such capabilities can be 173 used. 175 (5) MAY provide facilities to sign and/or encrypt material 176 passing from the non-MIME side to the MIME side of the 177 gateway. Again, such facilities MUST NOT be enabled by 178 default; the potential security exposure involved in 179 the transfer of unsecured content within the gateway 180 has to be assessed before such capabilities can be 181 used. 183 A gateway which complies with the above requirements is 184 considered to be security multiparts compliant. 186 5. Security Considerations 188 This entire document is about security. 190 6. References 192 [RFC-822] 193 Crocker, D., "Standard for the Format of ARPA Internet 194 Text Messages", RFC 822, August, 1982. 196 [RFC-1847] 197 Galvin, J., Murphy, S., Crocker, S., Freed, N., " 198 Security Multiparts for MIME: Multipart/Signed and 199 Multipart/Encrypted", RFC 1847, October 1995. 201 [RFC-2045] 202 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 203 Extensions (MIME) Part One: Format of Internet Message 204 Bodies", RFC 2045, Innosoft, First Virtual Holdings, 205 December 1996. 207 [RFC-2046] 208 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 209 Extensions (MIME) Part Two: Media Types", RFC 2046, 210 Innosoft, First Virtual Holdings, December 1996. 212 [RFC-2049] 213 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 214 Extensions (MIME) Part Five: Conformance Criteria and 215 Examples", RFC 2049, Innosoft, FIrst Virtual Holdings, 216 December 1996. 218 [RFC-2119] 219 Bradner, S., "Key words for use in RFCs to Indicate 220 Requirement Levels", RFC 2119, March 1997. 222 7. Author's Address 224 Ned Freed 225 Innosoft International, Inc. 226 1050 Lakes Drive 227 West Covina, CA 91790 228 USA 229 tel: +1 626 919 3600 fax: +1 626 919 3614 230 email: ned.freed@innosoft.com 232 8. Full Copyright Statement 234 Copyright (C) The Internet Society (1997). All Rights 235 Reserved. 237 This document and translations of it may be copied and 238 furnished to others, and derivative works that comment on or 239 otherwise explain it or assist in its implementation may be 240 prepared, copied, published and distributed, in whole or in 241 part, without restriction of any kind, provided that the 242 above copyright notice and this paragraph are included on all 243 such copies and derivative works. However, this document 244 itself may not be modified in any way, such as by removing 245 the copyright notice or references to the Internet Society or 246 other Internet organizations, except as needed for the purpose 247 of developing Internet standards in which case the procedures 248 for copyrights defined in the Internet Standards process must 249 be followed, or as required to translate it into languages 250 other than English. 252 The limited permissions granted above are perpetual and will 253 not be revoked by the Internet Society or its successors or 254 assigns. 256 This document and the information contained herein is provided 257 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 258 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 259 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 260 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 261 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 262 PARTICULAR PURPOSE.