idnits 2.17.1 draft-ietf-saag-whyenc-00.txt: 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: ---------------------------------------------------------------------------- == 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 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 == 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2222 (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2411 (Obsoleted by RFC 6071) ** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2828 (Obsoleted by RFC 4949) Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Jeffrey I. Schiller 3 INTERNET-DRAFT Massachusetts Institute of Technology 4 Expires: January, 2002 July, 2001 6 Encryption and Security Requirements for IETF Standard Protocols 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2001). All Rights Reserved. 33 Abstract 35 It is the consensus of the IETF that IETF standard protocols MUST 36 make use of appropriate strong security mechanisms. This document 37 describes the history and rationale for this doctrine and establishes 38 this doctrine as a best current practice. 40 Table of Contents 42 Status of this Memo . . . . . . . . . . . . . . . . . . . . . . . 1 43 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . . 1 44 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Security Services . . . . . . . . . . . . . . . . . . . . . . 3 48 4. The Properties of the Internet . . . . . . . . . . . . . . . . 4 49 5. IETF Security Technology . . . . . . . . . . . . . . . . . . . 4 50 6. The Danvers Doctrine . . . . . . . . . . . . . . . . . . . . . 4 51 7. MUST is for Implementors . . . . . . . . . . . . . . . . . . . 5 52 8. Is Encryption a MUST? . . . . . . . . . . . . . . . . . . . . 6 53 9. Crypto Seems to have a Bad Name . . . . . . . . . . . . . . . 6 54 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 56 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 8 58 Full Copyright statement . . . . . . . . . . . . . . . . . . . . 8 60 1. Introduction 62 The purpose of this document is to document the IETF consensus on 63 security requirements for protocols as well as to provide the 64 background and motivation for them. 66 The Internet is a global network of independently managed networks 67 and hosts. As such there is no central authority responsible for the 68 operation of the network. There is no central authority responsible 69 for the provision of security across the network either. 71 Security needs to be provided end-to-end or host to host. The IETF's 72 security role is to ensure that IETF standard protocols have the 73 necessary features to provide appropriate security for the 74 application as it may be used across the Internet. Mandatory to 75 implement mechanisms should provide adequate security to protect 76 sensitive business applications. 78 2. Terminology 80 Although we are not defining a protocol standard in this document we 81 will use the terms MUST, MAY, SHOULD and friends in the ways defined 82 by [RFC2119]. 84 3. Security Services 86 [RFC2828] provides a comprehensive listing of internetwork security 87 services and their definitions. Here are three essential definitions: 89 * Authentication service: A security service that verifies an 90 identity claimed by or for an entity, be it a process, computer 91 system, or person. At the internetwork layer, this includes 92 verifying that a datagram came from where it purports to originate. 93 At the application layer, this includes verifying that the entity 94 performing an operation is who it claims to be. 96 * Data confidentiality service: A security service that protects data 97 against unauthorized disclosure to unauthorized individuals or 98 processes. (Internet Standards Documents SHOULD NOT use "data 99 confidentiality" as a synonym for "privacy", which is a different 100 concept. Privacy refers to the right of an entity, normally a 101 person, acting in its own behalf, to determine the degree to which 102 it will interact with its environment, including the degree to 103 which the entity is willing to share information about itself with 104 others.) 106 * Data integrity service: A security service that protects against 107 unauthorized changes to data, including both intentional change 108 (including destruction) and accidental change (including loss), by 109 ensuring that changes to data are detectable. 111 4. Some Properties of the Internet 113 As mentioned earlier, the Internet provides no inherent security. 114 Enclaves of networking exist where users believe that security is 115 provided by the environment itself. An example would be a company 116 network not connected to the global Internet. 118 One might imagine that protocols designed to operate in such an 119 enclave would not require any security services, as the security is 120 provided by the environment. 122 History has shown that applications that operate using the TCP/IP 123 Protocol Suite wind up being used over the Internet. This is true 124 even when the original application was not envisioned to be used in a 125 "wide area" Internet environment. If an application isn't designed to 126 provide security, users of the application discover that they are 127 vulnerable to attack. 129 5. IETF Security Technology 131 The IETF has several security protocols and standards. IP Security 132 (IPsec [RFC2411]), Transport Layer Security (TLS [RFC2246]) are two 133 well known protocols. Simple Authentication and Security Layer (SASL 134 [RFC2222] and the Generic Security Service Application Programming 135 Interface (GSSAPI [RFC2743]) provide services within the context of a 136 "host" protocol. They can be viewed as "toolkits" to use within 137 another protocol. 139 One of the critical choices that a protocol designer must make is 140 whether to make use of one of the existing protocols, engineer their 141 own protocol to use one of the standard tools or do something 142 completely different. 144 There is no one correct answer for all protocols and designers really 145 need to look at the threats to their own protocol and design 146 appropriate counter-measures. The purpose of the "Security 147 Considerations" Section required to be present in an RFC on the 148 Internet Standards Track is to provide a place for protocol designers 149 to document the threats and explain the logic to their security 150 design. 152 6. The Danvers Doctrine 154 At the 32cd IETF held in Danvers, Massachusetts during April of 1995 155 the IESG asked the plenary for a consensus on the strength of 156 security that should be provided by IETF standards. Although the 157 immediate issue before the IETF was whether or not to support 158 "export" grade security (which is to say weak security) in standards 159 the question raised the generic issue of security in general. 161 The overwhelming consensus was that the IETF should standardize on 162 the use of the best security available, regardless of national 163 policies. This consensus is often referred to as the "Danvers 164 Doctrine." 166 Over time we have extended the interpretation of the Danvers Doctrine 167 to imply that all IETF protocols should operate securely. How can one 168 argue against this? 170 Since 1995 the Internet has increasingly come under attack from 171 various malicious actors. In 2000 significant press coverage was 172 devoted to Distributed Denial of Service attacks. However many of 173 these attacks were launched by first compromising an Internet 174 connected computer system. Usually many systems are compromised in 175 order to launch a significant distributed attack. 177 A conclusion we can draw from all of this is that if we fail to 178 provide secure protocols, then the Internet will become less useful 179 in providing an international communications infrastructure, which 180 appears to be its destiny. 182 One of the continuing arguments we hear against building security 183 into protocols is the argument that a given protocol is intended only 184 for use in "protected" environments where security will not be an 185 issue. 187 However it is very hard to predict how a protocol will be used in the 188 future. What may be intended only for a restricted environment may 189 well wind up being deployed in the global Internet. We cannot wait 190 until that point to "fix" security problems. By the time we realize 191 this deployment, it is too late. 193 The solution is that we MUST implement strong security in all 194 protocols to provide for the all too frequent day when the protocol 195 coming into widespread use in the global Internet. 197 7. MUST is for Implementors 199 We often say that Security is a MUST implement. It is worth noting 200 that there is a significant different between MUST implement and MUST 201 use. 203 As mentioned earlier, some protocols may be deployed in secure 204 enclaves for which security isn't an issue and security protocol 205 processing may add a significant performance degradation. Therefore 206 it is completely reasonable for security features to be an option 207 that the end user of the protocol may choose to disable. Note that we 208 are using a fuzzy definition of "end user" here. We mean not only the 209 ultimate end user, but any deployer of a technology, which may be an 210 entire enterprise. 212 However security must be a MUST IMPLEMENT so that end users will have 213 the option of enabling it when the situation calls for it. 215 8. Is Encryption a MUST? 217 Not necessarily. However we need to be a bit more precise here. 218 Exactly what security services are appropriate for a given protocol 219 depends heavily on the application it is implementing. Many people 220 assume that encryption means confidentiality. In other words the 221 encryption of the content of protocol messages. 223 However there are many applications where confidentiality is not a 224 requirement, but authentication and integrity are. 226 One example might be in a building control application where we are 227 using IP technology to operate heat and vent controls. There is 228 likely no requirement to protect the confidentiality of messages that 229 instruct heat vents to open and close. However authentication and 230 integrity are likely important if we are to protect the building from 231 a malicious actor raising or lowering the temperature at will. 233 Yet we often require cryptographic technology to implement 234 authentication and integrity of protocol messages. So if the question 235 is "MUST we implement confidentiality?" the answer will be "depends." 236 However if the question is "MUST we make use of cryptographic 237 technology?" the answer is "likely." 239 9. Crypto Seems to have a Bad Name 241 The mention of cryptographic technology in many IETF forums causes 242 eyes to glaze over and resistance to increase. 244 Many people seem to associate the word "cryptography" with concerns 245 such as export control and performance. Some just plain do not 246 understand it and therefore shy away from its use. However many of 247 these concerns are unfounded. 249 Today export control, at least from most of the developed world, is 250 becoming less of a concern. And even where it is a concern, the 251 concern is not over cryptography itself but in its use in providing 252 confidentiality. 254 There are performance issues when you make use of cryptographic 255 technology. However we pride ourselves in the IETF as being 256 engineers. It is an engineering exercise to figure out the 257 appropriate way to make use of cryptographic technology so as to 258 eliminate or at least minimize the impact of using cryptography 259 within a given protocol. 261 Finally, as to understanding cryptography, you don't have to. In 262 other words, you do not need to become a cryptographer in order to 263 effectively make use of cryptographic technology. Instead you make 264 use of existing well understood ciphers and cipher suites to solve 265 the engineering problem you face. 267 One of the goals that we have in the Security Area of the IETF is to 268 come up with guides so that protocol implementers can choose 269 appropriate technology without having to understand the minutiae. 271 10. Security Considerations 273 This document is about the IETF's requirement that security be 274 considered in the implementation of protocols. Therefore it is 275 entirely about security! 277 11. Acknowledgements 279 The author would like to acknowledge the participation of the 280 Security Area Advisory Group and in particular Rob Shirey, Ran 281 Atkinson, Steve Bellovin, Marc Blanchet, Steve Kent, Randy Bush, Dave 282 Crocker, Stephen Farrell, Paul Hoffman, Russ Housley, Christian 283 Huitema, Melinda Shore, Adam Shostack and Kurt D. Zeileng. 285 12. References 287 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 288 Requirement Levels", BCP 14, RFC 2119, March 1997. 290 [RFC2222] Myers, J., "Simple Authentication and Security Layer 291 (SASL)", RFC2222, October 1997. 293 [RFC2411] Thayer, R., Doraswamy, N., Glenn, R., "IP Security Document 294 Roadmap", RFC2411, November 1998. 296 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", 297 RFC2246, January 1999. 299 [RFC2743] Linn, J., "Generic Security Service Application Program 300 Interface Version 2, Update 1.", RFC2743, January 2000. 302 [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, 303 May 2000. 305 13. Author's Address 307 Jeffrey I. Schiller 308 MIT Room W92-190 309 77 Massachusetts Avenue 310 Cambridge, MA 02139-4307 311 USA 312 Phone: +1 (617) 253-8400 313 Email: jis@mit.edu 315 Full Copyright statement 317 Copyright (C) The Internet Society (2001). All Rights Reserved. 318 This document and translations of it may be copied and furnished to 319 others, and derivative works that comment on or otherwise explain it 320 or assist in its implementation may be prepared, copied, published 321 and distributed, in whole or in part, without restriction of any 322 kind, provided that the above copyright notice and this paragraph are 323 included on all such copies and derivative works. However, this 324 document itself may not be modified in any way, such as by removing 325 the copyright notice or references to the Internet Society or other 326 Internet organizations, except as needed for the purpose of 327 developing Internet standards in which case the procedures for 328 copyrights defined in the Internet Standards process must be 329 followed, or as required to translate it into languages other than 330 English. 332 The limited permissions granted above are perpetual and will not be 333 revoked by the Internet Society or its successors or assigns. 335 This document and the information contained herein is provided on An 336 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 337 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 338 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF INFORMATION HEREIN 339 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 340 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.