Strong Security Requirements for Internet Engineering Task Force Standard Protocols
RFC 3365

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

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.