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

Document Type RFC - Best Current Practice (August 2002; No errata)
Also known as BCP 61
Last updated 2012-02-26
Stream Legacy
Formats plain text pdf html
Stream Legacy state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3365 (Best Current Practice)
Telechat date
Responsible AD Steven Bellovin
IESG note Published as RFC 3365 in August 2002
Send notices to <jis@mit.edu>
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.
Show full document text