rfc3365.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 452 行 · 第 1/2 页


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: [phone]
   EMail: [e-mail]





















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]