rfc3365.txt

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

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]