diff options
Diffstat (limited to 'doc/rfc/rfc3365.txt')
| -rw-r--r-- | doc/rfc/rfc3365.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3365.txt b/doc/rfc/rfc3365.txt new file mode 100644 index 0000000..c056f63 --- /dev/null +++ b/doc/rfc/rfc3365.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group J. Schiller +Request for Comments: 3365 Massachusetts Institute of Technology +BCP: 61 August 2002 +Category: Best Current Practice + + + Strong Security Requirements for + Internet Engineering Task Force Standard Protocols + +Status of this Memo + + This document specifies an Internet Best Current Practices for the + Internet Community, and requests discussion and suggestions for + improvements. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + It is the consensus of the IETF that IETF standard protocols MUST + make use of appropriate strong security mechanisms. This document + describes the history and rationale for this doctrine and establishes + this doctrine as a best current practice. + +Table of Contents + + 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 3. Security Services . . . . . . . . . . . . . . . . . . . . . . 2 + 4. The Properties of the Internet. . . . . . . . . . . . . . . . 3 + 5. IETF Security Technology. . . . . . . . . . . . . . . . . . . 3 + 6. The Danvers Doctrine. . . . . . . . . . . . . . . . . . . . . 4 + 7. MUST is for Implementors. . . . . . . . . . . . . . . . . . . 5 + 8. Is Encryption a MUST? . . . . . . . . . . . . . . . . . . . . 5 + 9. Crypto Seems to Have a Bad Name . . . . . . . . . . . . . . . 6 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 7 + 14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 8 + + + + + + + + + +Schiller Best Current Practice [Page 1] + +RFC 3365 Encryption Security Requirements August 2002 + + +1. Introduction + + The purpose of this document is to document the IETF consensus on + security requirements for protocols as well as to provide the + background and motivation for them. + + The Internet is a global network of independently managed networks + and hosts. As such there is no central authority responsible for the + operation of the network. There is no central authority responsible + for the provision of security across the network either. + + Security needs to be provided end-to-end or host to host. The IETF's + security role is to ensure that IETF standard protocols have the + necessary features to provide appropriate security for the + application as it may be used across the Internet. Mandatory to + implement mechanisms should provide adequate security to protect + sensitive business applications. + +2. Terminology + + Although we are not defining a protocol standard in this document we + will use the terms MUST, MAY, SHOULD and friends in the ways defined + by [RFC2119]. + +3. Security Services + + [RFC2828] provides a comprehensive listing of internetwork security + services and their definitions. Here are three essential + definitions: + + * Authentication service: A security service that verifies an + identity claimed by or for an entity, be it a process, computer + system, or person. At the internetwork layer, this includes + verifying that a datagram came from where it purports to originate. + At the application layer, this includes verifying that the entity + performing an operation is who it claims to be. + + * Data confidentiality service: A security service that protects + data against unauthorized disclosure to unauthorized individuals or + processes. (Internet Standards Documents SHOULD NOT use "data + confidentiality" as a synonym for "privacy", which is a different + concept. Privacy refers to the right of an entity, normally a + person, acting in its own behalf, to determine the degree to which + it will interact with its environment, including the degree to + which the entity is willing to share information about itself with + others.) + + + + + +Schiller Best Current Practice [Page 2] + +RFC 3365 Encryption Security Requirements August 2002 + + + * Data integrity service: A security service that protects against + unauthorized changes to data, including both intentional change + (including destruction) and accidental change (including loss), by + ensuring that changes to data are detectable. + +4. Some Properties of the Internet + + As mentioned earlier, the Internet provides no inherent security. + Enclaves of networking exist where users believe that security is + provided by the environment itself. An example would be a company + network not connected to the global Internet. + + One might imagine that protocols designed to operate in such an + enclave would not require any security services, as the security is + provided by the environment. + + History has shown that applications that operate using the TCP/IP + Protocol Suite wind up being used over the Internet. This is true + even when the original application was not envisioned to be used in a + "wide area" Internet environment. If an application isn't designed + to provide security, users of the application discover that they are + vulnerable to attack. + +5. IETF Security Technology + + The IETF has several security protocols and standards. IP Security + (IPsec [RFC2411]), Transport Layer Security (TLS [RFC2246]) are two + well known protocols. Simple Authentication and Security Layer (SASL + [RFC2222] and the Generic Security Service Application Programming + Interface (GSSAPI [RFC2743]) provide services within the context of a + "host" protocol. They can be viewed as "toolkits" to use within + another protocol. + + One of the critical choices that a protocol designer must make is + whether to make use of one of the existing protocols, engineer their + own protocol to use one of the standard tools or do something + completely different. + + There is no one correct answer for all protocols and designers really + need to look at the threats to their own protocol and design + appropriate counter-measures. The purpose of the "Security + Considerations" Section required to be present in an RFC on the + Internet Standards Track is to provide a place for protocol designers + to document the threats and explain the logic to their security + design. + + + + + + +Schiller Best Current Practice [Page 3] + +RFC 3365 Encryption Security Requirements August 2002 + + +6. The Danvers Doctrine + + At the 32cd IETF held in Danvers, Massachusetts during April of 1995 + the IESG asked the plenary for a consensus on the strength of + security that should be provided by IETF standards. Although the + immediate issue before the IETF was whether or not to support + "export" grade security (which is to say weak security) in standards + the question raised the generic issue of security in general. + + The overwhelming consensus was that the IETF should standardize on + the use of the best security available, regardless of national + policies. This consensus is often referred to as the "Danvers + Doctrine". + + Over time we have extended the interpretation of the Danvers Doctrine + to imply that all IETF protocols should operate securely. How can + one argue against this? + + Since 1995 the Internet has increasingly come under attack from + various malicious actors. In 2000 significant press coverage was + devoted to Distributed Denial of Service attacks. However many of + these attacks were launched by first compromising an Internet + connected computer system. Usually many systems are compromised in + order to launch a significant distributed attack. + + A conclusion we can draw from all of this is that if we fail to + provide secure protocols, then the Internet will become less useful + in providing an international communications infrastructure, which + appears to be its destiny. + + One of the continuing arguments we hear against building security + into protocols is the argument that a given protocol is intended only + for use in "protected" environments where security will not be an + issue. + + However it is very hard to predict how a protocol will be used in the + future. What may be intended only for a restricted environment may + well wind up being deployed in the global Internet. We cannot wait + until that point to "fix" security problems. By the time we realize + this deployment, it is too late. + + The solution is that we MUST implement strong security in all + protocols to provide for the all too frequent day when the protocol + comes into widespread use in the global Internet. + + + + + + + +Schiller Best Current Practice [Page 4] + +RFC 3365 Encryption Security Requirements August 2002 + + +7. MUST is for Implementors + + We often say that Security is a MUST implement. It is worth noting + that there is a significant different between MUST implement and MUST + use. + + As mentioned earlier, some protocols may be deployed in secure + enclaves for which security isn't an issue and security protocol + processing may add a significant performance degradation. Therefore + it is completely reasonable for security features to be an option + that the end user of the protocol may choose to disable. Note that + we are using a fuzzy definition of "end user" here. We mean not only + the ultimate end user, but any deployer of a technology, which may be + an entire enterprise. + + However security must be a MUST IMPLEMENT so that end users will have + the option of enabling it when the situation calls for it. + +8. Is Encryption a MUST? + + Not necessarily. However we need to be a bit more precise here. + Exactly what security services are appropriate for a given protocol + depends heavily on the application it is implementing. Many people + assume that encryption means confidentiality. In other words the + encryption of the content of protocol messages. + + However there are many applications where confidentiality is not a + requirement, but authentication and integrity are. + + One example might be in a building control application where we are + using IP technology to operate heat and vent controls. There is + likely no requirement to protect the confidentiality of messages that + instruct heat vents to open and close. However authentication and + integrity are likely important if we are to protect the building from + a malicious actor raising or lowering the temperature at will. + + Yet we often require cryptographic technology to implement + authentication and integrity of protocol messages. So if the + question is "MUST we implement confidentiality?" the answer will be + "depends". However if the question is "MUST we make use of + cryptographic technology?" the answer is "likely". + + + + + + + + + + +Schiller Best Current Practice [Page 5] + +RFC 3365 Encryption Security Requirements August 2002 + + +9. Crypto Seems to Have a Bad Name + + The mention of cryptographic technology in many IETF forums causes + eyes to glaze over and resistance to increase. + + Many people seem to associate the word "cryptography" with concerns + such as export control and performance. Some just plain do not + understand it and therefore shy away from its use. However many of + these concerns are unfounded. + + Today export control, at least from most of the developed world, is + becoming less of a concern. And even where it is a concern, the + concern is not over cryptography itself but in its use in providing + confidentiality. + + There are performance issues when you make use of cryptographic + technology. However we pride ourselves in the IETF as being + engineers. It is an engineering exercise to figure out the + appropriate way to make use of cryptographic technology so as to + eliminate or at least minimize the impact of using cryptography + within a given protocol. + + Finally, as to understanding cryptography, you don't have to. In + other words, you do not need to become a cryptographer in order to + effectively make use of cryptographic technology. Instead you make + use of existing well understood ciphers and cipher suites to solve + the engineering problem you face. + + One of the goals that we have in the Security Area of the IETF is to + come up with guides so that protocol implementers can choose + appropriate technology without having to understand the minutiae. + +10. Security Considerations + + This document is about the IETF's requirement that security be + considered in the implementation of protocols. Therefore it is + entirely about security! + +11. Acknowledgements + + The author would like to acknowledge the participation of the + Security Area Advisory Group and in particular Rob Shirey, Ran + Atkinson, Steve Bellovin, Marc Blanchet, Steve Kent, Randy Bush, Dave + Crocker, Stephen Farrell, Paul Hoffman, Russ Housley, Christian + Huitema, Melinda Shore, Adam Shostack and Kurt D. Zeilenga. + + + + + + +Schiller Best Current Practice [Page 6] + +RFC 3365 Encryption Security Requirements August 2002 + + +12. References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2222] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security + Document Roadmap", RFC 2411, November 1998. + + [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", + RFC 2246, January 1999. + + [RFC2743] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1.", RFC 2743, January 2000. + + [RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, + May 2000. + +13. Author's Address + + Jeffrey I. Schiller + MIT Room W92-190 + 77 Massachusetts Avenue + Cambridge, MA 02139-4307 + USA + + Phone: +1 (617) 253-8400 + EMail: jis@mit.edu + + + + + + + + + + + + + + + + + + + + + +Schiller Best Current Practice [Page 7] + +RFC 3365 Encryption Security Requirements August 2002 + + +14. Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Schiller Best Current Practice [Page 8] + |